Defaults.Exposed › Taisymai › Guides

'DKIM Signature Not Valid' — The Causes, in the Order to Check Them (2026)

Paskelbta 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

“DKIM signature not valid” has five common causes, best checked in order: content modified in transit, a truncated key record, a published key that doesn’t match the signer, the wrong selector, and fragile canonicalization. Only 10,092,481 of 261,086,232 graded domains (3.87%) hold the full SPF + DKIM + enforcing-DMARC triad, according to the Defaults.Exposed census (2026-06-29).

The fix order matters because the most common cause isn’t in your DNS at all. Check what changed the message in transit first, then work inward: the key record’s integrity, whether it matches what your mail server is actually signing with, the selector, and finally the signing settings. Most invalid signatures are fixed at step one or two.

What does “DKIM signature not valid” actually mean?

Every DKIM-signed message carries a DKIM-Signature header naming a domain (d=), a selector (s=), a hash of the message body (bh=), and a cryptographic signature over the body hash plus selected headers (b=). The receiver fetches your public key from DNS at <selector>._domainkey.<domain>, recomputes both hashes, and checks the signature (RFC 6376). “Signature not valid” is checker- and header-speak for: that verification ran and failed — the key was found, but the maths didn’t come out.

That last clause is the diagnostic gold. A verifier that can’t find your key says something different — typically a header like dkim=fail (no key for signature) — and that’s a selector problem, covered in DKIM “no key for signature” — selector and rotation fixes. And a verifier that recomputes a different body hash usually says so explicitly: body hash did not verify — Microsoft reports it as dkim=fail (body hash did not verify), while Gmail often renders the same diagnosis as dkim=neutral (body hash did not verify). Either way it points at content modification, covered in “body hash did not verify” — what changed your message. Read the exact wording in the Authentication-Results header before touching anything: it tells you which of the five causes you’re holding.

Getting this right is rare: only 51.84% of graded domains publish a discoverable DKIM key in DNS at all, according to the Defaults.Exposed census, and only 3.87% of 261 million graded domains combine SPF, DKIM and an enforcing DMARC policy — the configuration the bulk-sender rules now assume. The stage-by-stage picture is in the SPF adoption maturity model.

What are the five causes, in order?

Cause 1 is bolded because it breaks signatures on messages that were signed perfectly. A security gateway appends a disclaimer, a compliance footer gets stamped on after signing, a mailing list adds [listname] to the subject — the body or signed headers change, the hashes no longer match, and the signature is invalid through no fault of your DNS. If failures correlate with mail that passed through a gateway, a list, or an archiving hop, start there.

How do I fix “DKIM signature not valid”?

1. Run the free scan at defaults.exposed before touching DNS. It shows whether your published key record is present, well-formed and complete — separating “your DNS is broken” (causes 2–4) from “your DNS is fine, the message is being changed” (cause 1) in one step.
2. Read the Authentication-Results header of a failing message. body hash did not verify → cause 1, go to the body-hash guide — the usual suspects are gateway footers and disclaimers, and the fix is to sign after modification. no key for signature → cause 4, go to the selector guide. A plain signature failure → continue.
3. Check the published key for truncation. Look up <selector>._domainkey.<yourdomain> as TXT (dig TXT selector._domainkey.example.com). A 2048-bit RSA public key is longer than the 255-character limit of a single TXT string, so it must be published as multiple quoted strings that receivers concatenate — and DNS-provider web UIs are notorious for silently truncating the paste, mangling the split, or injecting whitespace and quotes into the p= value. Compare character-for-character with the key your signer generated; our DKIM setup walkthroughs cover the per-provider quirks.
4. Confirm the published key matches the signer. After a key rotation, provider migration, or ESP reconnect, it’s common for the signer to hold a new private key while DNS still serves the old public key — every signature verifies against the wrong key and fails. Re-copy the current record from your provider’s admin console. Better: where the provider offers CNAME delegation, use it — the provider rotates keys on their side and this whole class of failure disappears. And never delete an old selector until traffic signed with it has drained.
5. Fix the signing settings, not just the record. Set canonicalization to c=relaxed/relaxed, which tolerates the whitespace re-wrapping and header re-folding that intermediate servers legitimately do; simple canonicalization fails on changes a human can’t even see. And do not use the l= body-length tag: it was meant to let footers through, but it lets anyone append content to your signed message without breaking the signature — a real attack vector — and it still doesn’t survive most gateway modifications. No l= is both the safer and the more reliable choice.
6. Re-scan, then check alignment. A valid signature only helps DMARC if the d= domain aligns with your From domain — a signature that validates as d=yourcompany.gappssmtp.com passes DKIM and still fails DMARC. If that’s you, see the default-signature trap, then work through anything else the scan flags on the fix DKIM page.

Frequently asked questions

Is “DKIM signature not valid” the same as “body hash did not verify”? The body-hash message is one specific sub-case: the body changed after signing (footers, disclaimers, list rewrites). “Signature not valid” is the umbrella verdict for any failed verification, including bad keys and header changes — which is why step 2 above is reading the header, and why the body-hash case has its own guide.

Does an invalid DKIM signature mean my mail is being rejected? Not by itself — receivers treat a broken signature like a missing one. The damage lands via DMARC: if SPF doesn’t pass with alignment either, the message fails DMARC and your published policy applies. As of the 2026-06-29 census, only 3.87% of 261,086,232 graded domains hold SPF, DKIM and an enforcing DMARC policy together — but Gmail and Microsoft now expect exactly that from senders, so a broken DKIM leg costs deliverability even before rejection.

Should I use a 1024-bit or 2048-bit DKIM key? 2048-bit — 1024-bit keys are below current cryptographic recommendations and some receivers score them down. The catch is purely operational: a 2048-bit key doesn’t fit in one 255-character TXT string, so it must be split correctly (cause 2 above). CNAME delegation to your provider sidesteps the splitting problem entirely.

My DKIM passes on a checker but DMARC still fails — how? Almost certainly alignment: the signature validates, but its d= domain (say, yourcompany.gappssmtp.com or yourtenant.onmicrosoft.com) doesn’t match your From domain, so DMARC can’t use it. Enable your provider’s custom-domain signing — the full walkthrough is in the default-signature trap guide.

Can I just turn DKIM off if it keeps failing? No — since the 2024 bulk-sender mandates, Gmail and Yahoo require DKIM for volume senders, and an enforcing DMARC policy realistically needs DKIM because SPF alone breaks under forwarding. Fix the signature; the causes above are all fixable in an afternoon.

Send the owner the report

If you’re fixing this for a client or your employer, close the loop with evidence. Re-run the free scan after your changes and forward the graded report to the business owner: dated, plain-language, DKIM showing green. It’s the artefact they’ll need for the cyber-insurance renewal and the next supplier security questionnaire — the difference between “I fixed a DNS thing” and a documented before-and-after that says the domain authenticates its mail.

Check your domain → · “Body hash did not verify” guide → · Fix DKIM → · How we grade → · Aggregate data only. Data stored and processed in the EU.