What is DKIM? How email signing works, and the mistakes that break it

Published October 16, 2026 · about a 7-minute read

If SPF is the bouncer with a guest list, DKIM is the tamper-proof seal on the envelope. It's the strongest of the three email-authentication checks, and it's the one people get almost right — the record's there, the signature's there, and yet mail still fails because of one detail nobody mentioned during setup. Let me explain what DKIM actually does and where it tends to fall over.

What DKIM does

DKIM — DomainKeys Identified Mail — attaches a cryptographic signature to every message your server sends. Here's the flow: your mail server holds a private key and uses it to sign each outgoing message. You publish the matching public key in DNS. When a receiving server gets your message, it reads the signature, fetches your public key, and checks that the two match. If they do, two things are proven: the message genuinely came from your domain, and nothing in the signed parts was changed along the way.

That second guarantee is what sets DKIM apart from SPF. SPF only asks "did this come from an approved server." DKIM cryptographically binds the message to your domain and detects tampering. And unlike SPF, a DKIM signature survives forwarding, because it travels inside the message rather than depending on the connecting IP.

Reading the signature and the record

DKIM has two halves. First, the signature your server adds to the message header, which looks roughly like this:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s2026a;
  h=from:to:subject:date; bh=...; b=...

The pieces that matter:

• d= — the signing domain. For DMARC to pass on DKIM, this has to align with the visible From domain.
• s= — the selector. This tells the receiver which key to look up.
• h= — which headers were signed.
• bh= and b= — the body hash and the signature itself.

Second, the public key, published in DNS at <selector>._domainkey.yourdomain.com. So the selector s2026a above lives at s2026a._domainkey.yourdomain.com and looks like:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...

The p= value is your public key. That's the whole public side — one TXT record per selector.

The selector is the clever bit

The selector exists so one domain can publish several DKIM keys at the same time. Your email provider signs with one selector, your marketing platform signs with a different one, and each publishes its own key under its own name. No collisions.

It's also what makes safe key rotation possible, which matters because you should rotate. The private key is the crown jewel — anyone who gets it can sign mail as you — so rotating every 6 to 12 months limits how long a leaked key stays useful. The trick is the two-selector overlap:

1. Generate a new key pair and publish the new selector's public key in DNS.
2. Wait for DNS to propagate. The new key must be live before you sign anything with it.
3. Switch your server to sign with the new selector.
4. Leave the old selector in DNS for a while — mail signed just before the switch is still in flight and needs the old key to verify.
5. Once the old mail has cleared, remove the old record.

The two classic rotation disasters: signing with a selector whose key you forgot to publish, and ripping out the old selector the same minute you switch. Both produce a wave of DKIM failures from mail that was perfectly legitimate.

Key length, briefly

Use a 2048-bit RSA key. It's the current default, and most providers generate it for you without asking. You'll still see 1024-bit keys in the wild — they work, but treat 1024 as the weak floor, not a target, and upgrade when you can. Going to 4096-bit is almost never worth it; it adds DNS and compatibility friction for a security margin you don't need at this layer. If your provider handles signing for you (Google Workspace, Microsoft 365, most ESPs), this is usually a non-decision — they set sensible defaults.

Where DKIM actually breaks

In my experience, DKIM rarely fails because the crypto is wrong. It fails for dull operational reasons:

• The record got mangled. DKIM public keys are long, and DNS providers love to split or truncate them. A single altered character and the signature can't verify. Always check the published record, not the one you pasted.
• A middlebox rewrote the message. Some mailing lists and security gateways modify the subject or body after signing, which invalidates the body hash. The signature was fine; the message changed under it.
• Signing isn't actually enabled. You published the key, but the sending platform was never switched on to sign — so there's no signature to check. Common right after adding a new sending tool.
• Alignment is off. DKIM passes on its own, but the d= domain doesn't match your From domain, so DMARC doesn't count it. Technically authenticated, functionally useless for DMARC.

Every one of these is invisible from your side. Your mail sends fine; it just quietly fails authentication at the far end and starts sliding toward spam. That's the theme across all of email auth — it fails silently, and the only way to know is to look from the outside.