DKIM glossary
What does dkim=fail mean and how do you fix it?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
dkim=fail is the receiver's Authentication-Results verdict that a message's DKIM signature did not verify. Common causes: the body was modified in transit (a broken body hash), the DNS public key is wrong or truncated, or the selector doesn't match a published key. DMARC can still pass on aligned SPF, so dkim=fail isn't always fatal.
dkim=fail at a glance | |
|---|---|
| Tag | dkim (Authentication-Results) |
| Valid values | pass · fail · none · neutral · temperror · permerror |
| Default | Reported by the receiver — not something you set. fail means the signature didn't verify. |
| Where it goes | In the Authentication-Results header the receiving server adds, e.g. dkim=fail. |
How dkim=fail works
dkim=fail is the receiver's verdict, written into the Authentication-Results header, that a message's DKIM signature did not verify. It doesn't say why — that's the triage job — only that the signature the message carried didn't check out against the published key.
Work the usual causes in order. First, the body was modified in transit, breaking the body hash — the single most common cause. Next, the DNS public key is wrong, truncated, or revoked. Then a selector mismatch or a missing key record, so the receiver can't find a key at all. Finally, a gateway or list rewriting content after signing. The related links below drill into each.
One thing dkim=fail does not always mean: disaster. DMARC passes if either SPF or DKIM aligns, so a message can fail DKIM and still pass DMARC on an aligned SPF result — and the reverse happens too. Read dkim=fail alongside the SPF and DMARC results, not on its own.
Correct record vs common mistake
Correct
Authentication-Results: mx.example.com; dkim=pass header.d=example.comThe signature verified and the signing domain is shown. This is the result you want — pair it with an aligned d= so DMARC passes on DKIM.
Common mistake
Authentication-Results: mx.example.com; dkim=fail (body hash did not verify) header.d=example.comThe receiver couldn't verify the signature — here the body hash failed, meaning the body changed after signing. Trace the mail flow that modified it.
Troubleshooting dkim=fail
| Issue | Likely cause | Fix |
|---|---|---|
| dkim=fail with 'body hash did not verify' | The body changed after signing — footer, disclaimer, or encoding rewrite | Stop the gateway or list from altering the body, or have it re-sign the message |
| dkim=fail with 'no key for signature' | The selector has no published key, or the key was revoked or truncated | Publish or repair the key at <selector>._domainkey.<domain>, unbroken |
| dkim=fail but the mail is genuine | Forwarding or a list broke the signature, yet SPF may still align | Confirm DMARC via aligned SPF; fix DKIM signing so both legs pass where possible |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
Why it matters for MSPs
dkim=fail across a client base is rarely one root cause — it's body-modifying gateways on one tenant, a truncated key on another, a stale selector on a third. Without per-domain report visibility, these blur into 'DKIM is flaky' and block you from confidently moving any domain to reject.
Trusted by MSPs
“We increased our meetings booked by 21% and slept better at night knowing our emails are now secured”
Marc-André Campagna — CEO, gaiia (YC 2021)Read the case study →
Enforce it — don't just monitor it
Palisade turns raw dkim=fail results into per-sender diagnosis across every client domain — separating broken body hashes from bad keys from stale selectors — so each legitimate source is fixed and aligned before the domain is advanced to reject.
Free 15-day trial · No credit card · Your own domain free forever (NFR)