DKIM Body Hash Errors: Causes and Fixes

"Body hash did not verify" is one of the most common DKIM failures. It means the email body changed after the sending server signed it. The receiving server hashed the body it received, compared it to the bh= value in the DKIM-Signature header, and the two didn't match.

This article explains exactly what body hash verification is, why it fails, and how to fix it.

What Is the Body Hash?

When a sending server signs an email with DKIM, it computes a hash (digest) of the message body and stores it in the bh= tag of the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=...

The bh= value is a Base64-encoded SHA-256 hash of the canonicalized message body. When the receiving server gets the email, it:

1. Canonicalizes the body using the method specified in c=
2. Hashes the result with the algorithm from a= (typically SHA-256)
3. Compares its computed hash to the bh= value

If they don't match, you get: body hash did not verify.

Why Body Hash Verification Fails

The root cause is always the same: the body the receiver sees is different from the body the sender signed. Here are the most common reasons.

1. Mailing List Footer Additions

Mailing list software (Mailman, Google Groups, LISTSERV) commonly appends footers like unsubscribe links to every message. This changes the body after the original sender signed it.

Example:

--- Original signed body ---
Hello team, please review the attached proposal.

--- Footer added by mailing list ---
--
To unsubscribe, visit: https://lists.example.com/unsubscribe

The appended footer changes the body hash. This is the single most common cause of body hash failures.

2. Email Forwarding with Modifications

Forwarding services may alter the message body by:

• Adding forwarding notices ("Forwarded message from...")
• Wrapping the original content in a new MIME structure
• Converting plain text to HTML or vice versa

3. Antivirus and Security Gateway Modifications

Corporate email security appliances and antivirus scanners may:

• Append virus scan results ("This email was scanned by...")
• Strip or modify attachments
• Rewrite URLs for safe link checking
• Add disclaimer banners

4. Encoding Changes

Intermediate mail servers may change the content transfer encoding:

• Converting quoted-printable to base64 or 7bit
• Changing line endings from \r\n to \n or vice versa
• Re-encoding character sets

5. HTML Sanitization

Some relay servers clean up HTML content by:

• Removing <script> tags
• Stripping inline styles
• Rewriting <img> URLs
• Normalizing HTML structure

6. Content-Length Truncation

Some mail servers enforce body size limits. If the body is truncated after signing, the hash will not match.

How Canonicalization Affects Body Hash

The c= tag in the DKIM-Signature header specifies how the body is normalized before hashing. The body canonicalization mode (the value after the slash) directly impacts body hash resilience.

Simple body canonicalization (c=.../simple):

• Only ignores trailing empty lines at the end of the body
• All other content must be byte-for-byte identical
• Very fragile — even a single added space will break the hash

Relaxed body canonicalization (c=.../relaxed):

• Reduces sequences of whitespace to a single space
• Removes trailing whitespace from each line
• Ignores trailing empty lines at the end of the body
• More tolerant of minor transit modifications

Relaxed canonicalization helps with whitespace issues but cannot save you from content additions, encoding changes, or structural modifications.

How to Diagnose Body Hash Errors

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.d=example.com header.s=selector1

How to Fix Body Hash Errors

Switch to Relaxed Canonicalization

If you're using simple body canonicalization, switch to relaxed:

# Before
c=simple/simple

# After
c=relaxed/relaxed

This won't fix content additions, but it will eliminate failures caused by whitespace changes.

Disable Body Modifications in Transit

If a security gateway or mailing list is modifying the body:

• Mailing lists: Configure the list to not add footers, or add them as separate MIME parts (some list software supports this)
• Security gateways: Configure them to operate on messages before DKIM signing, not after
• Antivirus disclaimers: Move disclaimer injection to the sending server, before DKIM signing occurs

Implement ARC (Authenticated Received Chain)

ARC preserves the original authentication results across forwarding hops. When a trusted intermediary modifies a message, it can add ARC headers that allow the final receiver to trust the original DKIM signature even though the body changed.

ARC is supported by Gmail, Microsoft, and other major providers.

Use the l= Tag Carefully

The l= (body length) tag limits how many bytes of the body are signed. In theory, content added after the signed portion wouldn't break the hash. In practice:

Reorder Your Email Pipeline

If possible, arrange your mail flow so that DKIM signing happens last, after all modifications:

Compose → Security scan → Disclaimer added → DKIM sign → Send

Not:

Compose → DKIM sign → Security scan → Disclaimer added → Send

Special Case: Empty Body

An email with an empty body has a known, fixed body hash. For SHA-256, the hash of an empty body (after canonicalization) is:

bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=

If you see this value in bh= but the received message has content in the body, something added content after signing.

Special Case: MIME Multipart Messages

MIME multipart emails (with attachments or HTML+text alternatives) are particularly vulnerable to body hash failures because:

• Boundary strings must remain identical
• MIME part ordering must be preserved
• Each part's encoding must be unchanged

If your emails include attachments and body hash fails, check whether intermediate systems are reorganizing MIME parts or re-encoding attachments.

Generating proper DKIM keys is the first step to reliable email authentication.