Setting Up SPF, DKIM, and DMARC for Microsoft 365

Why Microsoft 365 requires proper authentication

Google and Yahoo have required all senders to have SPF or DKIM since 2024. Senders exceeding 5,000 messages per day need both plus DMARC. Microsoft enforces similar rules on the receiving side — since May 2025, they require SPF, DKIM, and DMARC for senders exceeding 5,000 messages per day to Outlook.com, Hotmail.com, and Live.com.

Without proper authentication, your emails risk landing in spam or being rejected outright. This guide walks you through setting up all three protocols for Microsoft 365 (Exchange Online) step by step.

Before you start

You need the following:

• Access to the Microsoft 365 Admin center (admin.microsoft.com) and the Microsoft Defender portal (security.microsoft.com) with admin privileges
• Access to your domain's DNS manager (registrar or a service like Cloudflare)
• A list of all services sending email from your domain — besides Exchange Online, this may include marketing platforms, helpdesk, invoicing systems, or CRM

If you're not sure which services send email from your domain, run a full domain analysis — it will show you all sending sources.

Step 1: Set up SPF

SPF (Sender Policy Framework) tells receiving servers which servers are authorized to send email from your domain. For Microsoft 365, you add a single TXT record to DNS.

SPF record for Microsoft 365

If you send email only through Microsoft 365, add this TXT record to your domain root (@):

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

The include:spf.protection.outlook.com mechanism authorizes all Microsoft 365 IP addresses used by Exchange Online to send email.

Unlike Google Workspace, Microsoft recommends -all (hard fail) when used together with DKIM and DMARC. In practice, the difference between -all and ~all is minimal — major providers rely primarily on DMARC policy — but -all clearly signals that no other sources are authorized.

SPF record with additional services

If you send email from other services besides Microsoft 365, add their include mechanisms to the same record. Example with Mailgun and a dedicated server:

v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 -all

Important: A domain may have only one SPF record. Two separate TXT records starting with v=spf1 will cause SPF validation to fail (RFC 7208, Section 4.5). All sending sources must be in a single record.

Adding the record to DNS

1. Log in to your domain's DNS manager
2. Navigate to the DNS records section
3. Create a new TXT record:
   • Host/Name: @ (domain root)
   • Type: TXT
   • Value: your SPF record
4. Save changes

DNS propagation usually takes minutes, up to 48 hours at most. Verify your record with the SPF analyzer.

Step 2: Set up DKIM

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every email. The recipient verifies the signature using a public key in DNS, confirming the message wasn't altered in transit.

Unlike Google Workspace, which uses a TXT record for the DKIM key, Microsoft 365 uses CNAME records. These point to public keys hosted by Microsoft — eliminating the need to manually manage keys.

Creating DKIM CNAME records

Microsoft 365 requires two CNAME records for each domain. You can get the exact values from the Microsoft Defender portal:

1. Go to security.microsoft.com
2. Navigate to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM tab
3. Click on your domain — the required CNAME records will appear in the details

The CNAME record format looks like this (example for older tenants):

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.contoso.onmicrosoft.com
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.contoso.onmicrosoft.com

Since May 2025, Microsoft uses an updated format for new domains with target addresses ending in .dkim.mail.microsoft. Existing domains may continue using the original format with .onmicrosoft.com.

• Host: selector1._domainkey and selector2._domainkey
• Type: CNAME
• Value: copy exactly from the Defender portal — values are specific to your tenant and the format depends on when the domain was added

Add both CNAME records at your domain's DNS manager. Propagation usually takes minutes but can take up to 48 hours.

Enabling DKIM signing

Adding the DNS records alone isn't enough — you must explicitly enable signing in the Defender portal:

1. Go back to Email authentication settings → DKIM tab
2. Click on your domain
3. Toggle Sign messages for this domain with DKIM signatures to Enabled

If the toggle can't be activated, the CNAME records haven't propagated yet. Wait and try again.

Alternatively, you can enable DKIM via PowerShell:

Set-DkimSigningConfig -Identity example.com -Enabled $true

Verifying DKIM functionality

After activation, send a test email to an address outside your domain and check the headers of the received message:

Authentication-Results: mx.google.com;
    dkim=pass header.d=example.com header.s=selector1

If you see dkim=pass, signing is working. You can also verify the DNS records with our DKIM analyzer.

Step 3: Set up DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM to the sender address in the From header. It tells receiving servers what to do with emails that fail authentication and sends you reports on the results.

