Email authentication for Mimecast: SPF, DKIM and DMARC

3 May 2026 · 13 min read

Mimecast sits in front of your domain as a secure email gateway. Inbound mail is filtered before it reaches your mailbox provider, and outbound mail is relayed out through Mimecast's infrastructure. That relay step is exactly why email authentication needs special care here: when Mimecast sends on your behalf, the receiving server sees Mimecast's IP addresses, not Microsoft 365 or Google Workspace. If your SPF, DKIM and DMARC are not set up for the Mimecast path specifically, your legitimate mail can fail authentication and, once you reach p=reject, get rejected outright.

This guide is specific to Mimecast: the exact SPF include (and the regional variants that trip people up), how to generate and publish a DKIM key from the Mimecast console, why return-path and From alignment behave the way they do through a gateway, and the practical route from p=none to p=reject without an email outage.

How Mimecast changes the authentication picture

The core thing to understand is that Mimecast is a relay, not just a filter. Your mail flow typically looks like this:

Microsoft 365 / Google Workspace / on-prem
        ↓ (smart host / outbound route)
   Mimecast outbound
        ↓
   recipient's server (Gmail, Yahoo, etc.)

The recipient authenticates the message against the last hop that handed it over, which is Mimecast. So three things must line up:

• SPF must authorise Mimecast's sending IP ranges for your domain.
• DKIM must produce a valid signature that survives the journey, ideally signed with a key that aligns to your domain.
• DMARC must see at least one of SPF or DKIM both pass and align with the domain in the visible From: header.

Mimecast also rewrites or sets the envelope sender (the MAIL FROM, also called the return-path or 5321.MailFrom) on outbound mail. SPF authenticates that envelope domain, not the From: header your recipients see. This distinction is the single most common reason a domain "passes SPF" yet still fails DMARC, and it matters more through a gateway than with direct sending. We will come back to it.

Before you touch DNS, look at your current state with the DMARC checker, SPF checker and DKIM checker. You want a baseline so you can see exactly what changes.

Step 1: Get SPF right, including the regional include

Mimecast publishes its outbound IP ranges as an SPF include. The global form is:

include:_netblocks.mimecast.com

But Mimecast operates in multiple regional grids, and most accounts are provisioned in a specific region. The region-specific includes are narrower (fewer IP ranges, so fewer DNS lookups) and are what Mimecast generally recommends you use. The full set is:

include:eu._netblocks.mimecast.com   # Europe (excluding Germany)
include:de._netblocks.mimecast.com   # Germany
include:us._netblocks.mimecast.com   # United States
include:ca._netblocks.mimecast.com   # Canada
include:za._netblocks.mimecast.com   # South Africa
include:au._netblocks.mimecast.com   # Australia
include:je._netblocks.mimecast.com   # Offshore (Jersey)
include:_netblocks.mimecast.com      # Global (all regions)

Which one do you use? Use the include that matches the region your Mimecast account is hosted in. You can confirm this in the Mimecast Administration Console under Gateway > Policies > Definitions > DNS Authentication - Outbound, or simply ask your Mimecast onboarding contact. If you genuinely send through more than one region, you may need more than one include, but do not just add the global _netblocks.mimecast.com "to be safe", because it pulls in every region's ranges and burns DNS lookups you may not have to spare.

Building the single SPF record

Critically, a domain may have only one SPF TXT record. If you already send through Microsoft 365 or Google Workspace as well, you do not get a second SPF record for Mimecast; you merge the includes into one. A domain that relays through Mimecast but where Microsoft 365 can still send directly might look like:

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

If all outbound mail goes through Mimecast and nothing else sends directly, you can keep it tight:

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

A few Mimecast-specific cautions:

• Watch the 10-lookup limit. SPF allows a maximum of 10 DNS lookups before evaluation returns a permanent error (permerror), which DMARC treats as an SPF failure. The Mimecast regional include typically consumes 2 to 4 of those 10 lookups on its own. Stack that with Outlook, a CRM, a marketing platform and a help desk, and you blow the limit fast. If you are near it, read SPF and the 10-lookup limit and consider SPF flattening or our hosted SPF flattening so the record stays under the limit automatically.
• ~all versus -all. During rollout, ~all (softfail) is the safe default; receivers treat unlisted senders as suspicious but do not hard-reject on SPF alone. Once you are confident every legitimate source is in the record, move to -all (hardfail). Do not jump to -all before you have proof from DMARC reports that nothing is being missed.
• Do not point SPF at Mimecast and forget your other senders. A surprising number of outages happen because someone replaced their whole SPF record with just the Mimecast include and silently removed Outlook or a billing platform.

After editing, re-run the SPF checker to confirm the record parses, the lookup count is under 10, and the Mimecast include resolves.

Step 2: Enable and publish DKIM from the Mimecast console

DKIM is where a gateway really earns its keep for DMARC. Without DKIM, you are relying solely on SPF alignment, and SPF alignment through a gateway is fragile (more on that below). With Mimecast DKIM signing, every message leaving Mimecast carries a cryptographic signature tied to your domain.

