How do you fix “dkim=fail (body hash did not verify)”?

Updated July 3, 2026

This error means the message body was modified after your server signed it: the hash the receiver computes no longer matches the hash in your DKIM signature, so the signature is rejected.

Why this happens

DKIM works by hashing the message body at signing time and storing that hash in the DKIM-Signature header. The receiver re-hashes the body on arrival and compares. If even one character changed in between (an added footer, a rewrapped line, a rewritten link), the hashes differ and DKIM fails, no matter how correct your DNS setup is.

The usual culprits sit between you and the recipient: mailing lists that append “unsubscribe” footers, security gateways and appliances that rewrite links or add disclaimers, and forwarders that re-encode attachments. Your own stack can do it too: an outbound gateway that adds a compliance banner after your application server has already signed the message.

Canonicalization makes it worse. If you sign with “simple” canonicalization, even harmless changes like whitespace normalization or line-ending conversion break the hash. “Relaxed” canonicalization tolerates those cosmetic changes, but many setups still default to simple.

How to fix it

  1. 1

    Confirm it's a body hash problem, not a DNS problem

    Check the Authentication-Results header on a failing message. “body hash did not verify” means the public key was found and the signature parsed. DNS is fine. The body simply isn't what it was when signed.

  2. 2

    Find what's modifying the message

    Send a test to a mailbox you control and diff the received body against what you sent. Look for appended footers, disclaimers, rewritten links, or re-encoded content. Trace the message path: mailing list, security appliance, outbound gateway, forwarding rule.

  3. 3

    Switch to relaxed/relaxed canonicalization

    Set c=relaxed/relaxed in your signer configuration. This makes the signature survive whitespace and line-ending changes that break simple canonicalization. It won't survive real content changes, but it eliminates the flakiest failures.

  4. 4

    Sign after the last modification

    If your own infrastructure adds banners or disclaimers, move DKIM signing to the final hop before mail leaves your control: the outbound gateway, not the application server. Whatever touches the body last should be the thing that signs, or nothing after the signer may touch the body.

  5. 5

    Don't sign headers that get rewritten

    Some gateways rewrite Subject or Content-Type. Exclude volatile headers from the h= list in your signer so a rewritten header doesn't invalidate the signature. Keep From, which must always be signed, plus stable headers like Date and Message-ID.

  6. 6

    Verify the fix

    Send fresh test messages through the full production path, including any gateway, and confirm dkim=pass in the Authentication-Results header at the destination. Then run your domain through our DKIM checker to confirm the published key still matches your selector.

Verify the fix

Run the check that corresponds to this error. You'll see the same red/amber/green verdicts mailbox providers effectively apply.

Open the DKIM checker →

Preventing it next time

Body hash failures tend to appear when someone adds a new gateway or a compliance banner and nobody re-tests DKIM. DMARCPath reads your aggregate reports and flags when DKIM pass rates drop for a source that used to pass, so you spot the broken hop within a day, before your customers start seeing your mail in spam.

Frequently asked questions

My DKIM record is correct, so why does DKIM still fail?
Because “body hash did not verify” isn't a DNS error. The receiver found your key and validated the signature format; the body just changed after signing. The fix is in your mail path, not your DNS.
Will relaxed canonicalization fix mailing list failures?
Usually not. Mailing lists add real content (footers, subject tags), which changes the body hash under any canonicalization. That's what ARC and DMARC's DKIM-or-SPF logic exist for; lists that rewrite content should re-sign as their own domain.
Does one dkim=fail mean my mail gets rejected?
Not by itself. DMARC passes if either aligned SPF or aligned DKIM passes. But if the same hop that breaks DKIM also breaks SPF alignment, like forwarding does, the message fails DMARC and your policy decides its fate.

Catch this before your customers do

DMARCPath watches your domain's authentication continuously and alerts you the day something breaks, not the week a customer mentions your emails stopped arriving. One domain free.

Start monitoring free →