What does dkim=fail (body hash did not verify) mean?

dkim=fail (body hash did not verify) means the hash the receiver computed over the message body does not match the hash the sender stored in the DKIM signature's bh= tag. In plain terms: the body changed somewhere between signing and delivery. A mailing list appended a footer, a gateway rewrote a link, or the content encoding shifted in transit — any of which invalidates the signature even though the DKIM key and DNS record are perfectly fine.

Quick Takeaways

• The bh= tag in a DKIM signature is a hash of the message body, defined by RFC 6376.
• "Body hash did not verify" means the received body no longer matches that hash — the body was altered after signing.
• The most common cause is a mailing list or forwarder adding a footer, disclaimer, or link rewrite.
• It is distinct from a DKIM alignment failure and from a signature (header) failure — this specific error is about the body only.
• Fixes target whatever modifies the body: stop injecting footers, use relaxed canonicalization, or rely on ARC for forwarded mail.
• One failed DKIM signature is not fatal on its own — DMARC can still pass on SPF, provided SPF aligns.

What does "body hash did not verify" actually mean?

When a sending server signs a message with DKIM, it computes a cryptographic hash of the body and puts it in the bh= tag of the DKIM-Signature header, then signs the headers (including that bh= value) with its private key. The receiver does the reverse: it recomputes the body hash from the message it received and compares it to the bh= value the signature carried.

If those two hashes differ, verification stops with body hash did not verify — the receiver does not even need to check the cryptographic signature over the headers, because the body already fails. Per RFC 6376, the body hash is verified first precisely so this class of failure is caught early.

Crucially, this is not a key problem. Your DKIM DNS record, selector, and private key can all be correct and you will still see this error if a single character of the body changed after signing. That is what makes it confusing: every DKIM setup check passes, yet real messages fail. To see whether your failures are body-hash, signature, or alignment related, run a message through Palisade's DKIM checker.

What changes the message body after signing?

Anything that touches the body between the signing server and the recipient breaks the hash. The usual suspects:

• Mailing lists. Discussion lists and listservs commonly append a footer ("You are subscribed as…", unsubscribe links) or a [List-Name] subject tag and body separator. That edit invalidates the original DKIM signature for every message.
• Disclaimer and footer appenders. Corporate mail gateways that stamp a legal disclaimer or confidentiality notice onto outbound mail modify the body after DKIM has already signed it.
• Link rewriting. Security products that rewrite URLs for click-time scanning change the body, and therefore the hash.
• Content-Transfer-Encoding changes. An intermediary that re-encodes the body (for example switching between quoted-printable and base64, or between 7-bit and 8-bit) alters the bytes that get hashed.
• Line wrapping and whitespace. Some MTAs re-wrap long lines or add/strip trailing whitespace, which — depending on canonicalization — can be enough to break the hash.

The common thread: the sender signed one body, the receiver hashed a different one.

How do canonicalization and the l= tag affect the body hash?

Two parts of the DKIM spec decide how forgiving the body hash is.

Canonicalization (RFC 6376) is how the body is normalized before hashing, and DKIM offers two modes for the body:

• simple — almost no tolerance. Any change to the body, including trailing whitespace or extra blank lines, breaks the hash.
• relaxed — ignores insignificant whitespace differences and trailing empty lines. It survives cosmetic reformatting that simple would reject.

If your mail traverses gateways that tweak whitespace, relaxed/relaxed (relaxed for both headers and body) is far more resilient than simple. Most modern signers default to relaxed for exactly this reason.

The l= tag sets a body length count — it tells the verifier to hash only the first N bytes of the body. It was designed to let a footer be appended without breaking the signature, but it is discouraged: an attacker can append arbitrary content after the signed portion and the signature still verifies, so it weakens the protection DKIM is meant to provide. Prefer fixing the thing that modifies the body over papering over it with l=.

How do I fix a DKIM body hash failure?

Work from the most common cause outward:

1. Identify what is modifying the body. Compare a message that failed against what your server sent. Footer text, a disclaimer, a rewritten link, or a re-encoded body points straight at the culprit.
2. Stop injecting content after signing. If your own gateway appends disclaimers or footers, either apply them before DKIM signs, or sign after the modification. The signing step must be the last thing to touch the body.
3. Switch to relaxed canonicalization. If failures come from whitespace or line-wrapping changes, re-sign with relaxed/relaxed. It absorbs the cosmetic edits that simple rejects.
4. For mailing lists, expect the break — and lean on ARC. A list that rewrites the body will invalidate your DKIM no matter what you do on the sending side. Authenticated Received Chain (ARC) lets the list record that your message authenticated on arrival, so the final receiver can trust that chain even though DKIM now fails. The list operator has to add ARC; you cannot.
5. Keep DMARC alignment relaxed. Relaxed alignment gives DMARC the best chance of passing on your remaining aligned identifier when one signature is broken.

How does a body hash failure affect DMARC?

A single failed DKIM signature does not automatically fail DMARC. DMARC passes if either SPF or DKIM passes and aligns with the visible From domain. So if DKIM's body hash fails but SPF passes and aligns, the message can still clear DMARC.

The danger is forwarding. When a message is forwarded or sent through a mailing list, SPF usually breaks too (the forwarder becomes the sending server, so the Return-Path no longer aligns), and now both mechanisms fail — which is exactly when a p=reject policy bounces legitimate mail. This is the scenario ARC was built to rescue, and it is the same reason forwarded mail is a recurring headache in why DMARC fails and how to fix it. It also explains a subtler point covered in why phishing emails can still pass SPF and DKIM: passing authentication and aligning are two different things.

Common issues with DKIM body hash failures

DKIM passes in testing but fails on real mail

Test tools send a message straight from your server to the checker, so nothing modifies the body — everything passes. Real mail traverses gateways, lists, and forwarders that edit the body. If your setup checks pass but production mail fails the body hash, the problem is downstream modification, not your configuration.

Only mailing-list mail fails

This is expected. Lists that add footers or subject tags invalidate DKIM by design. You cannot fix it from the sending side; the list operator needs to implement ARC so the receiver can honor the authentication that existed before the list touched the message.

Failures started after adding a disclaimer or security tool

A new footer appender, disclaimer stamp, or URL-rewriting gateway that runs after DKIM signing will break every signature. Re-order the pipeline so signing happens last, or configure the tool to sign the message itself after it makes its change.

The signature verifies for some recipients but not others

Different receiving providers apply different intermediate processing, and some forwarding paths modify the body while others do not. Inconsistent results across mailbox providers usually point to a specific forwarding hop or gateway in one path, not a problem with your signing.

Frequently asked questions

Is a body hash failure the same as a DKIM alignment failure?

No. Body hash failure means the body changed after signing, so the signature itself is invalid. Alignment failure means the signature is valid but the domain it signed (d=) does not match the visible From domain, so DKIM does not count for DMARC. They have different causes and different fixes.

Can I fix it by adding the l= tag?

You can, but you should not. The l= tag lets appended content through by hashing only part of the body, which opens the door to attackers adding malicious content after the signed portion. Fix the thing modifying the body instead of limiting how much of it is protected.

Does the receiver's server cause the failure?

Rarely the receiver itself — usually an intermediary between you and them (a forwarder, list, or gateway) altered the body. The receiver is simply the first place that recomputes the hash and reports the mismatch.

Will re-sending the email fix it?

Only if the modification was a one-off. If a mailing list, forwarder, or your own gateway systematically edits every message, re-sending reproduces the same failure. Fix the modification source, not the individual message.

Palisade helps teams see this clearly across every client domain: it reads DMARC aggregate reports, separates body-hash failures from alignment and SPF problems, and points at the sending source responsible. Start with the free Email Security Score to check where a domain's DKIM stands today.

Related reading

• What is DKIM? DomainKeys Identified Mail explained
• Why does my DKIM signature fail alignment?
• What is the difference between DKIM and SPF?