Mimecast generates the DKIM key for you. You do not paste in a key you made elsewhere; you create a signing definition, Mimecast hands you the public key, and you publish it.

Create the Outbound Signing Definition

1. In the Administration Console, go to Gateway > Policies > Definitions and choose the DNS Authentication - Outbound Signing definition type.
2. Add a description, then select the domain you want to sign from the lookup list.
3. Name your DKIM selector. Mimecast does not impose a fixed selector name the way some providers do (for example, Microsoft 365 uses selector1 / selector2); you choose it. Pick something clear and dated so future rotation is obvious, for example mc2026a or mimecast202606. The selector becomes part of the DNS hostname, so keep it lowercase and simple.
4. Choose the key length. Select 2048 bits rather than 1024. A 1024-bit key is increasingly considered weak, and major receivers are pushing for 2048. For why this matters, see DKIM key length: 1024 vs 2048.

Mimecast then generates the key pair and shows you the public key to publish.

Publish the DKIM public key in DNS

Create a DNS TXT record where the host is your selector followed by ._domainkey and then your domain:

selector._domainkey.yourdomain.com

So if your domain is example.com and your selector is mc2026a, the record host is:

mc2026a._domainkey.example.com

The TXT value is the public key string Mimecast gives you, in the standard DKIM format:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...your-long-public-key...IDAQAB

A genuine 2048-bit key is long, often longer than the 255-character limit for a single DNS string. Most DNS providers handle this by splitting the value into multiple quoted strings within one TXT record; many do it automatically, but if you paste a 2048-bit key and your provider complains, that string-splitting is usually why. Our DKIM setup guide and DKIM selectors explained cover the mechanics.

Verify, then enable the Outbound Policy

Publishing the DNS record is not the last step. Two more things have to happen:

1. Check DNS in Mimecast. Back in the signing definition, use Check DNS (or the verification button shown) until you get a verified status. This confirms Mimecast can see the published public key and that it matches its private key.
2. Create an Outbound Policy that applies the signing definition. A definition on its own does nothing; you need a corresponding DNS Authentication - Outbound policy that tells Mimecast to apply this signing definition to your outbound mail. Until the policy is in place and enabled, Mimecast is not actually signing anything.

This two-part structure (definition plus policy) is a frequent stumbling block. People publish the DNS record, see "verified", and assume DKIM is live, but if no outbound policy applies the definition, messages still go out unsigned. After enabling the policy, send a test message to an external address and inspect the headers, or run the DKIM checker against your selector to confirm a valid signature.

Step 3: Understand return-path and From alignment through Mimecast

This is the part generic DMARC guides skip, and it is exactly where gateway setups go wrong.

DMARC requires that at least one of SPF or DKIM both passes and aligns with the domain in the visible From: header. Alignment has two separate notions:

• SPF alignment compares the From: domain with the envelope sender (MAIL FROM / return-path), the 5321.MailFrom.
• DKIM alignment compares the From: domain with the d= domain in the DKIM signature.

When Mimecast relays your mail, it commonly sets its own envelope sender for the outbound connection. If the envelope sender ends up on a Mimecast-owned domain rather than your own, then SPF can pass but not align, because the SPF check is validating a Mimecast domain, not yours. SPF passing without aligning does nothing for DMARC.

This is why DKIM is the more reliable alignment path through a gateway:

• The DKIM signature Mimecast applies uses d=yourdomain.com (the domain you selected in the signing definition). That d= aligns with your From: domain, so DKIM passes and aligns, and DMARC is satisfied even when SPF alignment is shaky.
• DKIM signatures also survive simple forwarding far better than SPF does, because the signature travels with the message rather than depending on the connecting IP.

Practical consequences for a Mimecast deployment:

• Always enable Mimecast DKIM signing. Do not rely on SPF alignment alone behind the gateway. If you only do SPF, a return-path on a Mimecast domain can leave you DMARC-unaligned and unable to safely reach p=reject.
• Sign with the From domain, not a generic one. Make sure the domain in the signing definition is the same registrable domain that appears in From:. If you send as news@example.com, the d= should be example.com (or a subdomain that satisfies relaxed alignment).
• Mind relaxed versus strict alignment. DMARC defaults to relaxed alignment, where mail.example.com aligns with example.com. If you have explicitly set aspf=s or adkim=s (strict), the domains must match exactly, which is easy to get wrong through a gateway. Unless you have a specific reason, leave alignment relaxed. There is a fuller treatment in DMARC alignment explained.

If you want to see, per message, whether your Mimecast traffic is passing and aligning, that information lives in your DMARC aggregate reports, which is what Step 4 is about.

Step 4: Publish DMARC and read the reports before you enforce

With SPF and DKIM in place for the Mimecast path, publish a DMARC record in monitoring mode first. The host is _dmarc.yourdomain.com and a sensible starting record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1; adkim=r; aspf=r

• p=none means observe only; nothing is quarantined or rejected yet.
• rua= is where aggregate XML reports are sent. Use an address you actually monitor, or a reporting platform.
• fo=1 asks for failure reports when either SPF or DKIM fails to produce an aligned pass, which is useful while you are validating the gateway path.

