Bounce and error codes

dkim=fail (body hash did not verify)

Last updated 2026-08-14

The signature is intact and the key is fine. The body arrived different from the body that was signed, so the hash does not match. Something on the path edited your message.

Where you see it

In OpenDKIM logs it reads body hash did not verify flat out. Either way, the consequence is the same: DKIM contributes nothing to DMARC for that message, and if SPF does not align either you get 550 5.7.509 or a policy rejection at whichever receiver is enforcing.

Causes, most likely first

1. A security gateway or antivirus appliance appending a banner. External sender warnings, disclaimers, scan footers. If it edits outbound mail after your mail server signs it, every message you send is broken and you may not have noticed because most receivers only care when DMARC does.
2. Mailing list software. Footers, [list-name] subject prefixes and link rewriting all change signed content. Nothing you can do at your end beyond making sure the list rewrites the From header.
3. Transport rules or disclaimers in Exchange. A rule that appends HTML to outbound mail runs after signing in some configurations.
4. Link rewriting by a click-protection product at either end. It rewrites URLs inside the body, which is exactly what the hash covers.
5. A relay re-encoding MIME. Converting quoted-printable to base64, or rewrapping long lines, changes the bytes even when the text is identical. This is what relaxed body canonicalization exists to soften, and it only forgives whitespace.
6. Signing the wrong copy. An MTA that signs before a content filter edits, in a multi-hop outbound path where nobody drew the diagram.

Prove which one

1. Does it fail for every recipient, or only some? Every recipient means the break is on your side, before the message leaves. Only list members or only one partner means it is on the path.
2. Send yourself a copy through the same route and diff what arrived against what you sent. A banner, a footer or a rewritten link will be visible to the eye.
3. Read the signature header. The c= tag shows canonicalization, for example c=relaxed/relaxed. The second half is the body. simple is unforgiving of a single changed byte, including trailing whitespace, and switching to relaxed fixes a real subset of these cases.
4. Confirm the key is published and correct with the DKIM checker, using the s= and d= from the header. It should be fine for a body hash failure, and it takes ten seconds to rule out.

Fix

• Sign last. Whatever edits the body should run before the signer. On most gateway products this is a setting, sometimes phrased as signing on the outbound connector rather than at the mailbox server.
• Turn off outbound banner injection for mail leaving your domain, or move it inbound only, which is where those banners are useful anyway.
• Use relaxed/relaxed canonicalization unless you have a reason not to. It tolerates whitespace and line-wrapping changes and costs nothing.
• For lists, rely on the list. A well-configured list rewrites From into its own domain and re-signs. If it does not, the fix is a conversation with the list owner, not a change to your DNS.
• Do not reach for l=. It makes the failure disappear by leaving part of the body unsigned, which is a security hole with a friendly face.

Once it is fixed, the way to confirm at scale is aggregate reports: a source that shows DKIM failing while SPF passes across many messages is a body-modification problem, not a key problem. Reading them is the next step, and our weekly digest flags exactly that pattern.