mailhow
All posts
July 23, 2026

DKIM Explained: Selectors, Key Rotation, and the Silent Failure Modes

How DKIM signatures work, why selectors exist, RSA vs Ed25519 and dual-signing, why rotation matters, and the four ways DKIM breaks without anyone noticing.

TL;DR — DKIM puts a cryptographic signature on every message you send; the public key lives in your DNS, so any receiver can verify the mail really came from your domain's infrastructure and wasn't altered in transit. Unlike SPF, the signature travels inside the message — so it survives forwarding. You don't manage keys day-to-day, but you should understand selectors, rotation, and the handful of ways DKIM breaks silently.

The mechanism in one paragraph

Your mail server computes a hash over the message body and selected headers, signs it with a private key, and attaches the result as a DKIM-Signature header. That header names the signing domain (d=yourdomain.com) and a selector (s=s1). The receiver fetches the public key from DNS at <selector>._domainkey.<domain>, verifies the signature, and now knows two things: the message was sent by infrastructure holding your domain's key, and the signed parts weren't modified on the way.

s1._domainkey.yourdomain.com.   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ..."

Selectors: why the record has that funny name

The selector is just a label that lets one domain publish many keys at once — s1._domainkey, s2._domainkey, 2026a._domainkey — with each outgoing message naming which one signed it. That's what makes zero-downtime key rotation possible (publish the new key at a new selector, start signing with it, retire the old one later) and what lets multiple services sign for the same domain without sharing keys: your mailbox provider on its selectors, your newsletter tool on its own.

Practical consequence: you can't audit DKIM by looking for "the" record. You audit by sending a message and reading which s= the signature declares.

RSA and Ed25519

RSA-2048 is the universally-verified workhorse. Ed25519 (RFC 8463) gives equivalent security with tiny keys, but receiver support is still not universal — which is why serious setups dual-sign: every message carries both an RSA and an Ed25519 signature, receivers verify whichever they support, and one valid signature is enough. (This is how we sign at MailHow — two signatures per message, rotating selectors.) If your provider offers only one, RSA-2048 is the safe answer.

Rotation: the part everyone skips

A DKIM private key that never changes is a quietly compounding risk: a key leaked once — a compromised relay, an old backup — signs "authentic" mail for your domain forever. Rotation bounds that damage.

Two ways it's handled:

  • CNAME delegation — your DNS has s1._domainkey.yourdomain.com CNAME s1.dkim.provider.com, and the provider rotates keys behind the pointer without you touching anything. This is the best available arrangement: rotation happens, and you did nothing.
  • Automatic in-zone rotation — when the provider is your DNS automation (as on MailHow), it can write fresh keys on a schedule directly.

If your setup is "I pasted a p= value into DNS three years ago" — that's the one to fix. Ask your provider how rotation works; "it doesn't" is a real answer you deserve to hear plainly.

How DKIM breaks in practice

  • The DNS UI mangles the key. Long TXT values get split into 255-byte chunks (correct and fine) — but some panels insert visible quotes or whitespace that corrupt the value, and some truncate silently. After any DKIM DNS change, verify by sending mail, not by eyeballing the record.
  • An empty p= means revoked. p= with no value is the standard's way of saying "this key is withdrawn" — occasionally left behind by migrations, quietly failing every message still signed with that selector.
  • Content modification between signing and delivery. A footer-appending relay or an over-eager security gateway alters the body after signing → signature invalid. The failure appears at the receiving end, and the DMARC reports are usually how you find out.
  • The signature passes but doesn't count. For DMARC, the signing domain d= must align with the From-header domain. A newsletter tool signing with d=newslettertool.com produces valid DKIM that does nothing for your DMARC. Fixing it means having the tool sign as your domain (their CNAME setup flow) — a five-minute task that turns "authenticated on their behalf" into "authenticated as you".

Checking your work

Send yourself a message at Gmail → "Show original": DKIM: 'PASS' with domain yourdomain.com is the goal — the with domain part being the alignment that matters. The message source shows the full DKIM-Signature: header(s), including d= and s=, which tells you exactly which key on which selector did the work.

The series: SPF explained · DMARC explained · MX records explained · the full picture in Email on Your Own Domain: The Complete 2026 Guide. MailHow signs with rotating dual RSA + Ed25519 keys per domain, records generated for you.