DKIM Explained: Cryptographically Signing Your Domain’s Email

DKIM has the sending server add a cryptographic signature to the email headers. The recipient reads the public key from DNS — a TXT record at selector._domainkey.example.com — and verifies the signature. If the message body or signed headers were altered anywhere along the way, verification fails and the mail drops in trust.

The moving parts

• Selector: the label that tells the receiver which public key to fetch. Every sending service has its own selector (common examples: s1, google, k1), which is why a domain often carries several *._domainkey records at once.
• Key size: at least 1024 bits; prefer 2048. Note that a 2048-bit key may need a longer TXT record split into multiple strings — a common copy-paste error is pasting only the first fragment.
• Key rotation: publish a new key every few months. A key that has served unchanged for years is a standing risk, especially if it was ever handled by several people.
• Verification test: send a message to an inbound mail tester and read the SPF/DKIM/DMARC results together — DKIM passing alone is not the goal; alignment is.

You can check a key is published correctly without sending anything:

dig +short TXT s1._domainkey.example.com

Expect a record containing v=DKIM1, a k=rsa tag and a long p= base64 key.

When DKIM fails

The two dominant causes are a missing or misnamed DNS record (wrong selector, truncated key) and forwarding: many forwarders rewrite the message body or add footers, which breaks the signature. SPF breaks on forwarding too, which is precisely why DMARC exists — it accepts either authentication passing. DKIM alone is never the whole answer; it becomes meaningful alongside SPF and DMARC, and the WhoDNS email records tool checks all three in one pass, including the selector lookup that most generic DNS tools skip.

🔗 Related tool: Check your DKIM and email records