Mimecast SPF, DKIM & DMARC Setup Guide

Overview

Mimecast is a cloud email security gateway that filters inbound and outbound email, providing spam filtering, threat protection, and compliance archival. Mimecast Email Security is widely deployed in enterprise environments where regulatory compliance and advanced threat protection are requirements. Unlike most providers that use a single SPF include mechanism, Mimecast uses regional includes — you add only the one that matches your Mimecast data center region.

Regional SPF Includes

Each include costs 1 DNS lookup. You only need the include(s) for your region — do not add all six. Adding all six would consume 6 of your 10 lookup budget on Mimecast alone, leaving almost no room for your email platform or any other sending service.

Gateway Architecture and SPF

Mimecast sits between the internet and your email platform as a mail gateway. MX records point to Mimecast, which filters mail before delivering it to the underlying platform (typically Microsoft 365 or Google Workspace). This architecture means both Mimecast and the underlying email platform need to be in SPF — a minimum of 2 lookups before adding any other senders.

DKIM Configuration

DKIM is configured through DNS Authentication policies in the Mimecast Admin Console. The admin creates a DKIM "definition" by selecting the sending domain and choosing a custom selector name. Mimecast generates the public key, which is published as a TXT record at selector._domainkey.yourdomain.com. Both 1024-bit and 2048-bit RSA keys are supported. For DMARC alignment on outbound mail, Mimecast must be configured to sign messages with your domain's DKIM key — without this, outbound messages relayed through Mimecast will fail DKIM alignment even if the underlying platform signed them, because Mimecast may modify headers during processing.

Why Mimecast Breaks Upstream DKIM Signatures

This is a critical point that catches many administrators. Mimecast, as a gateway, may modify email headers and body content during processing (e.g., adding disclaimer footers, rewriting URLs for threat protection, or modifying subject lines). Any modification to a DKIM-signed header or body invalidates the original signature. Even if Google Workspace or Microsoft 365 signed the message with a valid DKIM key, Mimecast's modifications can break that signature before the message reaches the recipient. The solution: configure Mimecast to re-sign outbound messages with your domain's DKIM key after processing.

Troubleshooting

SPF Failing for All Outbound Mail

The most common cause is using the wrong regional include. Your Mimecast region is determined by your account's data center assignment, visible in the Admin Console under Account > Account Settings. If you are on the US region but published eu._netblocks.mimecast.com, every outbound message fails SPF because the sending IPs do not appear in the European IP range. Replace the include with the correct region and allow DNS propagation.

All Six Regional Includes Published

Some administrators, unsure of their region, add all six includes to "cover all bases." This wastes 5 unnecessary lookups and can push the SPF record past the 10-lookup limit immediately. Identify your correct region in the Admin Console and remove the other five includes. You need exactly one (or two if your account spans both US regions, which is rare).

DMARC Failures Despite DKIM Being Configured in the Upstream Platform

If DMARC failures appear in aggregate reports for messages that pass through Mimecast, the most likely cause is that Mimecast is modifying messages after the upstream platform signed them, invalidating the original DKIM signature. Check whether Mimecast is configured to apply its own DKIM signature. In the Admin Console, verify that a DKIM definition exists for your domain, the DNS record is published, and the policy is applied to outbound mail. Without Mimecast-applied DKIM signing, outbound messages have only the broken upstream signature.

Calendar Invites and Direct SMTP Bypassing Mimecast

Not all email from your platform flows through Mimecast. Calendar invites, some automated messages, and direct SMTP submissions from internal applications may bypass the gateway entirely. These messages originate from your email platform's IPs, not Mimecast's IPs. If your SPF record includes only the Mimecast regional netblock, these bypass messages fail SPF. Keep your underlying email platform's SPF include (e.g., _spf.google.com or spf.protection.outlook.com) in your record alongside the Mimecast include.

Mimecast IP Ranges Changing

Mimecast's regional IP ranges update periodically without notice as capacity is added or reallocated. This makes the include: mechanism essential — it always resolves to the current set of IPs for your region. Hardcoding Mimecast IP addresses in an SPF record will break when those IPs change. If you previously hardcoded IPs (using ip4: or ip6: mechanisms), replace them with the correct regional include.

Additional Setup Notes

Inbound vs. Outbound Considerations

As a gateway, Mimecast processes both inbound and outbound mail. For outbound delivery, Mimecast's IP ranges are the source IPs that receiving servers see, which is why Mimecast's regional include must be in your SPF record. The underlying email platform's include is still needed for any mail that bypasses the gateway (direct SMTP submissions, calendar invites from some platforms, or fallback routing).

Lookup Budget with Mimecast Stacks

Mimecast deployments start at a minimum of 2 SPF lookups: one for the Mimecast regional include and one for the underlying email platform. A typical enterprise stack — Mimecast, Microsoft 365 or Google Workspace, Salesforce, a marketing platform, and a transactional sender — uses 5 lookups minimum. Organizations using Mimecast alongside MailRoute or another filtering layer (for different mail flows) can consume 6-7 lookups before adding any more senders.

Migrating To or From Mimecast

When deploying Mimecast, add the correct regional SPF include before changing MX records to point to Mimecast. If you change MX first, Mimecast starts relaying outbound mail from its IPs before your SPF record authorizes those IPs — causing SPF failures during the cutover window. When migrating away from Mimecast, reverse the process: change MX records back to the underlying platform first, confirm mail flow is direct, then remove the Mimecast SPF include.

Managed SPF can flatten nested includes into direct IP references, freeing up lookup budget for additional providers.