Why is Mimecast causing DKIM body hash failures?
Published 10 May 2025
Updated 19 Oct 2026
13 min read
Summarize with
Updated on 19 Oct 2026: We added inline-image troubleshooting and clarified how gateway changes affect DKIM verification.
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 can cause the mismatch when its processing changes the signed body, including after its own check but before a downstream server verifies DKIM. 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 break DKIM
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.
In c=relaxed/relaxed, the first value applies to headers and the second to the body. An omitted c= defaults to simple/simple; a single c=relaxed still uses simple body canonicalization. These defaults are defined in RFC 6376.
|
|
|
|---|---|---|
URL rewrite | Link bytes change | Verify inbound mail before rewriting; sign outbound mail after rewriting |
Footer | New body lines | Insert before outbound signing or after inbound verification |
MIME repack | Part bytes change | Preserve encoded MIME bytes through verification |
Invalid 7-bit declaration | Gateway re-encodes non-ASCII content | Encode affected parts correctly before signing |
Line endings | Changed line structure | Emit CRLF before signing and preserve it in transit |
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. DKIM does not require UTF-8. MIME parts can declare different charsets; a charset conversion after signing changes the encoded bytes DKIM checks.
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. Check DNS publication and selector configuration for key errors; rotate only when the key needs replacement. A body hash mismatch needs a message-body investigation.
When inline images or signatures trigger the failure
Inline images and corporate signatures are useful test cases when only some messages fail. An image does not inherently break DKIM. A multipart/related message can contain text and HTML alternatives plus an encoded image; the signed body includes the MIME structure and encoded attachment content.
In a Microsoft Q&A thread, senders reported failures with images pasted into desktop Outlook while other variants passed. That is a reported symptom, not proof of a general Outlook or Mimecast defect.
- Send the same message without the image-containing signature to establish a control.
- Test the same image inline and as a regular attachment. Repeat through webmail while keeping the delivery route fixed.
- Compare Content-ID references, MIME part headers and boundaries, and base64 line wrapping in paired raw sources.
- Complete image conversion and signature insertion before outbound DKIM signing. On the receiving side, check whether verification precedes body edits.
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, keep dynamic body content, including timestamps and tracking tokens, identical between tests. 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: Download original .eml files before Mimecast and after delivery, retaining the full MIME body and all DKIM signatures. Copying rendered text or forwarding inline can change the evidence.
- Check every signature: Confirm each signing domain, selector, canonicalization mode, and l= body length tag. One signature can fail while another passes. Compare the same signing domain and selector across hops; an added signature has its own body hash.
- Compare bodies: Recalculate bh= on each raw source using the signature's body canonicalization and hash algorithm, honoring l= if present. Hash the still-encoded MIME body, including its part headers; do not decode quoted-printable or base64 first.
- 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.
If the pre-Mimecast source already has a mismatched body hash, investigate the signer or an earlier relay. If only the post-Mimecast source mismatches for the same signature, inspect the changes between those capture points. A body hash match alone does not verify the header signature.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Suped's DKIM checker checks published key and selector configuration. A DNS check cannot recompute a message body hash without the raw signed message, and a passing key lookup does not prove that a delivered message passes DKIM.
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. For outbound mail routed through Mimecast, apply the final DKIM signature with DMARC domain alignment after stationery or other body edits. An inbound gateway's signature under its own unrelated domain does not provide that domain alignment for the original From address.
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.
Illustrative 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
Avoid l= as a workaround for added footers. It limits the body bytes covered by the signature, allowing content after that limit to be appended without invalidating the signature.
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 DMARC reporting product groups authentication results by sending source and reporting organization. Use it to identify DKIM failure clusters and compare them with the timing of template or routing changes. Aggregate reports do not identify individual campaigns or include the original message body, as specified in RFC 9990.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
In Suped, the practical workflow is to filter DKIM failures by source, reporting organization, signing domain, and time period. The DMARC monitoring view helps identify which reporting organizations observe failures; combine that pattern with raw-source evidence to locate the failing hop.
?
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 review DMARC and SPF configuration before collecting message-level evidence.
Suped shows the authentication data receivers report. It does not identify the body edit or prove which hop caused it; use raw message samples and delivery logs for that investigation.
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 with DMARC domain alignment, the message can still pass DMARC even while DKIM fails. If the message is forwarded or the SPF-authenticated MAIL FROM domain does not meet DMARC's domain alignment requirement, DKIM often becomes the authentication path that protects DMARC. A DKIM failure alone does not require rejection; delivery depends on DMARC policy and receiver handling.
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
Delivery impact
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 raw MIME source samples so body hash checks use the exact message bytes.
Use relaxed DKIM canonicalization and verify inbound messages before body edits occur.
Common pitfalls
Assuming Mimecast caused the failure when its header only shows where validation ran.
Declaring 7-bit while sending raw non-ASCII bytes that downstream gateways must recode.
Relying on DMARC aggregate rows without collecting full headers and original 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 view
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 view
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
Frequently asked questions
Usually no. A body hash failure means the body Mimecast verified did not match the body hash in the DKIM signature. DNS problems usually produce selector, key lookup, or public key errors instead.
No. A trusted Mimecast result proves that Mimecast recorded the mismatch. Proving causation requires paired raw sources captured before and after Mimecast processing, plus the Received header path.
Yes. If links are rewritten before DKIM validation, the body bytes change and the body hash fails. The correct order is to validate DKIM first, record the trusted result, then apply URL protection. Downstream re-verification of the rewritten body still fails for the original signature.
No. ASCII-only parts can use 7-bit even with a UTF-8 charset label. Encode non-ASCII content correctly before signing, and preserve that encoding in transit. DKIM does not require UTF-8.
It tolerates specific whitespace changes. It cannot protect a signature against rewritten URLs, added footers, or MIME and transfer-encoding changes that alter the canonicalized body.
Yes, if SPF passes with DMARC domain alignment, or another DKIM signature passes with domain alignment. If neither authentication path passes with the required domain alignment, DMARC fails.
