Mimecast SPF & DKIM Configuration: An Authoritative Guide by AutoSPF

To authenticate email sent through Mimecast, add the Mimecast region-specific include: mechanism to your SPF record and configure DKIM signing in the Mimecast Administration Console. The exact include string depends on which Mimecast region your tenant is provisioned in (US, EU, UK, AU, South Africa), so it must come directly from your Mimecast admin portal — there is no single universal include.

DKIM (RFC 6376) signs email messages cryptographically, and unlike SPF, the signature survives email forwarding — which is why DMARC alignment via DKIM is more reliable than SPF alignment for forwarded mail and mailing lists.

A US-region Mimecast SPF record typically looks like this (confirm the exact string in your admin console before publishing):

example.com. IN TXT "v=spf1 include:_netblocks.mimecast.com -all"

DKIM signing for outbound mail is configured under Administration → Gateway → Policies → DNS Authentication - Outbound Signing Definitions. Mimecast generates a selector-based key pair; you publish the public key as a TXT record at <selector>._domainkey.example.com and Mimecast signs every outbound message that matches your signing policy.

This guide covers the region-specific Mimecast include strings, the exact Administration Console navigation for DKIM setup, how Mimecast interacts with upstream platforms (Microsoft 365, Google Workspace) when used as a gateway, and how to verify SPF + DKIM + DMARC all align after deployment. Because Mimecast typically sits in front of Microsoft 365, RFC 7208’s 10-DNS-lookup budget is often the tightest constraint — the guide shows how to stay under it.

1. Why Email Authentication Matters

Before diving into configurations, it’s important to understand why email authentication protocols like SPF and DKIM exist.

1.1. What Problem Are We Solving?

Email protocols were originally designed without authentication built in. That means anyone can send an email claiming to be from any domain — including domains you own. This has led to:

• Domain spoofing: Malicious actors sending email that appears to come from your domain.

• Phishing and fraud: Attempts to trick your partners or customers into divulging credentials or clicking malicious links.

• Delivery issues: Legitimate email being flagged or blocked due to lack of authentication.

Modern authentication such as SPF and DKIM combats these issues by allowing receiving mail servers (e.g., Gmail, Microsoft, Yahoo) to verify that an email actually came from an authorized sender and has not been tampered with. 

2. A Primer on SPF and DKIM

To properly configure these protocols, you first need to understand what they are and how they work.

2.1. What Is SPF?

The Sender Policy Framework (SPF) is an email authentication method that lets domain owners publish which mail servers are authorized to send email on behalf of their domain. Receivers check the SPF DNS record to see whether the sending IP is allowed. If the SPF check fails, the receiving server may flag or reject the message. 

At a high level, an SPF record is just a DNS TXT record that includes:

• A version (v=spf1)

• A list of IP addresses and domains permitted to send email

• A policy directive such as ~all or -all

For example:

v=spf1 include:_netblocks.mimecast.com ~all

This SPF record tells receivers: only email that originates from the Mimecast mail servers is authorized for this domain. 

2.2. What Is DKIM?

DomainKeys Identified Mail (DKIM) is an authentication protocol that uses a cryptographic signature to validate messages.

When an email is sent, the mail server generates a signature header using a private key. The receiving server retrieves the public key from the sender’s DNS record and validates that:

• The email was legitimately signed by the domain owner

• The content has not been altered in transit

This ensures integrity and authenticity — two things SPF alone does not guarantee. 

A typical DKIM DNS record looks like:

selector._domainkey.example.com TXT "v=DKIM1; k=rsa; p=PUBLICKEY"

This contains the public key that receivers use to verify signatures.

3. Why Mimecast Needs Proper SPF & DKIM

Mimecast is more than an email gateway — it’s a cloud-based email security and delivery service. When you send mail through Mimecast, your outbound email is routed through their systems. For your email to pass authentication checks with DMARC, both SPF and DKIM records must reflect Mimecast’s involvement.

