DKIM DomainKeys Identified Mail

How DKIM actually works

At its mechanical core, DKIM does three things. Your sending server takes a hash of selected message headers and the body, signs that hash with a private key, and inserts the signature into the email as a DKIM-Signature header. The receiving server reads the header, fetches the public key from {selector}._domainkey.{your-domain} in DNS, hashes the message in the same way, and compares. If the signature verifies, the message provably came from your domain and was not modified along the way. If it does not verify, the message has either been tampered with, was never signed by your domain, or there is a DNS misconfiguration.

The "selector" part is worth pausing on. A single domain can publish multiple DKIM keys at different selectors. This matters in practice because rotating keys without breaking running mail flow requires having both an old key and a new key available simultaneously. ESPs that send on your behalf, including us, will usually ask you to publish a selector-specific CNAME or TXT record so they can sign mail with their managed key while it still verifies as coming from your domain.

Why DKIM matters in 2026

Gmail and Yahoo's 2024 enforcement update made DKIM effectively mandatory for any sender pushing more than 5,000 messages per day to those mailboxes. Outlook tightened its bulk-sender rules around the same time. The era where DKIM was a nice-to-have is over. Without DKIM, your messages either land in spam at a much higher rate or get rejected outright by bulk-sender policies. The cost of not having it is now measurable in delivered-mail percentages, not theoretical risk.

DKIM is also one of the three signals that DMARC uses to make policy decisions. SPF can pass while DKIM fails, or vice versa, but you need at least one of them to align with your visible From: domain for DMARC to consider the message authenticated. If neither signal aligns, DMARC fails and the receiving server applies whatever policy you published. For most senders that means quarantine or reject. Set up DKIM properly before you go anywhere near a DMARC p=reject policy. Our free deliverability check verifies all three together so you can see where the gap is.

Common DKIM mistakes I keep seeing

Three patterns show up over and over. First, teams set up DKIM on the apex domain but then send marketing from a subdomain whose DKIM never got configured, so half their mail authenticates and half fails. The fix is straightforward but easy to miss: every subdomain you actually send from needs its own DKIM keys published.

Second, key rotation. Teams publish a DKIM key on day one, never rotate it, and three years later are running a 1024-bit key that has been considered weak since 2017. Modern guidance is 2048-bit RSA keys with rotation every 6-12 months. Most ESPs handle this for you if you let them manage the keys, but if you generated keys yourself or rolled your own setup, check what you are still running.

Third, DNS record formatting. DKIM public keys are long. DNS providers split them into multiple quoted strings in TXT records, and some configuration tools concatenate the strings incorrectly. The signature then fails verification on the receiving side and you spend three hours wondering why nothing works. If verification is failing intermittently or just for some recipients, a malformed DNS record is the first place to look.

Related reading

• Email Deliverability — DKIM is one of the foundational signals. Start with the broader concept if authentication is new territory.
• The Email Deliverability Guide — full-length practical setup including DKIM key generation and DNS record templates.
• Domain temperature and warmup — DKIM-signed mail is the baseline for any warmup process. Without it, warmup is just sending more mail that gets filtered.
• Run a free deliverability check — checks DKIM alongside SPF, DMARC, and MX. No signup required.