DKIM Verification Failed: dkim=fail and Body Hash Mismatch

Problem

The email is signed. You can see the DKIM-Signature header. And the receiver still reports dkim=fail. The signature was valid the moment it left your server — but something between you and the recipient changed the message, or the public key the receiver fetched no longer matches the one that signed it.

DKIM does not check whether an email is “good.” It checks one narrow thing: that the signed parts of the message arrived byte-for-byte the way they were signed, using a key published in DNS. When any of that drifts, verification fails — even though nothing was malicious.

Symptoms

• Authentication-Results shows dkim=fail, often with (body hash did not verify).
• DKIM passes in a pre-send test but fails once the message goes through a list or forwarder.
• dkim=none appears even though you believe the message is signed.
• DKIM verifies, but DMARC still reports failure.

Top 3 Causes

1. The body was modified after signing — A mailing list, forwarder, or corporate gateway appended a footer, rewrote a link, or changed the content encoding. The bh= body hash no longer matches, so the signature fails. This is the single most common cause.
2. The public key is missing, rotated, or revoked — The receiver fetches the key from selector._domainkey.yourdomain using the s= selector in the signature. If that TXT record was never published, points to an old key after rotation, or has an empty p= value (a deliberately revoked key), verification fails or returns no signature.
3. DKIM passes but does not align for DMARC — The signature verifies against a d= domain that is not the From domain. Under DMARC, a passing DKIM signature only helps if d= aligns with the visible From: header — strict alignment requires an exact match, relaxed allows the same organizational domain.

Diagnose with DechoNet

• Email Header Analyzer to read the actual Authentication-Results, see whether the result is fail vs none, and trace which hop modified the message.
• Email Deliverability Test to confirm whether a DKIM key is detectable for common selectors on your domain.
• DNS Lookup to verify the selector._domainkey TXT record exists and serves the key you expect.

Resolution Checklist

• Read the result precisely: fail means a broken signature, none means no signature. Fix the right problem.
• If the result is body hash did not verify, look for something rewriting the body — list footers, disclaimer appenders, link rewriters, or a changed Content-Transfer-Encoding.
• Confirm the selector in the DKIM-Signature (s=) actually resolves to a published key at selector._domainkey.yourdomain.
• After any key rotation, verify the new public key is published before retiring the old selector.
• Check that the signing domain (d=) aligns with the From domain if DMARC matters to you.
• Avoid the l= body-length tag. RFC 6376 §8.2 warns it lets an attacker append unsigned content past the signed length while DKIM still passes — many verifiers distrust signatures that use it.
• Re-test by sending through the real delivery path, not just a local check, since modification usually happens in transit.

When to Escalate

• Escalate to the mailing list or forwarding operator if their platform rewrites the body. The clean fix is for the list to re-sign with its own key and publish DMARC for the list domain — you cannot fix this from the sending side.
• Escalate to your email provider or DNS administrator if the selector record is missing, stale after rotation, or you cannot control which key is published.