DKIM, explained: selectors, key sizes and the failures nobody notices

If SPF is a guest list, DKIM is a wax seal. Every email you send gets a cryptographic signature stamped into its headers; receivers fetch your public key from DNS and verify the seal is intact. If the message was tampered with in transit — or never came from you at all — the seal breaks.

Unlike SPF, DKIM survives forwarding. The seal travels with the message, no matter which servers relay it. That’s why receivers weight it heavily, and why Google, Yahoo and Microsoft all require it from bulk senders.

What actually gets signed

Your sending server takes selected headers (From, Subject, Date…) plus a hash of the body, signs them with a private key only it holds, and adds the result as a DKIM-Signature header. The receiver looks up the matching public key in your DNS and checks the math. Pass means two things at once: the message wasn’t modified, and whoever sent it controls the DNS of the signing domain.

The tag-by-tag breakdown

A real DKIM-Signature header looks dense, but every tag has one job:

Tag	Meaning
v=	Version — always 1 for the current spec.
a=	Signing algorithm, almost always rsa-sha256 (Ed25519 shows up as ed25519-sha256).
d=	The signing domain — this is what DMARC checks for alignment against the From: address.
s=	The selector — which key under that domain signed this message.
h=	The list of headers actually signed, in order — From, Subject, Date, To are typical.
bh=	The body hash — a hash of the message body, so any edit to the body breaks verification.
b=	The signature itself, over the headers listed in h= plus bh=.

The h= and bh= tags are where most confusing DKIM failures live. Only the headers listed in h= are covered by the signature — if Subject isn’t listed, someone could theoretically change the subject line in transit without breaking DKIM. Reputable senders always sign From, Subject, Date and To at minimum; a signature that omits From is not one you should trust.

Why “canonicalization” quietly breaks signatures

DKIM has to survive the reality that mail servers rewrite small things in transit — a trailing newline added, whitespace normalized. The spec handles this with canonicalization, declared in the c= tag as header/body, each side either simple (byte-for-byte, no tolerance) or relaxed (tolerates whitespace changes, header case changes). Most modern senders use relaxed/relaxed for exactly this reason: a strict simple signature breaks if literally one server in the delivery path touches a single space, which is common and usually harmless. This is also why a mailing list or forwarder that adds a footer to the body — even one line — breaks the bh= body hash outright, regardless of canonicalization mode: the body genuinely changed, so the seal correctly reports that it did. That’s expected behavior, not a bug, and it’s the main reason forwarded mail relies on DMARC’s SPF fallback or ARC rather than DKIM alone.

Selectors: how one domain holds many keys

Look at a real DKIM-Signature header and you’ll find two tags that matter:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...

• d= is the signing domain.
• s= is the selector — a label that points at one specific key.

The receiver combines them and queries mail2026._domainkey.yourdomain.com for the public key. Selectors exist so a domain can hold many keys at once: one per provider, one per key rotation, old and new overlapping during a changeover.

Don’t know your selector? Send yourself an email and read the s= tag in the signature header — our Email Header Analyzer pulls it out for you, along with the SPF/DKIM/DMARC verdicts on that message. Once you have the selector, our DKIM Record Checker fetches the published key and tells you what you’re actually working with.

Key size: 1024 bits is on borrowed time

DKIM keys are mostly RSA, and RSA strength is all about length:

• 512 bits — factorable on rented hardware for pocket money. Was used to forge signed mail from real companies over a decade ago. If you find one of these, treat it as an incident.
• 1024 bits — the long-standing default, now the floor. Still common because rotating keys is friction, but the industry guidance has moved on, and “we kept the old key because rotating is annoying” is not a sentence you want in a postmortem.
• 2048 bits — the current standard. Set it and forget it for years.

There’s also Ed25519, a newer, smaller, faster signature scheme the RFC supports — elegant, but receiver support is still uneven, so the practical play in 2026 is RSA-2048, optionally dual-signing with Ed25519.

The catch: you can’t tell key strength by looking at the DNS record — it’s a wall of base64 either way. The DKIM Checker measures the real key strength with WebCrypto, in your browser, and flags anything below 2048.

Generating and rotating keys

Need a key pair? Our DKIM Generator creates one in your browser — the private key never touches our servers, which is exactly how you should treat private keys generally. Publish the public half under a new selector, configure the private half in your sender, and once mail flows with the new signature, delete the old selector’s record.

Rotation cadence: every 6–12 months is the common guidance. The mechanism is painless precisely because selectors let old and new keys coexist during the switch.

Failures nobody notices until deliverability drops

DKIM either passes or fails — there’s no partial credit — which means the failures that hurt you are the ones that stay silent until something else forces you to look:

• Multiple signatures, one dead. A message can carry more than one DKIM-Signature header (e.g., a marketing tool’s plus your own custom domain’s). Receivers generally accept the message if any signature passes — so a broken custom-domain signature can hide behind a working vendor one for months. DMARC alignment is what actually exposes it, because alignment cares which domain’s signature passed, not just whether one did.
• Selector DNS record quietly deleted. Someone cleans up “unused” DNS records during a migration, doesn’t recognize mail2026._domainkey.yourdomain.com as load-bearing, and removes it. Every message signed with that selector starts failing DKIM the moment the record disappears — with no error visible anywhere except the receiver’s side.
• Subdomain vs. root domain mismatch. A signature with d=mail. yourdomain.com doesn’t automatically align with mail claiming to be from yourdomain.com under DMARC’s default (non-relaxed) alignment mode — a detail that trips up anyone running a subdomain-based sending setup without checking the alignment mode explicitly.
• A provider’s default key, not yours. Covered below, but worth repeating as a failure mode: everything passes DKIM, so nothing looks broken. It’s only failing the specific job you needed it for — DMARC-aligned authentication under your own domain.

The alignment detail that bites later

For DMARC (the policy layer on top), the d= domain in your DKIM signature must match the From: domain your recipient sees. Plenty of providers sign with their domain by default — the seal is valid, but it’s their seal, not yours, and DMARC won’t count it. When you set up any sending tool, do the custom-domain DKIM step. It’s always there, usually under “advanced,” always worth it.

Where does this leave you? Twenty minutes of setup: generate or request a 2048-bit key, publish it under a clean selector, verify with the checker, confirm alignment. Then it’s infrastructure — and you can spend your attention on the part of email that actually needs it: what you write.