Mimecast SPF: choosing the right regional include for outbound mail

When outbound mail routes through Mimecast, the receiving server sees Mimecast's IP addresses. The client's SPF record has to authorize them, or SPF starts failing on the day you cut over. Mimecast's knowledge base documents a set of regional includes, a global include, and, in its newest regional article, a second naming scheme. Picking the wrong one costs lookups or misses the client's region. This guide covers what Mimecast documents and what we saw in live DNS.

The regional _netblocks includes

Mimecast's articles on implementing SPF for outbound email list one include per region (its "grid"):

Mimecast's examples end with ~all and recommend "testing with the relaxed syntax first" before moving to -all. Take the value from the client's Mimecast Administration Console, then use the table to sanity-check it.

A caveat about the most detailed source: it's a Connect Application article. Mimecast's own EOL notice says the Connect Application was discontinued on January 31, 2024, and onboarding now goes through the Administration Console. The record values below were checked against live DNS, not taken on trust from that article.

Three documented includes that don't resolve

Mimecast's articles also list include:uspcom._netblocks.mimecast-pscom-us.com (USPCOM), include:je._netblocks.mimecast.com (Offshore) and, in the newer scheme below, include:spf.sg-1.a.mimecastprotect.com (Singapore). On Oct 14, 2026, all three returned NXDOMAIN from both Google (8.8.8.8) and Cloudflare (1.1.1.1). The whole mimecast-pscom-us.com domain returned NXDOMAIN too. Under RFC 7208 §5.2, an include whose target doesn't exist is a permerror, so one of these would break SPF for every message. Don't use them unless Mimecast confirms the name for the client's account.

USB coverage

The Connect article says the global record "does not include USB IP addresses." Live DNS disagrees. On Oct 14, 2026, _netblocks.mimecast.com included usb._netblocks.mimecast.com directly. A USB-grid customer using the global include is covered as of that date. A customer that only sends from USB still does better with include:usb._netblocks.mimecast.com, which costs one lookup.

Regional vs global: the lookup cost

Mimecast's Sender Policy Framework article (updated Sep 23, 2026) says a regional include "counts as 1 DNS lookup," while the global _netblocks.mimecast.com "counts as 6 DNS lookups."

On Oct 14, 2026, a live DNS check gave a higher number for the global record. _netblocks.mimecast.com included eight regional records (eu, us, za, de, au, ca, usb and sg), and each of those contained only ip4 ranges. So the global include cost nine lookups: the include itself plus eight nested ones. That would leave one lookup for everything else in the record under RFC 7208's limit of 10. The regional us._netblocks.mimecast.com was ip4-only, costing one lookup. This is a DNS observation that differs from Mimecast's published figure. Use the regional include unless the client really sends from several Mimecast grids.

The newer mimecastprotect.com records

Mimecast's Configuration – Regional IPs & Resources article (updated Oct 1, 2026), written for Mimecast Email Security Cloud Integrated, lists a different set of outbound SPF includes:

The article also lists a Singapore entry, spf.sg-1.a.mimecastprotect.com, which doesn't resolve (see above). On Oct 14, 2026, the other five resolved, and spf.us-1.a.mimecastprotect.com returned to four ip4 entries with no nested lookups. Its ranges weren't identical to us._netblocks.mimecast.com. Mimecast's public articles don't say which customers should move to these records. Check which Mimecast product the client has and what its console shows, and don't swap one scheme for the other on assumption.

Remove the mx mechanism once MX points to Mimecast

This is the trap Mimecast warns about specifically. Many old records start with v=spf1 mx .... Once the client's MX records point to Mimecast's inbound servers, Mimecast says each of those servers resolves to many A records (its example is 16 per server). That exceeds SPF's address-record limit and causes an SPF error. Its instruction: "remove the 'MX' mechanism from the SPF record and only include 'xx._netblocks.mimecast.com'."

Mimecast also asks you to make sure Mimecast is referenced exactly once, removing older Mimecast entries in favor of the _netblocks include. The Connect Application's validator also wanted Mimecast "listed first." That was a check in a discontinued tool. SPF itself doesn't require any particular order.

Order of operations for an outbound cutover

1. Confirm the region. Get it from the client's Mimecast administration console, not from where the client is based. A European business can still be on the US grid.
2. Edit the existing record. Add the regional include (one that resolves), remove any older Mimecast entries, and remove mx if MX already points to Mimecast. Recount the lookups.
3. Wait out the TTL before you change the outbound connector in Microsoft 365 or Google to deliver through Mimecast.
4. Test. Send to external mailboxes you control and read the Authentication-Results header. You want spf=pass with the client's envelope domain, dkim=pass for the client's domain, and dmarc=pass.
5. Watch the DMARC aggregate reports for a week. SPF failures from Mimecast IPs mean the include is missing or wrong. Passes from Microsoft or Google IPs mean some mail still bypasses Mimecast.

Mimecast's knowledge base also notes that some DNS providers don't allow TXT strings longer than 255 characters. RFC 7208 §3.3 lets a record be split into several strings that are joined back together, but if the client's DNS panel can't do that, keep the record short, which is one more reason to use a regional include.

A merged example

For a US client whose outbound mail relays through Mimecast, and who still sends some app mail through SendGrid:

```

v=spf1 include:us._netblocks.mimecast.com include:sendgrid.net ~all

```

That's the same shape as Mimecast's own example, which uses eu._netblocks with include:sendgrid.net. If every outbound path now goes through Mimecast, Mimecast says to update or replace the SPF record so it specifies Mimecast as the authorized outbound service. Confirm that with the DMARC aggregate reports before you drop the Microsoft 365 or Google include.

Check the client's SPF now

Run the free SPF checker →

It walks the include tree, counts every nested lookup against the RFC 7208 limit of 10, so you can see what the global Mimecast include really costs, and flags duplicate records and +all or ?all endings.

Founding Partner: $1,999, one time. See which client SPF records are one include away from permerror, across all your gateway customers. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →