"Body Hash Did Not Verify" Error: Causes and Fixes

You're looking at your email authentication results and see a DKIM (DomainKeys Identified Mail) failure with a specific message: "body hash did not verify." Unlike a generic DKIM failure, this error tells you something very precise: the email's body was changed after your mail server signed it.

In plain language: your server created a cryptographic fingerprint of the email body, attached it to the message, and sent it on its way. Somewhere between your server and the recipient, something altered the body. When the receiving server computed its own fingerprint and compared the two, they didn't match. The signature is broken, and DKIM fails.

This is frustrating because it usually means your DKIM configuration is actually correct. Your keys are fine. Your DNS record is fine. The problem is something in the delivery pipeline modifying your email after it leaves your server.

What Is a Body Hash?

Every DKIM signature includes a bh= tag that contains a hash (cryptographic fingerprint) of the email body at the moment of signing. Here's what it looks like inside a DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector;
  h=from:to:subject:date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=LiKe9x2...

The bh= value is a SHA-256 hash of the message body. When the receiving mail server gets your email, it computes its own hash of the body it actually received. If the two hashes match, the body is unchanged. If they don't, something altered the content in transit, and you get "body hash did not verify."

Why This Error Happens

The body hash fails because the message body was modified after signing. Here are the five most common causes.

1. Email Modified by Mailing Lists or Forwarding Services

This is the most frequent cause. Mailing list software like Mailman, Listserv, or Google Groups routinely appends content to messages (unsubscribe links, list footers, legal disclaimers, or reply instructions). Forwarding services may add headers into the body, reformat HTML, or change encoding. Any of these modifications invalidate the body hash.

If your DKIM failures happen only when sending to mailing lists or forwarded addresses but pass on direct delivery, this is almost certainly the culprit.

2. Antivirus or Spam Filters Modifying Content

Organizations often route email through security gateways that scan and alter messages. Common modifications include rewriting URLs to "safe link" versions, stripping or quarantining attachments flagged as risky, inserting safety warnings or banners, and sanitizing HTML elements. If these tools process your email after DKIM signing, the body hash breaks.

3. Character Encoding Changes

This one is subtle. Intermediate mail servers sometimes re-encode message bodies, converting between quoted-printable and base64, changing character sets, or normalizing Unicode. The visible text may look identical to a human reader, but the underlying bytes are different, and the hash no longer matches.

4. Line Ending Normalization Issues

Email standards specify CRLF (carriage return + line feed) line endings, but not all systems comply. If an intermediate server converts line endings from LF to CRLF or vice versa, the body bytes change. With simple canonicalization, even this minor difference breaks the hash.

5. The l= Tag Limiting Body Signing

Some DKIM implementations use the l= (lowercase L) tag to specify a body length limit, telling verifiers to only hash the first N bytes of the body. While this was intended to tolerate appended content, it creates a serious security vulnerability: an attacker could append malicious content to a signed message without breaking the signature. If your l= value is set incorrectly or the body is shorter than expected, it can cause unexpected hash mismatches.

Cause, Symptom, and Fix at a Glance

How to Diagnose the Problem

Fixing the Problem

Reorder your outbound email pipeline

If your own systems are modifying messages after signing (a disclaimer tool adding footers, a security gateway rewriting links), change the processing order. DKIM signing should be the last step before email leaves your infrastructure. Move all content-modifying tools upstream of the DKIM signer.

Switch to relaxed canonicalization

DKIM supports two canonicalization algorithms: simple and relaxed. Relaxed mode normalizes whitespace and is more tolerant of minor formatting changes. While it won't fix major content modifications (appended footers, rewritten URLs), it eliminates failures caused by trivial whitespace or line-ending differences.

Update the c= tag in your mail server's DKIM configuration from simple/simple to relaxed/relaxed. This is recommended as the default for most deployments.

Configure mailing lists to re-sign

If you manage the mailing list that's causing failures, configure it to strip the original DKIM signature and re-sign with the list's own key. Modern list software supports this. If you don't control the list, ARC (Authenticated Received Chain) helps. It lets intermediate servers vouch for the original authentication results.

Ensure complete email authentication

Body hash mismatches on forwarded mail may be unavoidable. This is a known DKIM limitation. Protect yourself by having all three authentication protocols in place. Check your SPF at spfrecordcheck.com and your DMARC at dmarcrecordchecker.com. When one protocol fails due to forwarding, the others can still verify your identity.

Preventing Body Hash Mismatches

Once you've resolved the immediate issue, take steps to prevent recurrence:

• Audit your email pipeline. Map every system that touches outgoing email. Confirm that DKIM signing happens last in the chain.
• Use relaxed/relaxed canonicalization. There's almost never a reason to use simple mode. Relaxed is more robust and widely supported.
• Remove any l= tag. If your DKIM configuration includes a body length limit, remove it. The security risk outweighs the benefit.
• Monitor your DKIM results. Use deliverabilitychecker.com to track authentication results continuously. Catch new failures before they damage your sender reputation.
• Test after pipeline changes. Any time you add a security tool, change forwarding rules, or modify your email infrastructure, send a test email and verify DKIM passes.

Monitor Your DKIM Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.