DKIM: the digital signature inside every email

If SPF is a guest list of approved servers, DKIM (DomainKeys Identified Mail) is a wax seal on the envelope. Your outgoing mail server attaches a digital signature to every message before it leaves, and anyone who receives that message can check the signature against a public key your domain has published. If it checks out, the receiving mailbox knows two things for certain: this message really did pass through a server that holds your domain's private signing key, and nobody altered it along the way.

That second guarantee is what makes DKIM different from SPF. SPF only checks where a message came from; it says nothing about whether the contents were changed after it left. DKIM is the piece that lets a message stay provably yours even after being forwarded, relayed, or passed through a mailing list.

The public key is published as a TXT record at a very specific DNS location: selector._domainkey.yourdomain.com. The selector is a short label chosen by whoever set up DKIM (common examples: google, selector1, k1) — it exists because a domain can run several DKIM keys at once, one per sending tool, each under its own selector name.

Behind the scenes, DKIM uses a pair of mathematically linked keys: a private key that only your sending server ever touches, and the public key published in DNS as above. When a message goes out, the server runs its headers and body through the private key to produce a signature, then attaches it to the message. Anyone receiving that message can run the same content through your published public key and confirm the signature matches — this is the same public-key idea used to secure things like software downloads and digital contracts, just applied to email.

Not every DKIM key offers the same level of protection. The strength of the signature depends on how large the underlying cryptographic key is — a bigger key is exponentially harder to break by brute force. Older or hastily configured DKIM setups sometimes still use smaller, weaker keys that were considered adequate years ago but no longer meet current standards.

Because a DKIM signature covers the actual content of a message, anything that modifies that content after it's signed can invalidate it — even when the change is harmless or well-intentioned. Mailing lists that add an unsubscribe footer, security gateways that rewrite links, or forwarding services that alter subject lines can all unintentionally break a signature that was perfectly valid when it left the original sender.

This is one reason DKIM and SPF are meant to work as a pair rather than substitutes for each other: a message that loses its DKIM validity somewhere along the way can often still lean on a passing SPF check, and vice versa.