Mimecast SPF and DKIM setup

The regional SPF include to publish for Mimecast, the two-part DKIM setup (a signing definition plus an outbound policy), and the unsaved-key mistake that leaves your mail unsigned.

What you are setting up

Mimecast is a secure email gateway. Your mailboxes hand outbound mail to Mimecast, and Mimecast delivers it to the world, so the connecting IP the receiver sees belongs to Mimecast, not to you. You authorize that with one SPF include, and you have Mimecast sign DKIM with a key you generate in the Administration Console. Unlike most senders, DKIM here is two objects, not one: a definition that holds the key and a policy that decides which mail gets signed. Miss either and nothing is signed.

Publish SPF and DKIM

SPF. Mimecast publishes one include per region. Use the one for your account's region (the Connect application and the Account Settings page both show which):

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 include:us._netblocks.mimecast.com ~all

Regions: eu (Europe excluding Germany), de (Germany), us, usb (US, USB grid),
         ca (Canada), za (South Africa), au (Australia), je (Offshore)

The global include:_netblocks.mimecast.com works everywhere but fans out into every regional include: measured live, it spends 9 of your 10 SPF lookups, where the regional include spends 1. Mimecast also asks that it be referenced exactly once, so remove any older Mimecast include when you merge this into an existing record. If your MX now points at Mimecast, drop the mx mechanism too: each Mimecast inbound host resolves to 16 addresses and the record trips the lookup limit.

DKIM. In the Administration Console, go to Policies > Gateway Policies, open the Definitions drop-down, choose DNS Authentication - Outbound Signing, and click New DNS Authentication - Outbound Signing. Tick Sign Outbound Messages with DKIM, use Lookup to pick your domain, choose the DKIM Key Length (1024 or 2048 bits), and click Generate. Mimecast keeps the private key and shows you two things to publish:

Type:  TXT     (DKIM)
Host:  the "DNS Address" shown, e.g. mimecastYYYYMMDD._domainkey
Value: the "Public Key" shown (v=DKIM1; k=rsa; p=...)

The DNS Address is selector._domainkey.yourdomain.com. If your DNS host appends the domain automatically, enter only the selector._domainkey part. Back in the definition, click Check DNS; it looks up the record and compares it to the Public Key field. Then click Save and Exit. You need one definition per internal domain you send from.

Now the policy. Go to Gateway > Policies > DNS Authentication - Outbound and click New Policy. Select the definition you just verified, set Addresses Based On to Both, Applies From to Email Domain with your domain in Specifically, Applies To to Everyone, leave it perpetual and enabled, and Save and Exit.

Add DMARC

Standard _dmarc TXT record, nothing Mimecast-specific. Start in monitor-only mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Build it with our DMARC builder and progress past p=none once your reports are clean.

The Mimecast gotcha

A verified key that was never saved, or never attached, signs nothing. Mimecast is explicit that a definition only activates after a successful Check DNS, and that if you do not Save and Exit afterward the key is not used. Even a saved definition is inert until an Outbound policy names it. So the usual symptom is a perfect TXT record in DNS and DMARC reports showing Mimecast mail with no DKIM signature at all. If Check DNS fails right after you publish, Mimecast allows up to 72 hours for propagation, and it warns that a 2048-bit key exceeds the 255-character TXT limit at some DNS providers, so the value may need to be split into quoted chunks.

Two more. Only Mimecast should sign: if Microsoft 365 or an on-premises server signs DKIM before handing mail to Mimecast, Mimecast's processing invalidates that upstream signature, so turn off signing at the source and let the gateway do it. And if a domain is not registered as internal in your Mimecast account, mail carrying it leaves through a separate _extnetblocks IP range that your include does not cover, which reads as SPF fail until the domain is added.

Confirm it worked

  • Check DNS in the definition. Reopen the Outbound Signing definition and confirm Check DNS passes and the definition is saved.
  • Send a test and read the headers. Send externally through Mimecast, open the message, and confirm a DKIM signature with d=yourdomain.com and your Mimecast selector, plus spf=pass and dmarc=pass. Our header analyzer reads it back plainly, and the SPF tester shows your lookup count after the include.
  • Watch the reports. Mimecast should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.
Let trustyourinbox publish Mimecast for you

Connect your DNS once and we publish the Mimecast records above in a single click, with a five-minute window to undo. Then we keep watching this sender in your DMARC reports and tell you the moment Mimecast mail starts failing, so a typo in a record never quietly costs you the inbox.

Keep reading

Last verified 2026-08-30 against the official Mimecast documentation.

Was this page helpful?

Stop guessing. Start monitoring.

Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.