DMARC setup for Mimecast

Why a sender you added breaks DMARC, and why it happens quietly

DMARC was never built to catch your own mail server. It catches every other system that puts your domain in the From line. Each one has to be authorized and aligned, or your own policy turns on it.

Mimecast is the awkward version of that problem. Most senders sit beside your mail path. Mimecast sits inside it. Mail leaves Microsoft 365 or Google Workspace, crosses to Mimecast, and Mimecast delivers it. To the receiving server, Mimecast sent that message.

A DMARC failure is not a bounce. At p=none nothing visible happens. At p=quarantine you have asked the receiving server to treat the message as suspicious, and what it does with it is its decision, not yours. It surfaces in your aggregate reports, in failure reports, and in the headers of a test message you send yourself.

The From address your reader sees is not the one SPF checks

Every message carries two sender addresses. The envelope sender is the address in the SMTP MAIL FROM command, which appears in delivered headers as Return-Path. The header From is the one your reader sees. They do not have to match.

SPF checks the envelope. DKIM signs with whatever domain sits in the signature's d= tag. DMARC ignores both results on their own. It asks whether the domain that passed matches the header From. That match is alignment.

A typical email service provider fails you here by design. It sets a Return-Path in its own bounce domain, publishes SPF for it, and earns a clean spf=pass for itself. Your From domain stays unauthenticated.

Mimecast is different, and in your favor. Its documentation states that it preserves the original SMTP envelope sender when forwarding, and changes it only if you configure an Address Alteration policy. There is no custom return-path setting to hunt for. Get the SPF include right and SPF aligns.

The exception is a policy you build yourself. Address Alteration has an Address Type field with separate entries for Envelope FROM Address and Header [From] Address. Rewrite one and not the other and you break alignment without meaning to.

Which Mimecast you run decides the SPF include

Mimecast sells two products and they use different includes.

Email Security Cloud Gateway is the MX-based one. Your MX points at Mimecast and outbound mail routes through it. Its includes are regional:

• United States: v=spf1 include:us._netblocks.mimecast.com ~all
• Europe excluding Germany: include:eu._netblocks.mimecast.com
• Germany: include:de._netblocks.mimecast.com
• Canada: include:ca._netblocks.mimecast.com
• Australia: include:au._netblocks.mimecast.com
• South Africa: include:za._netblocks.mimecast.com
• Global, covering all of the above: include:_netblocks.mimecast.com

The ten-lookup limit makes the global include expensive

SPF allows ten DNS lookups per record. Go over and the record is invalid, which returns permerror. Mimecast's own SPF page is direct about the arithmetic. The regional record costs one lookup. Mimecast's page still puts the global _netblocks.mimecast.com record at six lookups. Resolve it today and it nests eight regional includes, so it costs nine of your ten and leaves you almost nothing. Six of your ten on a single vendor leaves little for anything else.

There is a second trap once your MX moves. If your SPF record still contains a bare mx mechanism, Mimecast documents that its inbound hosts resolve to enough address records to blow the lookup limit on their own. Remove mx.

Email Security Cloud Integrated is the other product. It connects to Microsoft 365 through the API rather than taking over your MX, and its outbound include is a different hostname family: spf.us-1.a.mimecastprotect.com, with uk-1, de-1, ca-1, au-1 and za-1 elsewhere.

The DKIM record Mimecast asks for is a TXT record, not a CNAME

Microsoft-shaped instructions mislead here. Microsoft 365 hands you two CNAMEs pointing at keys it holds. Mimecast generates a key pair, keeps the private half, and gives you the real public key to publish as TXT.

In the Mimecast Administration Console go to Policies then Gateway Policies. Open the Definitions drop-down, choose DNS Authentication - Outbound Signing, then click New DNS Authentication - Outbound Signing. Older articles send you to Administration then Gateway then Policies, which is the previous menu.

Select Sign Outbound Messages with DKIM. Use the Lookup button to pick the internal Domain. Choose a DKIM Key Length of 1024 or 2048. Name your selector. Mimecast shows the DNS Address as selector._domainkey.yourdomain.com and a Public Key field with a Generate button. What goes wrong is specific:

• DNS Address is the full hostname. If your DNS provider appends your domain automatically, Mimecast tells you to strip it and enter selector._domainkey only. Otherwise the record resolves at a doubled name, meaning nowhere.
• A 2048-bit key exceeds the 255-character limit for one TXT string. Mimecast says to confirm your provider supports it. That means quoted chunks inside one record, never two records for one selector.
• Mimecast warns that the published key must keep its spaces, because some DNS providers strip them out.
• Click Check DNS. It runs a TXT lookup for selector._domainkey.domain and compares the result against the Public Key field. Allow up to 72 hours before calling a miss a failure.
• Then click Save and Exit. Mimecast states plainly that a validated key you did not save will not sign your outbound email.
• Is External Domain forces a 1024-bit key and needs that domain to have MX records. Without them you get "The external domain has no MX records, you cannot sign emails on its behalf".

The definition does nothing until a policy points at it

Mimecast splits this into two objects and the second is easy to skip. The definition holds the key. The policy decides which mail gets signed.

Go back to Policies then Gateway Policies, select DNS Authentication - Outbound, click New Policy, and pick your verified definition in Select Option. Mimecast's documented setup sets Addresses Based On to Both, Applies From to Email Domain with your domain in Specifically, and Applies To set to Everyone.

Build one definition and one policy per internal domain. Mimecast is explicit that sharing a definition across domains makes DKIM checks fail, because the definition names the wrong domain.

What this does to Microsoft 365 or Google Workspace signing

On Cloud Gateway, Mimecast is the last hop, so Mimecast should be the signer. Its guidance is that only Mimecast must sign message headers with DKIM signatures, and it names Microsoft 365 and on-premises servers as upstream signers whose signatures are likely to fail at the recipient.

Be precise about how bad that is. RFC 9989, the DMARC standard published in May 2026 that replaces RFC 7489, says a message can carry several DKIM signatures and passes if any one of them verifies and aligns. A broken upstream signature is not automatically fatal while Mimecast's aligned signature holds. It will still fill your reports with dkim=fail rows.

Microsoft 365 tenants may have less of a conflict than they expect. Microsoft's current documentation states that no DKIM signing occurs for outbound mail from custom domains until you configure it. The conflict is real only if you already published selector1 and selector2.

Cloud Integrated inverts the arrangement. Microsoft still delivers the mail, so its DKIM stays authoritative and there is no outbound signing definition to build. Mimecast is registered as a Trusted ARC Sealer in your tenant instead. Drop the service and you must remove that sealer yourself.

Google Workspace routes outbound to Mimecast through a Gmail host route under Apps, Google Workspace, Gmail, Hosts, plus a routing rule under Routing scoped to Outbound. Same signing decision.

Publishing DMARC itself

Mimecast does not host your DNS. The _dmarc TXT record goes at your registrar or DNS host, like SPF and the DKIM key. Nothing in the console publishes it for you.

Start at p=none with a rua address, watch until Mimecast and every other legitimate sender reports aligned, then tighten. If you are writing a fresh record now, RFC 9989 marks the pct tag historic. Its replacement is t=y, a test-mode flag telling receivers not to apply your policy yet.

Mimecast's reporting product is DMARC Analyzer 2.0, under More Services then DMARC Analyzer 2.0. Domain Management offers automated DMARC Delegation or a manual TXT record. DNS Checker validates DMARC, SPF, DKIM and BIMI. Mimecast has been migrating accounts off version 1.0 during 2026, so older screenshots will not match.

Verify on a real send, not on the green tick

Check DNS proves one thing: Mimecast can see your TXT record. It says nothing about whether a delivered message passes DMARC.

There is a specific trap here. Mimecast stamps its own Authentication-Results header on inbound mail, showing spf, dkim and dmarc results for people writing to you. Finding one proves your inbound checks work, not your outbound signing.

Send a real message from a real mailbox to an external address you control on another provider. Open the raw source and read the receiving server's Authentication-Results line. Three things have to be true:

• spf=pass, and the domain SPF evaluated is yours rather than a Mimecast one.
• dkim=pass with header.d= equal to your From domain. If d= shows a Mimecast domain or your onmicrosoft.com tenant, DKIM passed and DMARC did not.
• dmarc=pass with header.from= showing your domain.

If you would rather not do this yourself

Check the Return-Path on the delivered message too. If it is not an address at your domain, an Address Alteration policy rewrote it, and that is where your SPF alignment went.

All of this is a genuine afternoon's work. If your test message came back with three passes and a matching d= and From, you are done.

We do this for businesses that would rather hand it off. We work through the access controls each platform already provides, which you grant and revoke yourself. We do not accept passwords, government IDs or card numbers. We cannot promise a deliverability outcome, because inbox placement depends on your sending history as much as your DNS. We can get the records right and prove it in real headers.