You can generate a syntactically correct record with the DMARC record generator and sanity-check an existing one with the DMARC checker. For what every tag means, see understanding your DMARC record.

Now wait for data. Aggregate reports arrive daily from major receivers. You are specifically looking for the Mimecast source IPs in those reports and checking that:

• Mail from Mimecast shows DKIM = pass and aligned (this is your safety net).
• You understand the SPF result: pass-but-not-aligned is acceptable provided DKIM is aligned; DMARC needs only one aligned pass.
• No legitimate source is failing both. If you spot a billing system, CRM or marketing tool sending as your domain and failing, fix that source (add its include to SPF, enable its DKIM) before tightening policy.

Raw DMARC XML is unpleasant to read by hand. Paste a report into the DMARC report analyzer, or set up continuous parsing so you get a per-source breakdown over time. Reading your first DMARC report walks through what to look for.

Step 5: Move to enforcement without breaking mail

The whole point is to reach p=reject, where spoofed mail using your domain is rejected. Rushing there is what causes outages; staged enforcement is what prevents them. The Mimecast-aware progression is:

1. Stay at p=none until reports are clean. Every legitimate sender, Mimecast included, should show an aligned pass (DKIM aligned at minimum). Give it a couple of weeks of data so weekly and monthly senders show up.
2. Move to p=quarantine with sampling. Apply the policy to a fraction of mail first:

   v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r
   

Watch reports. If nothing legitimate lands in spam, raise pct toward 100. See DMARC pct sampling.
3. Move to full quarantine, then p=reject. Once 100% quarantine is stable:

   v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r
   

1. Tighten SPF to -all once you are confident the record is complete, and consider rotating to a fresh 2048-bit DKIM selector on a schedule (see DKIM key rotation).

Two Mimecast-specific enforcement gotchas:

• Subdomains and the sp tag. If departments or apps send from subdomains through Mimecast, set a subdomain policy with sp=, and make sure each active subdomain has its own aligned DKIM or SPF. A common failure is the organisational domain reaching p=reject while a marketing.example.com subdomain quietly breaks. See subdomain DMARC and the sp tag explained.
• Forwarded and journaled mail. Gateways often forward, journal or re-inject mail internally. SPF breaks on forwarding; DKIM usually survives. This is, again, why your Mimecast DKIM signing has to be solid before enforcement. DKIM alignment and forwarding covers the failure modes.

Whichever step you are on, the rule is the same: change one thing, wait for DMARC reports, confirm nothing legitimate broke, then take the next step. For the bigger picture, see reaching p=reject without breaking email and our enforcement journey doc.

A complete Mimecast example

Putting it together for example.com, hosted in Mimecast's EU grid, with Microsoft 365 also able to send directly, here is a coherent end-state set of records.

SPF (one record only):

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

DKIM (published from the Mimecast signing definition, selector mc2026a):

Host:  mc2026a._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB

DMARC at enforcement:

Host:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

If you also run MTA-STS to enforce TLS on inbound mail (sensible alongside Mimecast), our MTA-STS setup doc and the MTA-STS checker will help, and if a logo in the inbox is on your roadmap once you are at p=reject, see the BIMI checker and do you need BIMI.

Common Mimecast mistakes to avoid

• Using the global include when you have a regional account. It works, but it wastes DNS lookups. Match the include to your grid (eu, us, de, and so on).
• Two SPF records. Adding a separate v=spf1 include:_netblocks.mimecast.com ~all alongside an existing SPF record produces a permerror. Merge into one.
• Definition without a policy. Creating the Outbound Signing Definition but never enabling the Outbound Policy means mail goes out unsigned. Always verify with a real test message.
• Trusting SPF alignment alone. Because Mimecast can set its own return-path, SPF may pass without aligning. DKIM is your reliable aligned pass; enable it.
• Jumping straight to p=reject. Without report data confirming Mimecast and every other sender are aligned, enforcement will bounce legitimate mail. Stage it.
• Forgetting subdomains. The org domain at p=reject does not protect or fix subdomains that send through the gateway. Audit each one.

The practical takeaway

For Mimecast specifically: pick the regional SPF include that matches your grid and fold it into a single SPF record under the 10-lookup limit; generate a 2048-bit DKIM key from an Outbound Signing Definition, publish it at selector._domainkey.yourdomain.com, and crucially enable the Outbound Policy so signing actually happens; then lean on DKIM alignment rather than SPF, because Mimecast's return-path can leave SPF passing-but-unaligned. Publish DMARC at p=none, read the reports until your Mimecast traffic shows an aligned pass, and only then climb through quarantine to reject.

If you would rather not manage the gateway includes, DKIM selectors and the staged enforcement by hand, that is exactly what we do for you. Start by checking where your domain stands today with the DMARC checker, watch every sending source (Mimecast included) with continuous monitoring and change alerts, and when you are ready, let our done-for-you hosted service take you from p=none to p=reject without an email outage.