Set Up DKIM — Signing Your Outgoing Email

How DKIM works

When sending, your mail server hashes the body and a selection of headers and signs that hash with a private key. The signature travels in the message as a DKIM-Signature header. The public counterpart lives in DNS, so any recipient can verify that the signature matches.

The DNS location is built from a freely chosen selector plus the domain: selector._domainkey.yourdomain.com. Selectors let you run several keys in parallel — one per sending system, and temporarily two during rotation.

Step 1 — Generate the key pair

With Google Workspace, Microsoft 365 and most hosting providers the admin console handles this and hands you the finished DNS value. On your own server, e.g. with OpenDKIM or Rspamd:

Use 2048 bit. 1024 bit is considered too weak; 4096 bit sometimes no longer fits into a single TXT string and is poorly supported by some DNS providers.

Step 2 — Publish the public key in DNS

The p= value is the base64 portion of the public key, without the BEGIN and END lines and without line breaks. "mail" is the selector here — it must match the one your mail server writes into the signature.

Step 3 — Enable signing

Install the private key on your mail server and enable signing for outgoing messages. Watch two settings in particular:

• Algorithm rsa-sha256, not rsa-sha1.
• Signed headers: at minimum From, To, Subject and Date belong in the h= list. The From header is mandatory — without it there is no DMARC alignment.

Step 4 — Ensure alignment

For DMARC it is not enough that the signature is valid. The signing domain in the d= tag must match the domain in the From header. If you use an email service provider, it often signs with its own domain by default — the signature is then valid but worthless for DMARC. In those cases configure the option to sign with your own domain (usually a CNAME pointing at the provider).

Key rotation

A DKIM key should be replaced regularly, at least annually. The procedure without downtime:

1. Generate a new key pair with a new selector, e.g. mail2
2. Publish the new public key in DNS and wait for propagation
3. Switch the mail server to the new selector
4. Leave the old selector in DNS for at least a week — messages still in transit would otherwise become unverifiable
5. Only then remove the old record

Common mistakes

• Line breaks in the p= value: copying from a PEM file leaves the breaks in. The record is then invalid.
• Selector mismatch: the mail server signs with default while the key sits at mail in DNS. Result: permanent failure.
• Footers from intermediate systems: mailing lists and some security gateways alter the body and break the signature. That is what ARC is for.
• Only one path signed: invoicing systems and newsletter tools frequently do not sign. Every sending path needs its own configuration.

Testing

After the change, send an email to hello@analyzemy.email. The report shows every signature found, individually, with algorithm, key strength, signed headers and alignment status.