Email authentication for Mimecast: SPF, DKIM and DMARC

22 June 2026 · 5 min read

Mimecast is a secure email gateway: your outbound mail leaves Microsoft 365, Google Workspace or your own server and is relayed out through Mimecast, so receivers judge Mimecast's IP addresses and Mimecast's DKIM signature. To pass DMARC through it, your SPF record needs the Mimecast include for your account's region, and Mimecast needs an outbound DKIM signing definition, applied by a policy, that signs with your own domain.

SPF: use the regional include

Mimecast publishes its outbound ranges behind DNS includes. At the time of writing, its global record, _netblocks.mimecast.com, contains eight regional includes:

eu._netblocks.mimecast.com    us._netblocks.mimecast.com    usb._netblocks.mimecast.com
de._netblocks.mimecast.com    ca._netblocks.mimecast.com    za._netblocks.mimecast.com
au._netblocks.mimecast.com    sg._netblocks.mimecast.com

Each regional include lists its addresses directly, so it costs one DNS lookup. The global include costs one lookup plus one for each of the eight it nests, nine in all, which leaves almost nothing of SPF's ten-lookup budget for your other senders. Use the regional include for the region your Mimecast account is hosted in, as shown in your Mimecast onboarding details.

For a domain whose mail all leaves through Mimecast's European grid:

v=spf1 include:eu._netblocks.mimecast.com -all

If some mail still leaves Microsoft 365 directly, add it to the same record:

v=spf1 include:eu._netblocks.mimecast.com include:spf.protection.outlook.com -all

Two rules from RFC 7208 catch people out here:

• One SPF record per domain. Adding a second v=spf1 record for Mimecast makes SPF return a permanent error for every sender. Merge the include into your existing record.
• Ten DNS lookups at most. More than ten also returns a permanent error. The SPF checker counts them.

Do not replace your whole SPF record with the Mimecast include unless Mimecast really is your only outbound path; a billing platform or CRM that sends directly would start failing.

DKIM: definition, DNS record, then policy

Mimecast generates the DKIM key for you. Its documentation describes three steps, and skipping the last one is the common mistake.

Step 1: create the signing definition. In the Mimecast Administration Console, go to Policies > Gateway Policies > Definitions and choose DNS Authentication - Outbound. Select your domain, enter a selector and choose the key length. A selector is just a label; a dated one such as mc202610 makes later rotation easier. Choose 2048 bits if the option is available.

Step 2: publish the public key. Mimecast shows a TXT value to publish at <selector>._domainkey.example.com:

mc202610._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

A 2048-bit key is longer than a single 255-character DNS string, so your DNS host must store it as two or more strings; most do this automatically. Back in Mimecast, use Check DNS to confirm it sees the published key, and save the definition. Mimecast notes that an unsaved definition is not used for signing.

Step 3: apply it with a policy. A definition does nothing on its own. Create a DNS Authentication - Outbound policy that applies the signing definition to outbound mail from your domain.

Then send a message to an outside mailbox and check the DKIM-Signature header shows d=example.com and your selector, and that Authentication-Results shows dkim=pass. The DKIM checker confirms the published key.

Why DKIM carries DMARC through a gateway

DMARC passes when SPF or DKIM passes and aligns with the From domain (RFC 9989). Through a gateway:

• DKIM aligns as long as Mimecast signs with d= set to your domain, which the signing definition above does.
• SPF only aligns if the envelope sender (Return-Path) on the relayed message stays on your domain. Check smtp.mailfrom= in the Authentication-Results header of a test message to see what yours is.

DKIM also survives most forwarding, where SPF does not, so make Mimecast's aligned DKIM signature the mechanism your DMARC pass depends on. Keep alignment relaxed, the default, so a signing subdomain or bounce subdomain of yours still counts.

Publish DMARC and read the reports

Start in monitoring mode at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

In the aggregate reports, look for:

1. Mimecast's IP ranges showing DKIM pass, aligned to your domain. If DKIM is missing on those rows, the signing policy is not applying.
2. The SPF result on those rows. Aligned is a bonus; unaligned is fine while DKIM aligns.
3. Legitimate mail that bypasses Mimecast, such as an application or marketing platform sending directly. Give it its own SPF and DKIM, or route it through Mimecast, before you enforce.

The DMARC report analyser shows each source.

Quarantine, then reject

When every legitimate source passes with alignment, change the policy to p=quarantine, then p=reject once quarantine has run cleanly. The current DMARC standard removed the old pct= tag; to trial a stricter policy, add t=y, which asks receivers to apply one level less. RFC 9989 also suggests at least a month at p=none and a similar period at p=quarantine, and says domains whose users post to mailing lists SHOULD NOT publish p=reject.

Common Mimecast mistakes

• The global include on a regional account. It works but costs nine lookups instead of one.
• Two SPF records. Merge Mimecast into the existing one.
• A definition without a policy. The key verifies, but nothing is signed.
• Relying on SPF alignment. Check the envelope sender; lean on DKIM.
• Forgetting subdomains. Check in your reports that every subdomain sending through Mimecast carries an aligned DKIM signature.

Run the DMARC checker to see your current policy. For the same pattern on another gateway, read the Proofpoint guide, and for the platform behind many Mimecast deployments, DMARC for Microsoft 365. Hosted SPF keeps your record under the lookup limit as your senders change.