Is 'body hash did not verify' a sign of tampering or attack?

Almost never in practice — the mundane explanations (footers, gateways, lists) cover nearly all cases. But the failure is doing its job either way: the message you received provably isn't the message that was signed.

Does this failure hurt my deliverability?

It can. A failed DKIM signature contributes nothing to DMARC, so those messages ride on SPF alignment alone — which breaks under forwarding. If the modification happens on your side, every recipient sees a failed signature, and consistent DKIM failure is a negative reputation signal.

What's the difference between this and a 'signature did not verify' error?

Signature verification failure means the signed headers or the key don't check out (wrong/rotated DNS key, malformed signature). Body hash failure specifically isolates the change to the message body — the headers and key were fine.

DKIM "body hash did not verify" — what it means and how to fix it

When DKIM verification reports body hash did not verify, the cryptography is telling you something precise: the message body that arrived is not the body that was signed. The signature itself is fine, the DNS key is fine — the content changed somewhere between signing and delivery. The fix depends on who's changing it.

Updated July 13, 2026

How the body hash works

When a server DKIM-signs a message, it hashes the body and stores that hash in the signature header (the bh= tag). The receiver recomputes the hash on arrival; any difference — one character, one whitespace change depending on canonicalization — and verification fails with exactly this error.

The usual suspects, in order of likelihood

A footer-appending gateway: security appliances and compliance tools that add disclaimers ("This email originated outside the organization") after signing. The classic cause inside companies.
Mailing lists that add footers or subject tags — well-known DMARC breakers; modern lists rewrite the From header to compensate.
Link-rewriting security services (URL sandboxing) that modify message bodies on the way out rather than the way in.
Signing with simple body canonicalization: c=relaxed/simple makes even trivial whitespace changes fatal. relaxed/relaxed tolerates them.
A broken sending pipeline that modifies content after the DKIM signing step — wrong middleware order.

How to fix it

First, confirm the diagnosis: paste the delivered message's raw headers into our header analyzer and check which hop added or modified content (compare Received chains against where the DKIM signature was added). Then:

If your own gateway modifies mail: reorder so DKIM signing is the last step before the internet, or have the gateway re-sign after modification.
If it's outbound link-rewriting: same rule — modify first, sign second.
If you control the signer: use c=relaxed/relaxed canonicalization so cosmetic changes don't break the hash.
If it's third-party forwarding or mailing lists: you can't fix their modification — you rely on DMARC needing only one aligned pass, which is why your direct mail should always be signed correctly.

How the body hash works

The usual suspects, in order of likelihood

How to fix it

Common questions