DKIM: DomainKeys Identified Mail

What it does

DKIM proves that a message wasn't tampered with in transit and that it was authorised by the holder of your domain's private key. The sending server adds a DKIM-Signature header that includes a hash of selected parts of the message; receivers reproduce the hash and verify it against your published public key.

Crucially, the DKIM signature travels with the message. When a recipient forwards your email, the DKIM signature still validates at the next hop (assuming the forwarder doesn't rewrite the body). That makes DKIM the protocol that DMARC alignment relies on for forwarded mail.

Each ESP signs with their own key, so you publish multiple selectors (one per sender). Modern ESPs auto-rotate keys via CNAME records you publish.

How it works

1. Generate a 2048-bit RSA key pair (or have your ESP do it).
2. Publish the public key as a TXT record at <selector>._domainkey.<your-domain>.
3. Configure your sending server / ESP to sign every outbound message with the matching private key.
4. Receivers retrieve the public key via the DKIM-Signature header's d= and s= tags, hash the message body + headers per the algorithm, and compare to the included signature.
5. A pass result feeds DMARC alignment; a fail flags the message.

Example record

google._domainkey.yourdomain.com TXT

Common pitfalls

• Using 1024-bit keys (vulnerable to factorization). Industry standard since 2018 is 2048-bit. Some legacy ESPs still default to 1024; rotate to 2048.
• Forgetting that mailing-list managers rewrite message bodies, breaking DKIM. The fix is ARC (Authenticated Received Chain), not a DKIM tweak.
• Not rotating keys periodically. Once a private key is compromised, every signed message is forgeable. Rotate annually at minimum.
• Multiple TXT entries on the same selector — only the first is honoured, rest are ignored. Use a single TXT split across quoted strings if needed.

Related tools