Why DKIM fails
DKIM is a cryptographic check, so it has no middle setting: the signature verifies or it does not. That makes failures easier to diagnose than they look, because the list of things that can go wrong is short. Almost every real-world DKIM failure is one of six causes.
Two of them are not really failures at all — they are the system working correctly.
1. The message was never signed
The most common "DKIM failure" is the absence of a signature. A platform that was never configured for DKIM sends unsigned mail; a receiver has nothing to verify and reports dkim=none. DKIM not signed at all is a different condition from a DKIM signature invalid, and they need different fixes.
This looks identical to a broken signature in a summary view, but it is a completely different problem — nothing is misconfigured, something is simply missing. In How to read a DMARC report, none and fail are separate results for exactly this reason.
Fix: enable DKIM at that platform and publish its selector record. Each sender needs its own — see What is a DKIM selector?.
2. The selector record is missing or wrong
The signature names a selector; the receiver builds <selector>._domainkey.<domain> and fetches the key. If that record does not exist, is truncated, or contains a different key than the one that signed, verification fails at the first step.
Classic causes: the record was pasted into DNS with a line break inside the key, the provider rotated to a second selector that was never published, or a migration changed the selector and the old record is still sitting there doing nothing.
3. The message was modified in transit — usually a mailing list
DKIM signs the body and a chosen set of headers. Change any of it and the seal breaks, which is the entire point of a seal.
Mailing lists do this deliberately: a [list-name] tag prepended to the subject, an unsubscribe footer appended to the body. Both are signed content, so the signature no longer matches and the receiver reports a body hash failure. Some appliances and "email security" gateways do the same by inserting a banner into the body.
This is DKIM succeeding, not failing. It detected a modification, which is what you asked it to do. Mailing lists work around it by rewriting the From header so DMARC is evaluated against the list's own domain. There is nothing to fix on your side; the detail is in Why SPF fails on forwarded mail, which covers the list case too.
4. The DKIM body hash did not verify (bh=)
A bh= mismatch is the most literal failure in the list. A DKIM signature carries two hashes: one over the body (bh=) and one over the selected headers. When a report or a header says the body hash failed, the body changed — the key is fine and DNS is fine.
Beyond mailing lists, this is worth knowing:
- Trailing whitespace and line endings. The
relaxedcanonicalisation tolerates ordinary whitespace changes;simpletolerates almost nothing. A relay that rewrites line endings can break asimplesignature and leave arelaxedone intact. - Content rewriting. Link-tracking gateways that rewrite URLs after signing break every signature they touch.
5. The key is too weak, or the record is malformed
Receivers reject keys they consider unsafe. A 512-bit key will not be accepted anywhere; 1024-bit is accepted today but is the old default rather than a good one. A key with stray characters, a missing p= tag, or an empty p= (which explicitly means revoked) fails the same way.
Length and rotation are covered in DKIM key length and rotation.
6. DKIM temperror — DNS did not answer
If the DNS lookup for the selector times out, the result is temperror, not fail. It means "ask again later", and receivers usually do. A handful in a report is noise; a persistent pattern from one receiver points at your DNS provider rather than at DKIM.
The failure that is not a failure: passing but unaligned
This one deserves its own section because it is the most misread result in the whole system.
The signature verifies. The report says dkim=pass. DMARC still fails.
That happens when the signature's d= domain is not your domain — your marketing platform signed with mailer.provider.example and the seal is genuinely valid, for the provider. DMARC requires the passing check to be aligned with the domain in the visible From address, and this one is not.
| What you see | What it means |
|---|---|
dkim=none | Nothing was signed |
dkim=fail | A signature exists and did not verify |
dkim=pass, DMARC fail | Valid signature, wrong domain — alignment |
The fix is never "fix DKIM" — it is to complete the platform's domain authentication so it signs as you. The rule is set out in DMARC alignment explained.
Narrowing it down
- Is anything signed at all? Send yourself a message from that platform and look for a
DKIM-Signatureheader. No header means cause 1. - Does the selector resolve? Take
s=andd=from the header and look up<s>._domainkey.<d>. Nothing there means cause 2. - Does it fail only for some recipients? Mailing lists and forwarding gateways — causes 3 and 4.
- Does it pass but DMARC still fails? Alignment, not DKIM.
The per-source view makes step 3 quick, because it shows which senders fail for everyone and which fail only somewhere: Sending sources, grouped by provider.