Setting Up DMARC with Microsoft 365

Overview

Microsoft 365 (formerly Office 365) has built-in support for DKIM and handles SPF slightly differently from Google Workspace. This guide walks through the complete setup.

Step 1 — SPF for Microsoft 365

Microsoft 365 uses a single SPF include:

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

If you have an existing SPF record, add include:spf.protection.outlook.com to it.

Note: If you previously used include:outlook.com or include:office365.com, update to include:spf.protection.outlook.com — these older includes are deprecated.

Verify:

dig TXT yourdomain.com

Step 2 — DKIM for Microsoft 365

Microsoft 365 can sign your outbound email with DKIM using your own domain.

Enable DKIM in Microsoft 365

Option A — Microsoft Defender portal (recommended):

1. Go to Microsoft Defender → Email & Collaboration → Policies & Rules → Threat policies → Email authentication settings
2. Click the DKIM tab
3. Select your domain
4. Toggle Sign messages for this domain with DKIM signatures to Enabled
5. Microsoft will show you two CNAME records to publish in DNS

Option B — Exchange Admin Center:

1. Go to Exchange Admin Center → Protection → DKIM
2. Select your domain and click Enable

Publish the DKIM CNAME records

Microsoft uses CNAME records (not TXT records) for DKIM. Add both records to your DNS:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.youronmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.youronmicrosoft.com

The exact values will be shown in the Defender portal. The format of the CNAME targets varies slightly by tenant.

Wait 48 hours after publishing before checking — CNAME propagation can be slow.

Verify DKIM is working

Back in the Defender portal, the DKIM status for your domain should show Enabled. If it shows an error after 48 hours, verify the CNAME records are correctly published.

Step 3 — Publish a DMARC record

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Step 4 — Handle other sending services

Step 5 — Advance to enforcement

Same path as any DMARC deployment:

1. Monitor with p=none until pass rate > 95%
2. Quarantine with pct=10, increase gradually
3. Enforce with p=reject

Microsoft 365-specific considerations

Shared IP addresses

Microsoft 365 uses large shared IP pools. You may see Microsoft IPs in your DMARC reports that appear to be sending for your domain but are actually other tenants on the same IP. Don't be alarmed — your DMARC policy only applies to email claiming your domain in the From: header.

Exchange Online Protection (EOP)

EOP performs outbound spam filtering before email leaves Microsoft's servers. This can occasionally strip DKIM signatures. If you see DKIM failures for email you know was sent from M365, check whether EOP content filtering is modifying message headers.

External email forwarding

If users set up forwarding rules from their M365 mailbox to personal accounts, those forwarded emails may fail SPF alignment. This is expected and not a misconfiguration — it's how SMTP forwarding works.

Hybrid environments

If you run Exchange on-premises alongside Microsoft 365, your on-premises servers need their own SPF entries and DKIM setup separately. Check the DMARC+ Dashboard for on-premises IPs that may be failing.

Troubleshooting

DKIM CNAME shows as unresolvable → Check you published both CNAME records with the exact values from the portal → Verify the format — the target CNAME must include your onmicrosoft.com subdomain

SPF fails from Microsoft IPs → Verify the SPF include is spf.protection.outlook.com (not an older variant) → Check your SPF record hasn't exceeded 10 lookups

DMARC fails alignment despite SPF pass → Check whether email is being relayed through an intermediate server that changes the Return-Path → Ensure DKIM is set up — if SPF alignment breaks on forwarding, DKIM alignment keeps DMARC passing