In 2016, hackers breached a major political campaign's email system. But the most damaging part wasn't the breach itself—it was what came after. Attackers modified some of the stolen emails before releasing them, adding fabricated content to real message threads. Without cryptographic signatures, there was no way to prove which emails were authentic and which had been altered.
This is the problem DKIM solves. Not just proving that an email came from who it claims to come from, but proving that it hasn't been modified since it was sent.
DKIM—DomainKeys Identified Mail—adds a cryptographic signature to every email you send. This signature is mathematically tied to the email's content. Change a single character, and the signature becomes invalid. It's the digital equivalent of a tamper-evident seal.
The cryptography behind DKIM
DKIM uses public-key cryptography, the same technology that secures HTTPS connections and cryptocurrency wallets. If you're not familiar with how this works, here's the essential concept.
You generate two mathematically linked keys: a private key and a public key. Anything encrypted with the private key can only be decrypted with the public key, and vice versa. The private key stays secret; the public key is shared with the world.
When you send an email, your mail server takes certain parts of the message—typically the From address, Subject, Date, and body—and creates a hash (a fixed-length fingerprint) of that content. It then encrypts this hash using your private key. The encrypted hash is your DKIM signature.
The signature gets added to the email as a header. When the email arrives at its destination, the receiving server retrieves your public key from DNS, decrypts the signature to get the original hash, and then creates its own hash of the email content. If the two hashes match, the email is authentic and unmodified. If they don't match, something changed.
The beauty of this system is that only someone with your private key can create a valid signature. And since the signature is tied to the email's content, any modification—even adding a space—invalidates it.
What DKIM actually signs
Not every part of an email gets signed. DKIM lets you specify which headers to include in the signature, and this choice matters more than you might think.
The 'From' header is always signed—this is the whole point, proving who sent the email. Most implementations also sign 'To', 'Subject', 'Date', and 'Message-ID'. The email body is signed separately (its hash appears in the 'bh' field of the signature).
Headers that might legitimately change during transit—like 'Received' headers that get added by each server the email passes through—are typically not signed. If they were, the signature would break every time the email was relayed.
This selective signing is both a feature and a limitation. It means emails can pass through multiple servers without breaking DKIM, but it also means unsigned headers can be modified without detection. A sophisticated attacker could potentially add misleading headers to a legitimately signed email.
Selectors and key rotation
When you look up a DKIM public key in DNS, you don't just query the domain—you query a specific 'selector' within that domain. This seemingly minor detail enables some important capabilities.
A selector is just a name that identifies which key to use. Your DKIM signature includes a 's=' field specifying the selector, and the receiving server looks up [selector]._domainkey.[yourdomain] to find the public key.
Why does this matter? Because it lets you have multiple active keys simultaneously. You might use different selectors for different email services—one for your marketing platform, another for your transactional emails. Each service has its own private key, and if one is compromised, you can revoke it without affecting the others.
Selectors also enable key rotation. Security best practice says you should periodically generate new keys, but you can't just swap keys instantly—emails in transit signed with the old key would fail verification. With selectors, you can publish a new key under a new selector, start signing new emails with it, and keep the old key active until all in-transit emails have been delivered. Then you remove the old key.
Most email services handle this automatically, but if you're managing your own mail infrastructure, key rotation is something you need to plan for.
DKIM's relationship with SPF and DMARC
DKIM doesn't exist in isolation. It's one piece of a three-part email authentication system, and understanding how the pieces fit together is crucial.
SPF verifies that the sending server is authorized to send for the domain. DKIM verifies that the email content is authentic and unmodified. But neither one, alone, ties the authentication to the 'From' address that recipients actually see.
This is where DMARC comes in. DMARC requires that either SPF or DKIM (or both) pass AND that the authenticated domain aligns with the visible 'From' domain. Without DMARC, an attacker could send an email that passes SPF for their own domain while displaying your domain in the 'From' header.
DKIM has one significant advantage over SPF: it survives forwarding. When someone forwards your email, the forwarding server's IP won't be in your SPF record, so SPF fails. But the DKIM signature travels with the email content, so it remains valid even after forwarding. This is why having both SPF and DKIM is important—they cover each other's weaknesses.
When DKIM fails
DKIM failures happen, and they're not always because of attackers. Understanding the common causes helps you troubleshoot deliverability issues.
The most common cause is content modification by intermediate servers. Some email security gateways add footers to outgoing emails, or modify links for tracking purposes. If these modifications happen after DKIM signing, the signature becomes invalid. The fix is to ensure DKIM signing happens last, after all content modifications.
Mailing lists are another frequent culprit. Many mailing lists modify the Subject line (adding '[listname]' prefixes) or add footers. Since Subject is typically signed, these modifications break DKIM. Some modern mailing list software re-signs emails with the list's own DKIM key, but many don't.
Key mismatches cause failures too. If you rotate your DKIM key but don't update DNS, or if there's a typo in the DNS record, verification will fail. Always test after making changes.
Finally, clock skew can cause problems. DKIM signatures include a timestamp, and some implementations reject signatures that are too old or from the future. If your mail server's clock is significantly wrong, signatures might fail verification.
Setting up DKIM properly
If you're using a managed email service like Google Workspace, Amazon SES, or a dedicated email API, DKIM setup is usually straightforward—they generate the keys and tell you what DNS record to add. But there are still decisions to make and pitfalls to avoid.
Key length matters. The minimum is 1024 bits, but 2048 bits is now the standard recommendation. Some older systems can't handle 2048-bit keys in DNS (there are workarounds involving splitting the key across multiple strings), but this is increasingly rare. Don't use 1024-bit keys for new setups.
Test thoroughly before relying on DKIM. Send test emails to Gmail, Outlook, and Yahoo, then check the headers to confirm DKIM is passing. Look for 'dkim=pass' in the Authentication-Results header. If you see 'dkim=fail' or no DKIM result at all, something's wrong.
Monitor your DMARC reports. They'll show you DKIM pass/fail rates across all your email. A sudden increase in failures might indicate a configuration problem, a compromised key, or someone attempting to spoof your domain.
Plan for key rotation from the start. Even if you're not rotating keys today, set up your infrastructure so you can. Use meaningful selector names that include dates or version numbers, making it clear which key is current.
Frequently asked questions
Does DKIM encrypt my emails?
No. DKIM signs emails, it doesn't encrypt them. The signature proves authenticity and integrity, but the email content is still readable by anyone who intercepts it. For encryption, you need S/MIME or PGP, or rely on TLS for transport encryption.
Can I use the same DKIM key for multiple domains?
Technically yes, but it's not recommended. If the key is compromised, all domains are affected. Each domain should have its own key pair. Most email services handle this automatically.
Why do some of my emails pass DKIM and others fail?
Usually this means something is modifying some emails after signing. Check if you have email security tools, auto-responders, or forwarding rules that might alter content. Also verify that all your sending sources are properly configured for DKIM.
How often should I rotate DKIM keys?
There's no universal standard, but annually is a reasonable baseline. More frequent rotation (quarterly) is better if you can automate it. The important thing is having a rotation process in place, not the specific frequency.