DMARC Fail Mimecast

DMARC passes only when at least one of SPF or DKIM both verifies and aligns with the domain in the visible From: header (RFC 7489 §3.1). When Mimecast sits in the mail path as an intermediary (inbound gateway, outbound relay, or forwarder), it can break both checks at once — that is why you see a DMARC fail even though the original message was correctly signed.

What causes "DMARC Fail Mimecast"?

There are two distinct failure modes. Identify which one you have by reading the Authentication-Results header on a received message.

1. DKIM body hash is broken by message modification. DKIM signs a hash of the body (and selected headers) per RFC 6376. If any byte of the signed content changes after signing, the body hash no longer matches and DKIM returns fail. Mimecast commonly changes those bytes when it:

• rewrites URLs (URL Protect / attachment protection) — link bytes change;
• inserts a disclaimer, banner, or footer — new body lines are added;
• repacks MIME parts during attachment scanning — boundaries change;
• re-encodes transfer-encoding (e.g. 7-bit → quoted-printable/base64).

Relaxed body canonicalization (c=relaxed/relaxed, RFC 6376 §3.4.4) only collapses internal whitespace runs to a single space, trims trailing whitespace, and drops trailing empty lines — it does not forgive rewritten URLs, added text, new MIME boundaries, or re-encoded parts. So relaxed canonicalization helps with minor whitespace drift but will not save a message Mimecast has materially rewritten.

2. SPF and/or DKIM no longer align. When Mimecast relays a message, the SMTP envelope (MAIL FROM / Return-Path) and the connecting IP become Mimecast's, not yours. SPF may then pass for Mimecast's domain but is not aligned with your From: domain, so it does not satisfy DMARC. If DKIM is also broken (mode 1), DMARC has nothing left to pass on and fails.

ARC (Authenticated Received Chain) records that authentication was valid before the hop, but per its design it does not repair a broken DKIM body hash — it only lets a trusting downstream receiver honor the earlier result.

How do I fix DMARC fail through Mimecast?

If Mimecast is your inbound gateway (protecting your own users, mail forwarded to you fails DMARC):

1. Set inbound processing to authenticate first, modify second — run SPF/DKIM/DMARC evaluation before URL Protect, banners, and attachment processing so the verdict is computed on the unmodified message.
2. Have Mimecast seal ARC on inbound mail and trust upstream ARC chains, so legitimately-forwarded mail that already passed isn't re-failed.
3. Do not enforce your own DMARC reject on internally-forwarded streams that Mimecast has already authenticated.

If Mimecast is your outbound relay (your domain's mail fails DMARC at recipients):

1. Let only one party sign DKIM, and sign last. Either sign at Mimecast (create a DNS Authentication / DKIM signing definition and policy in Mimecast, publish the public key in your DNS), or sign upstream — but not both, and never sign before a hop that will rewrite the body. The signer must be the final modifier.
2. Align the signing domain (d=) with your From: domain — DKIM can verify yet still fail DMARC if the domains don't align (RFC 7489 §3.1.1).
3. Authorize Mimecast in SPF by adding their include: mechanism to your SPF record so SPF passes and aligns for mail sent under your domain.
4. Use c=relaxed/relaxed canonicalization to absorb harmless whitespace changes.

How do I confirm which check failed?

Read the Authentication-Results header (and your DMARC aggregate rua reports). dkim=fail (body hash did not verify) points to message modification (mode 1). spf=pass with dmarc=fail points to an alignment gap (mode 2). Fixing the wrong one wastes time, so diagnose before changing config.

The original "generate a key and trust the third party" advice is only half the story: it addresses outbound DKIM signing but ignores SPF alignment, inbound processing order, and ARC — the parts that actually cause most Mimecast DMARC failures.