Why is Mimecast causing DKIM body hash failures?
Published 10 May 2025
Updated 11 Aug 2026
12 min read
Summarize with
Updated on 11 Aug 2026: We tightened the troubleshooting steps around trusted headers, paired raw-source comparisons, canonicalization, and gateway validation order.
Mimecast reports a DKIM body hash failure when the body it verifies is not byte-for-byte equivalent to the body that was signed, after DKIM canonicalization is applied. Mimecast causes the mismatch only when its processing changes the message before that check. Common triggers along the path include URL rewriting, attachment scanning that repacks MIME parts, footer or disclaimer insertion, transfer-encoding changes, line ending changes, and incorrect validation order.
The important caveat is that an Authentication-Results header from relay.mimecast.com identifies where the failure was recorded only when the header belongs to the recipient's trusted Mimecast hop. It does not prove who changed the message. Treat it as evidence that Mimecast observed the failure, then compare paired raw sources captured before and after Mimecast processing.
A DKIM body hash failure is not a DNS problem by itself. It means the verifier recalculated the body hash and got a different value from the bh= tag in the DKIM-Signature header. A separate public key lookup, selector, or key syntax failure can coexist with it.
What a DKIM body hash failure means
DKIM signs selected headers and a canonicalized version of the message body. The body hash is calculated at signing time and stored in bh=. When Mimecast receives the message, it canonicalizes the body using the method declared in the signature, recalculates the hash, and compares the result. If the body changed in a way canonicalization does not ignore, DKIM fails with a body hash error.
Typical header clue
Authentication-Results: relay.mimecast.com; dkim=fail ("body hash did not verify")
This error is different from bad signature and no key for signature results. A body hash result means the verifier parsed the DKIM signature and found that the recalculated body hash differs from bh=. It does not establish that the public key lookup or header-signature check succeeded. Mimecast's DKIM failure guide also separates these result types, so use the exact error text when choosing the next check.
- Changed body: A footer, banner, rewritten link, rewritten attachment part, or added tracking block changes the bytes DKIM checks.
- Changed encoding: A quoted-printable, base64, 7-bit, 8-bit, or charset conversion can alter the canonicalized body.
- Changed validation point: The gateway can validate a copy that has already been scanned or rewritten instead of the original inbound copy.
- Changed parser result: A DKIM library can mishandle canonicalization, MIME boundaries, empty body lines, or unusual header folding.
Why Mimecast appears in the failure
Mimecast often sits as the recipient domain's MX. It receives the message before the final mailbox system, scans it, applies policy, and forwards it internally. That placement makes Mimecast the first visible verifier in many header samples. When a trusted Authentication-Results header says Mimecast found body hash did not verify, the failure happened during the check Mimecast recorded.
Mimecast Administration Console with inbound policies and a DKIM body hash failure result.
The hard part is separating observation from causation. Mimecast can be the place that noticed a broken signature, the place that broke it, or the place whose verifier produced a false result. Header samples alone rarely separate those cases. Paired pre-gateway and post-gateway raw sources usually do.
The HappyFox note documents this symptom after Mimecast handling and describes unpacking and repacking as a suspected cause. It is useful supporting evidence, but it is not proof that the same processing changed a specific message.
What the header proves
- Verifier: The named host or domain recorded the DKIM result when the header is within the trusted receiving path.
- Failure type: The DKIM body hash did not match after canonicalization.
- Timing clue: The check happened at or before that Authentication-Results header was added.
What the header does not prove
- Root cause: It does not prove which system first changed the body.
- Body diff: It does not show whether URLs, MIME parts, or footer content changed.
- Parser accuracy: It does not prove the verifier handled every canonicalization edge case correctly.
Encoding and MIME changes that trigger it
The most common technical reason is not that Mimecast dislikes DKIM. DKIM is intentionally strict. Relaxed body canonicalization compresses runs of spaces and tabs within each line, removes whitespace at line ends, and ignores empty lines at the end of the body. It does not decode MIME, normalize transfer encodings, ignore a rewritten URL, or tolerate an added line or changed MIME boundary.
|
|
|
|---|---|---|
URL rewrite | Link bytes change | Validate first |
Footer | New body lines | Add later |
MIME repack | Part bytes change | Preserve source |
7-bit label | Recoding risk | Use QP |
Line endings | Hash changes | Normalize send |
Common causes of Mimecast-visible DKIM body hash failures.
The 7-bit question matters, but not because 7-bit is always wrong. It becomes a problem when a message declares 7-bit content while the actual body contains bytes that require a different transfer encoding. Somewhere in the path, a gateway can recode that body into quoted-printable or base64. That recoding changes the bytes DKIM signed.
For UTF-8 HTML mail, choose a stable quoted-printable or base64 transfer encoding at the final sender and generally use a relaxed/relaxed DKIM signature. That reduces harmless whitespace breakage, but it does not protect against content security rewriting. For a broader remediation checklist, the body hash fixes page covers the full troubleshooting path.
Do not fix a Mimecast-visible body hash failure by rotating DKIM keys first. Key rotation helps when the key is missing, malformed, revoked, too short, or published under the wrong selector. A body hash mismatch needs a message-body investigation.
How to prove the actual change
Use a controlled test with the same saved RFC 5322 message through a Mimecast-protected path and a comparable path that does not use Mimecast. If exact replay is unavailable, disable timestamps, tracking tokens, and personalization so both bodies start identically. Collect raw source before the gateway and after delivery. A passing comparison path and failing Mimecast path narrow the cause, while the paired source diff shows what changed.
DKIM body hash investigation flow through a Mimecast-protected mail path.
- Capture both sources: Get the raw message before Mimecast and after delivery, including MIME boundaries, transfer encoding, and all DKIM signatures.
- Check every signature: Confirm each signing domain, selector, canonicalization mode, and l= body length tag. One signature can fail while another passes.
- Compare bodies: Look for rewritten URLs, added text, changed MIME boundaries, altered attachment wrappers, and transfer encoding changes.
- Test order: Check whether the recipient gateway validates before or after URL protection, footer insertion, and attachment processing.
- Repeat cleanly: Send plain text, HTML, and attachment controls while keeping dynamic and recipient-specific content fixed.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
A focused DKIM checker is useful when you need to confirm selector syntax and key retrieval before moving on to body-level evidence. If the key and selector pass, stop treating the issue as DNS and start treating it as content mutation or verification behavior.
What to change in signing and routing
The clean fix is to preserve the signed body until inbound authentication has run. A receiving gateway should record a trusted local Authentication-Results value before it rewrites URLs, adds banners, scans attachments in a way that changes MIME, or appends disclaimers. If a downstream system re-verifies the modified copy, the original DKIM signature will still fail, so local routing and policy must distinguish that result from the trusted pre-modification result.
Better sender setup
- Canonicalization: Prefer relaxed body and header canonicalization for normal production mail.
- Encoding: Choose stable quoted-printable or base64 for body content that needs it.
- Signing point: Sign after all outbound footers, branding, tracking, and MIME assembly are complete.
- Samples: Keep raw source examples for each major sending stream.
Risky sender setup
- Fragile body: Using simple body canonicalization for mail that crosses security gateways.
- Wrong label: Declaring 7-bit content while sending bytes that require another encoding.
- Late edits: Signing before an outbound system adds tracking, disclaimers, or MIME wrappers.
- Header-only proof: Drawing conclusions without paired raw sources around the failing hop.
Stable DKIM signing pattern
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=BASE64-BODY-HASH; b=BASE64-SIGNATURE
The l= body length tag sometimes comes up in these conversations because it lets a verifier hash only the declared number of canonicalized body bytes. Do not treat it as the default fix. It narrows what the signature covers, which weakens the integrity value of DKIM. Use it only when you understand the tradeoff and have a specific reason.
The best operational fix is usually ordering: authenticate first, record the trusted result, then modify the message. Sender-side hardening still matters, but it cannot compensate for a receiving gateway that rewrites the body before DKIM validation.
How Suped fits the workflow
Suped's product is most useful when this stops being a single header puzzle and becomes a pattern across recipients, sending sources, or campaigns. A one-off DKIM test proves the mechanics. Ongoing DMARC data shows whether the failures are isolated to Mimecast-protected domains, a specific sender, a new template, or a routing change.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
In Suped, the practical workflow is to filter DKIM failures by source, receiving organization, aligned domain, and time period. The DMARC monitoring view helps separate a sending-side problem from a receiver-specific gateway pattern.
Suped's product also tracks DMARC, SPF, DKIM, and blocklist (blacklist) signals in one place. For this incident, use the authentication trend and alerts to confirm whether failures begin after a sender, template, or routing change.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For a fast domain-level check before reviewing aggregate reports, use the domain health checker to confirm DMARC record presence, SPF syntax, DKIM DNS basics, and common configuration faults.
Suped cannot repair a receiving gateway that validates after it rewrites content. It can show the pattern, affected sources, authentication trend, and DNS or sender-side issues that are under your control.
When the failure matters for DMARC
A DKIM body hash failure matters most when DKIM is the only aligned authentication path. DMARC passes when either aligned DKIM passes or aligned SPF passes. If SPF also passes and aligns, the message can still pass DMARC even while DKIM fails. If the message is forwarded or the visible From domain does not match the SPF-authenticated domain, DKIM often becomes the authentication path that protects DMARC.
When receiver-specific failures need action
Classify the pattern after excluding known tests and confirming the trusted validation point.
Low noise
Isolated
A small isolated sample has no DMARC failures or delivery complaints.
Investigate
Recurring
The same receiver, sender, template, or route produces a repeatable pattern.
Fix now
Widespread
The pattern drives aligned DKIM and DMARC failures or causes delivery impact.
No universal percentage makes a receiver-specific body hash failure urgent. A small number of failures from automated forwards or gateway quirks is different from a campaign where most Mimecast-protected recipients fail DKIM and the SPF domain is not aligned. The second case needs a fast routing and content investigation.
ARC can preserve earlier authentication results across forwarding chains when an intermediary validates before modification and signs the result. A later receiver still decides whether to trust that intermediary and the ARC chain. ARC does not make a broken DKIM body hash valid again.
Views from the trenches
Best practices
Validate at the first MX before judging whether a gateway changed the signed body bytes.
Keep original MIME source samples so body hash checks use the exact message bytes.
Use relaxed DKIM canonicalization, then prevent security filters from editing first.
Common pitfalls
Assuming Mimecast caused the failure when its header only shows where validation ran.
Signing fragile 7-bit content while sending UTF-8 body text that downstream MTAs recode.
Relying on DMARC aggregate rows without collecting full headers and message source.
Expert tips
Compare the body before and after scanning, not just the Authentication-Results header.
Check URL rewriting, footer insertion, MIME repacking, and transfer encoding together.
Track failure clusters by receiver so a single gateway pattern becomes visible quickly.
Expert from Email Geeks says the first question is whether Mimecast is the first MX hop or whether the failure only appears later in DMARC reporting. This changes who evaluated the signature and where to collect samples.
2022-08-08 - Email Geeks
Marketer from Email Geeks says header-only evidence is useful but incomplete. A full message source is needed to prove whether the signed body changed, whether URLs were rewritten, or whether a parser produced a false failure.
2022-08-08 - Email Geeks
Why Mimecast causes or exposes the failure
Mimecast causes a DKIM body hash mismatch when it changes the signed body before validation. Otherwise, it is surfacing a change made earlier in the path or a verifier edge case. The usual suspects are content rewriting, MIME repacking, transfer-encoding changes, and footer insertion. The fastest path is to prove the byte-level change with paired raw source samples, then fix validation order or sender encoding based on what changed.
If the problem is only visible at Mimecast recipients, do not start by changing DNS. Start with paired samples, compare the body, check whether Mimecast protection changed content before authentication, and confirm whether DMARC is still passing through aligned SPF. Then use ongoing DMARC data to see whether the issue is isolated or repeatable by receiver.