Wait at least 48 hours after setting up SPF and DKIM before deploying DMARC. Receiving servers need time to recognize your new records.

Starting DMARC record

Start with a none policy — DMARC will only monitor and send reports without affecting delivery:

v=DMARC1; p=none; rua=mailto:example.com@rua.spfmonitor.com,mailto:dmarc@example.com

• p=none — monitoring mode, emails are delivered normally
• rua= — addresses for receiving aggregate reports

If you specify the SPF Monitor address (example.com@rua.spfmonitor.com), reports are automatically processed, visualized, and you'll receive alerts when issues arise — no need to manually parse XML files.

Adding the record to DNS

1. Go to your domain's DNS manager
2. Create a new TXT record:
   • Host/Name: _dmarc
   • Type: TXT
   • Value: your DMARC record
3. Save changes

Verify your record with the DMARC analyzer.

Gradually tightening the policy

After 2–4 weeks of monitoring, analyze your DMARC reports. If legitimate emails pass authentication without issues, tighten the policy gradually:

1. p=none — monitoring (2–4 weeks)
2. p=quarantine; pct=10 — 10% of unauthenticated messages to quarantine
3. p=quarantine; pct=100 — all unauthenticated to quarantine
4. p=reject — full rejection of unauthenticated messages

The pct parameter enables a gradual rollout — you can start at 10% and increase over time. We cover how to read DMARC reports and evaluate results in a separate article.

Differences from Google Workspace

If you manage both platforms or are migrating from one to the other, the key authentication differences are:

For a detailed Google Workspace guide, see Setting Up SPF, DKIM, and DMARC for Google Workspace.

Additional sending services

Microsoft 365 isn't the only source of email from your domain. Marketing platforms (Mailchimp, Brevo), transactional services (SendGrid, Mailgun, Amazon SES), helpdesk (Zendesk, Freshdesk), or invoicing systems — each of these services needs its own authentication.

SPF for additional services

Add each service's include mechanism to your SPF record:

v=spf1 include:spf.protection.outlook.com include:mailgun.org include:sendgrid.net -all

Watch out for the 10 DNS lookup limit in SPF records. Each include consumes at least one lookup. Exceeding the limit causes SPF to fail with a PermError. Check your lookup count with the SPF analyzer.

DKIM for additional services

Each service has a domain verification section in its admin panel (Domain Authentication / Domain Verification). The service generates DNS records that you add to your domain. Once verified, the service will sign emails with your domain's DKIM key.

Without DKIM verification, the service signs emails with its own domain — recipients see "signed by: sendgrid.net" instead of your domain. This undermines trust and causes DMARC alignment failures.

Common mistakes and how to fix them

Two SPF records on the domain

A common mistake when adding Microsoft 365 to existing email: the admin creates a new SPF record instead of editing the existing one. Two v=spf1 records on a single domain cause automatic SPF failure.

Solution: Check your DNS records. If an SPF record already exists, edit it — don't add a new one.

DKIM CNAME records not propagating

After adding the CNAME records, DKIM signing can't be enabled in the Defender portal. The toggle remains inactive.

Solution: Verify the CNAME records are correctly created — check for typos in the values (watch for dashes, periods, and underscores). Wait for DNS propagation and try again. Verify your record status with our DNS tool.

DKIM enabled but emails aren't signed

CNAME records exist in DNS, but emails still lack a DKIM signature. The Defender portal shows "Signing DKIM signatures for this domain", but DKIM is missing from email headers.

Solution: Verify you're sending from your custom domain, not the default *.onmicrosoft.com address. DKIM signing with a custom domain only works for senders with an address in that domain.

DMARC deployed too early

Skipping the monitoring phase (p=none) and deploying p=reject directly can block legitimate emails from services that don't have SPF or DKIM properly configured.

Solution: Always start with p=none and tighten only after analyzing DMARC reports.

Checklist

• SPF record added to DNS (include:spf.protection.outlook.com)
• SPF record verified with analyzer — syntax, lookup count
• DKIM CNAME records added to DNS (selector1._domainkey, selector2._domainkey)
• DKIM signing enabled in the Defender portal
• Test email confirmed — spf=pass and dkim=pass
• DMARC record deployed with p=none and reporting address
• DMARC record verified with analyzer
• All additional sending services authenticated (SPF + DKIM)
• Plan for gradually tightening DMARC policy established