Guides

DMARC, SPF and DKIM for Microsoft 365

27 October 2026

For a custom domain on Microsoft 365 you publish three things at your DNS host: an SPF TXT record with include:spf.protection.outlook.com, two DKIM CNAME records that Microsoft gives you, and a DMARC TXT record at _dmarc. Then you turn on DKIM signing in the Defender portal. Your onmicrosoft.com domain is handled for you. Your own domain is not.

What Microsoft does and does not do for you

Microsoft’s documentation draws a clear line between the two kinds of domain in a tenant:

The onmicrosoft.com domain. Microsoft owns its DNS. Its SPF article says you do not need to do anything for SPF there, and its DKIM article says outbound mail from it is DKIM-signed automatically. You can add a DMARC record for it in the admin center.
Your custom domain, such as example.com. Microsoft says custom domains get no DKIM signing until you configure it, and each sending domain needs its own SPF record. Nothing is automatic.

Most people send from the custom domain, so that is where the work is.

Step 1: SPF

The record Microsoft gives for commercial Microsoft 365 and GCC:

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

Other clouds use a different include. GCC High and DoD use include:spf.protection.office365.us, and Microsoft 365 operated by 21Vianet uses include:spf.protection.partner.outlook.cn.

Notes from Microsoft’s article:

Publish it as a TXT record at the domain itself. Use one SPF record per domain or subdomain. More than one causes permerror.
If other services send as your domain, add their includes or IP addresses to the same record. The whole check is limited to ten DNS lookups.
Microsoft recommends -all for Microsoft 365 domains. If you are still finding other senders, ~all is the safer place to start. See how to create an SPF record.
Set a TTL of at least 3600 seconds.
Each subdomain that sends mail needs its own SPF record. Microsoft suggests putting third-party bulk mail on a subdomain, partly to keep the main record under the lookup limit.

Step 2: DKIM

Microsoft uses CNAME records that point to keys it hosts, which lets it rotate keys for you. In the Microsoft Defender portal:

Go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings, and open the DKIM tab.
Find your domain. It should show as Disabled with a status of NoDKIMKeys. Turn the toggle to Enabled.
A Client error dialog appears. Microsoft says this is expected. Click OK, and the status changes to CnameMissing.
Click the domain row to open its details, and copy the two values under Publish CNAMEs.
At your DNS host, create the two CNAME records.
Back in the details pane, turn on Sign messages for this domain with DKIM signatures.

The records look like this. Microsoft’s example values:

selector1._domainkey  CNAME  selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft
selector2._domainkey  CNAME  selector2-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft

Do not type those. Microsoft says part of the target is assigned per tenant, so copy the exact values from the portal or from PowerShell. Other points from the article:

Use CNAME records, not TXT.
Enter just selector1._domainkey if your DNS host appends the domain automatically.
On Cloudflare, set both records to DNS only (the gray cloud).
On Route 53, include the trailing dot on the target.
Detection can take a few minutes, and DNS propagation can take up to 48 hours.

If you prefer PowerShell, Exchange Online has New-DkimSigningConfig, Get-DkimSigningConfig to read the CNAME values, and Set-DkimSigningConfig -Enabled $true to turn signing on. The default key size is 1024 bits. You can ask for 2048 with -KeySize 2048 when creating the config, or move to 2048 during a rotation with Rotate-DkimSigningConfig. Microsoft says a rotated key takes effect after four days.

For the general idea behind selectors and keys, see how to set up DKIM.

Step 3: DMARC

Microsoft’s DMARC article recommends starting at p=none and moving up slowly. A first record:

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Microsoft’s rollout, in order:

Start with p=none, ideally on a low-volume subdomain or domain, and watch the reports.
Move to p=quarantine. Optionally step pct through 10, 25, 50, 75, and 100.
Move to p=reject, again optionally stepping pct.
Repeat for other subdomains in order of increasing volume and complexity, and do the parent domain last.

Microsoft gives no fixed timing. It says to go slowly and deal with the issues the reports reveal. Our guide to DMARC policies covers how to judge when to move. One note on pct: RFC 9989, the DMARC standard published in May 2026, removed it in favor of a t=y testing flag. Microsoft still documents it.

Reports with Microsoft 365

Send rua reports to a dedicated mailbox or a Microsoft 365 Group, not a person’s mailbox. Microsoft recommends this.
Microsoft 365 does not send forensic (ruf) reports, even when other domains ask for them.
Microsoft 365 sends aggregate reports for inbound mail only when your MX record points directly at Microsoft 365. If a third-party filter sits in front, it will not.
If the rua address is on another domain, that domain needs a record such as example.com._report._dmarc.otherdomain.com with the value v=DMARC1;.

Our guide to reading a DMARC report explains what the reports contain.

The onmicrosoft.com domain

You can add DMARC to it in the Microsoft 365 admin center: Settings, then Domains, select the onmicrosoft.com domain, open DNS records, and add a TXT record named _dmarc. Microsoft’s example value is v=DMARC1; p=reject. That is reasonable if nobody sends from that address.

Step 4: Other services sending as your domain

A Microsoft 365 tenant rarely sends alone. Newsletters, store notifications, help desks, and invoicing apps all send as example.com too. Each needs DKIM on your domain, set up inside that service, or its mail will fail DMARC once you enforce. Your first reports will list them. If a source passes SPF or DKIM on the wrong domain, our guide to why DMARC fails shows how to fix it.

Step 5: Check a message

Send a message from Outlook to an address outside your organization, such as a personal Gmail account. Microsoft notes that messages between users in the same organization may not carry a DKIM signature, and advises against testing with AOL. In the received message’s headers, look for:

DKIM-Signature: ... d=example.com; s=selector1 (or selector2). The d= must be your domain.
Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass

If d= shows your onmicrosoft.com domain, DKIM signing is not turned on for the custom domain yet.

How Microsoft 365 treats inbound mail that fails DMARC

This is the other direction: mail arriving at your tenant from domains with their own DMARC policies. With the anti-phishing setting Honor DMARC record policy turned on, which Microsoft recommends:

p=none: no DMARC-specific action. Other filtering still applies.
p=quarantine: delivered to the Junk Email folder by default, which you can change to quarantine.
p=reject: rejected during the SMTP conversation with 550 5.7.1.

Microsoft also says outbound mail from your domains that fails DMARC at the destination is routed through its high-risk delivery pool when your policy is quarantine or reject. One more reason to fix your own senders before you enforce.

Parked domains

If the tenant holds domains that never send mail, Microsoft suggests locking them down instead of leaving them blank: v=spf1 -all for SPF, v=DMARC1; p=reject; for DMARC, and no DKIM records at all.