Why is Mimecast causing DKIM body hash failures?
Published 10 May 2025
Updated 4 Jun 2026
11 min read
Summarize with
Mimecast causes a DKIM body hash failure when the body that Mimecast verifies is not byte-for-byte equivalent to the body that was signed, after DKIM canonicalization is applied. The common triggers are URL rewriting, attachment scanning that repacks MIME parts, footer or disclaimer insertion, transfer-encoding changes, line ending changes, and validation order problems where a gateway modifies the message before it runs the DKIM check.
The important caveat is that an Authentication-Results header from relay.mimecast.com proves where the failure was recorded, not automatically who damaged the message. I treat it as strong evidence that the failure was observed at Mimecast, then I prove the cause by comparing the full original source with the full received source.
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. DNS only matters if the public key lookup, selector, or key syntax also fails.
The direct cause
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 specific error is different from a DKIM public key problem. A key problem usually says the selector cannot be found, the key is invalid, or the signature cannot be verified. A body hash error means the signature header was readable and the public key was usable enough for the verifier to compare the body hash.
- 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 pristine 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 the Authentication-Results header says Mimecast found body hash did not verify, the failure happened during the check Mimecast recorded.
Mimecast Administration Console screenshot showing inbound policy and DKIM result areas.
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. A full source sample does.
There are public troubleshooting notes that describe this symptom after Mimecast handling. The HappyFox note is useful because it frames the failure as a body hash mismatch rather than a missing DKIM record. That distinction changes the fix.
What the header proves
- Verifier: The named host or domain recorded the DKIM result.
- 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. It is that DKIM is intentionally strict. Even relaxed body canonicalization only ignores a narrow set of whitespace differences at line ends and empty lines at the end of the body. It does not ignore a rewritten URL, an added line, a different MIME boundary, or a recoded body part.
|
|
|
|---|---|---|
URL rewrite | Link bytes change | Verify 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, I prefer a stable transfer encoding at the sender and a relaxed/relaxed DKIM signature. That protects against harmless whitespace variation, but it does not make DKIM immune to content security rewriting. For a deeper remediation checklist, the body hash fixes page covers the broader 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
I use a simple test: send the same message to a Mimecast-protected recipient and to a recipient path that does not use Mimecast. Then collect full raw source for both, not just visible headers. If the non-Mimecast copy passes DKIM and the Mimecast copy fails, compare the canonicalized body and the MIME structure.
Flowchart for testing DKIM body hash failures through Mimecast.
- Capture source: Get the raw message as received, including MIME boundaries, transfer encoding, and all DKIM signatures.
- Check signer: Confirm the signing domain, selector, canonicalization mode, and whether the signature has an l= body length tag.
- Compare bodies: Look for rewritten URLs, added text, changed MIME boundaries, altered attachment wrappers, and transfer encoding changes.
- Test order: Ask whether the recipient gateway validates before or after URL protection, footer insertion, and attachment processing.
- Repeat cleanly: Send a plain text control, an HTML control, and an attachment control so the failing content pattern is obvious.
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 DKIM validation has happened. A receiving gateway should authenticate the inbound message first, record the result, then rewrite URLs, add banners, detonate attachments, or append disclaimers later. That order keeps DKIM meaningful.
Better sender setup
- Canonicalization: Use 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 full raw source from the failing copy.
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 can let a verifier ignore content added after the signed length. I 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, modify later. 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 true sending-side problem from a receiver-specific gateway pattern.
Suped also brings DMARC, SPF, DKIM monitoring, hosted SPF, hosted DMARC, hosted MTA-STS, SPF flattening, real-time alerts, and blocklist (blacklist) monitoring into one platform. For most teams, Suped is the stronger practical choice because it turns raw authentication failures into fix steps and alerts instead of leaving teams to manually interpret aggregate XML and scattered header samples.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
When I want a fast domain-level check before reviewing aggregate reports, I use the domain health checker to confirm the obvious items first: DMARC record presence, SPF syntax, DKIM DNS basics, and common configuration faults.
Suped will not magically repair a receiving gateway that validates after it rewrites content. It will show the pattern, affected sources, authentication trend, and concrete 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.
How much DKIM failure needs action
Use these thresholds for receiver-specific DKIM body hash failures after excluding known test mail.
Low noise
Under 2%
Small sample, no DMARC failures, no delivery complaints.
Investigate
2-10%
Pattern is visible by recipient gateway or sender.
Fix now
Over 10%
DKIM failure is driving DMARC failure or delivery impact.
Do not treat every receiver-specific DKIM failure as equal. A small number of failures from automated forwards or gateway quirks is different from a campaign where most Mimecast-protected recipients fail DKIM and SPF does not align. The second case needs a fast routing and content investigation.
ARC can help preserve authentication results across forwarding chains when a trusted intermediary validates first and then signs the result. ARC does not make a broken DKIM body hash valid again. It gives later receivers more context about what passed before a message was forwarded or modified.
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
The practical answer
Mimecast is causing, or at least surfacing, DKIM body hash failures because the verified body does not match the signed body. The usual suspects are content rewriting, MIME repacking, transfer-encoding changes, footer insertion, or a validator edge case. The fastest path is to prove the byte-level change with full 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 full 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 a one-off or a repeatable receiver-specific pattern.
