DKIM body hash did not verify

What does "body hash did not verify" mean?

DKIM works by hashing the message body and selected headers, then signing those hashes with a private key. The receiving server fetches the public key from DNS and verifies the signature.

When Authentication-Results shows:

dkim=fail (body hash did not verify)

it means the body hash computed by the receiver doesn't match the bh= value in the DKIM-Signature header. The body changed after signing.

This is different from other DKIM failures like "no key found" (DNS issue) or "signature verification failed" (header modification or key mismatch). Body hash failure specifically means the message body was altered.

If DKIM is the only mechanism providing DMARC alignment for this sender, a DKIM body hash failure also means DMARC fails — which can trigger rejections at providers enforcing DMARC.

DMARCit shows DKIM pass/fail results for every sender. When a sender's DKIM starts failing, you'll see it in your dashboard before it cascades into DMARC rejections.

Why did this happen?

Cause 1: An outbound gateway or security appliance modified the message

This is the most common cause. Many organizations route outbound email through a gateway that adds disclaimers, footers, tracking pixels, or rewrites URLs for link scanning. If this modification happens after the sending platform applies the DKIM signature, the body hash changes and DKIM fails. Google's DKIM troubleshooting documentation specifically calls out outbound gateways adding footers as a common cause of body hash verification failure.

Cause 2: A mailing list processor modified the message

Mailing list software commonly adds subject line tags (for example, [List-Name]), appends footers, reorders MIME parts, or converts formatting. Any of these changes after DKIM signing will break the body hash.

Cause 3: Content encoding transformation in transit

Some mail servers transform message encoding during relay — for example, converting between 8-bit and quoted-printable encoding. If this changes the byte representation of the body, the hash changes. In some cases, encoding transformations during delivery to Outlook.com have been reported as a cause of body hash failures. Using Content-Transfer-Encoding: quoted-printable for outbound mail can help avoid this.

Cause 4: Anti-spam or DLP systems injecting content

Data loss prevention (DLP) tools, anti-spam filters, or compliance appliances that inspect and modify message content before delivery can break DKIM if they operate after the signature is applied.

How to fix "body hash did not verify"

Step 1: Identify what's modifying the message

The modification happens somewhere between DKIM signing and the receiving server. Check your outbound mail path:

• Does your organization use an outbound email gateway or security appliance?
• Are disclaimers, footers, or tracking pixels being added to outbound mail?
• Is the message going through a mailing list processor?
• Is a DLP or compliance tool inspecting and modifying content?

Step 2: Reorder the mail path so modification happens before signing

The most reliable fix is to ensure that any content modification happens before the DKIM signature is applied — not after. This may mean:

• Moving the disclaimer/footer insertion to the sending platform itself (many platforms support this natively)
• Reordering mail flow so the gateway modifies first and the DKIM-signing system processes last
• Configuring the gateway to skip modification on mail that's already DKIM-signed

Step 3: If you can't reorder, ensure DKIM alignment exists on another path

If the modification is unavoidable (for example, a mailing list you don't control), DKIM will fail for that mail flow. Ensure SPF alignment is in place as a fallback so DMARC can still pass via SPF.

Step 4: Don't use the DKIM body length tag (l=) as a workaround

The l= tag in DKIM allows signing only the first N bytes of the body, theoretically letting appended content pass verification. However, this creates a security risk — it allows an attacker to append arbitrary content beyond the signed portion. Google's documentation advises against using the body length tag because messages using it are vulnerable to abuse.

Step 5: Confirm the fix

After making changes, send a test message and check the Authentication-Results header at the receiver. Confirm dkim=pass and verify the bh= value matches. Check your DMARC aggregate reports within 24-48 hours for confirmation across all receivers.

This isn't a one-time fix

Email authentication tends to break again because:

• Mail path changes are common. Adding a new security gateway, enabling a compliance tool, or changing outbound routing can introduce message modification at a point after DKIM signing. Each change to the outbound mail path is a potential DKIM breakage point.
• Mailing lists are structural. If your mail goes through mailing lists, DKIM body hash failures are expected behavior for modified messages. You can't control what list software does to your messages.
• Platform and encoding changes happen quietly. A sending platform may update how it encodes messages, or a relay may change its transfer encoding behavior, breaking DKIM without any visible change in your configuration.

The most reliable way to catch DKIM failures is monitoring your DMARC aggregate reports for changes in DKIM pass rates per sender.