If either SPF or DKIM isn’t configured correctly:

• Email may fail DMARC alignment

• Emails could be marked as spam or rejected

• Domain reputation could suffer

This makes correct configuration vital, especially if you want to enforce strict DMARC policies like p=quarantine or p=reject.

4. Step-By-Step SPF Setup in Mimecast

4.1. Identify Your Domain Infrastructure

Before you create or update your SPF record, make sure you catalogue all mail servers and services sending email on behalf of your domain. This includes:

• Mimecast

• Internal mail servers

• Third-party mailing services (e.g., marketing automation)

• Other outbound services

Failing to include any of these will cause SPF authentication to fail. 

4.2. Construct the SPF Record

To configure SPF for Mimecast, your DNS SPF record needs to include the Mimecast netblocks. Depending on your server’s region, this could be:

Region	Include Mechanism
Europe (excluding Germany)	include:eu._netblocks.mimecast.com
Germany	include:de._netblocks.mimecast.com
United States	include:us._netblocks.mimecast.com
Canada	include:ca._netblocks.mimecast.com
South Africa	include:za._netblocks.mimecast.com
Australia	include:au._netblocks.mimecast.com
Offshore	include:je._netblocks.mimecast.com
Global	include:_netblocks.mimecast.com

For example, a simple SPF record for a domain in Europe could be:

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

If you also send email from other services, add them using include: as well:

v=spf1 include:eu._netblocks.mimecast.com include:thirdparty.com ~all

Important: Only one SPF record should exist per domain. Multiple SPF TXT records cause errors and can break authentication. 

4.3. Publish the SPF Record in DNS

After crafting the SPF string:

1. Log into your DNS provider’s dashboard.
2. Create a new TXT record with the name of your domain.
3. Paste the SPF string as the value.
4. Save and wait for propagation (which can take up to 72 hours).

5. Configuring DKIM in Mimecast

DKIM setup is a bit more involved because it includes both Mimecast policy definitions and DNS records.

5.1. Create a DKIM Signing Definition

To configure DKIM for Mimecast:

1. Log into the Mimecast Administration Console.
2. Navigate to Administration > Gateway > Policies.
3. Under the Definitions dropdown, select DNS Authentication – Outbound.
4. Click New DNS Authentication – Outbound Signing.
5. Provide a description and choose your domain.
6. Assign a selector name (this identifies the DKIM key).
7. Select the key length (e.g., 2048 bits for stronger security) and click Generate.

This process generates a key pair (private/public). Mimecast stores the private key and provides you with the public key format needed for DNS.

5.2. Publish the DKIM Public Key in DNS

Once the key is generated:

• Copy the provided public key string.

• Create a DNS TXT record with this format:

selector._domainkey.yourdomain.com

• Paste the public key as the TXT content.

• Save and allow DNS propagation.

This enables receiving mail servers to verify the DKIM signature generated by Mimecast on outgoing emails.

5.3. Establish the DKIM Policy

After publishing the DNS record:

1. Return to Mimecast’s Policies > DNS Authentication – Outbound settings.
2. Create a new policy that applies the signing definition to outbound mail.
3. Save the policy and confirm that DKIM signing is enabled.
4. Use Mimecast’s DNS check functionality to verify the DKIM record is published and valid.

When correctly set, you’ll see DNS verification status marked as “verified.”

6. Best Practices and Validation

6.1. Testing and Verification

After both SPF and DKIM are configured:

• Test your SPF record using online validators.

• Use DKIM checks to confirm the record is published and correctly formatted.

These checks alert you to syntax errors or propagation issues before enforcing strict DMARC policies.

6.2. Move Toward DMARC Enforcement

Once SPF and DKIM are verified, you can confidently implement a DMARC record with policies like p=quarantine or p=reject to reduce spoofed email from your domain. However, ensure you’ve thoroughly tested authentication before enforcing strict DMARC, as misconfiguration can disrupt legitimate email flow.