SPF (Sender Policy Framework, RFC 7208) authorizes specific servers to send mail for your domain. When you start sending through Microsoft 365, you must publish a single SPF record at your domain apex that includes Microsoft 365's sending infrastructure — otherwise the messages will fail SPF, your DMARC checks will fail, and your mail will land in spam or be rejected outright.
If you already publish SPF for another sender (Google Workspace for inbound, a marketing tool, your CRM), do not publish a second record. Merge the new include into the existing record. RFC 7208 §3 forbids multiple SPF records on the same name and receivers MUST return permerror when they see one.
Publish these DNS records
Add the following record(s) to your domain's DNS zone. Most registrars (Cloudflare, Route 53, Namecheap, GoDaddy) accept values exactly as shown.
- Type
TXT- Host
@- Value
v=spf1 include:spf.protection.outlook.com -all
- Microsoft recommends `-all` directly. Their inbound infrastructure is mature enough that the additional strictness rarely causes legitimate-mail problems.
- If you use Microsoft 365 alongside on-premises Exchange or another sender, append the relevant `include:` mechanisms before `-all`.
Where in Microsoft 365
The SPF configuration lives in Microsoft 365 Defender → Policies & rules → Threat policies → Email authentication settings.
Verify the records
Once published, run the SPF Checker on your domain to verify the lookup chain expands cleanly and stays under the 10-DNS-lookup limit.
dig +short TXT your-domain.comCommon pitfalls
- Forgetting to enable DKIM signing in the Defender portal after publishing the CNAMEs is the single most common Microsoft 365 setup error.
- Older Microsoft documentation references `selector1` only — both `selector1` and `selector2` are required as of 2023.
- If you use Microsoft 365 as your inbound mail (MX) and a separate ESP for marketing, the SPF record above is for outbound through Microsoft only. Marketing mail needs its own `include:` merged in.
- The `<tenant>` value is your initial `*.onmicrosoft.com` name (set when the tenant was created), not your custom domain. To confirm it, run `Get-DkimSigningConfig -Identity your-domain.com | Format-List Selector1CNAME,Selector2CNAME` in Exchange Online PowerShell — the right-hand side of those values is exactly what to paste into DNS.
- If you previously published `selector1._domainkey` as a TXT record (some old guides used raw keys), delete it before publishing the CNAME. A CNAME at a host with any other record type is invalid and DNS providers will reject or silently drop one of them.
Frequently asked questions
What is the correct SPF record for Microsoft 365?
The standard SPF record for Microsoft 365 is: v=spf1 include:spf.protection.outlook.com -all — published as a TXT record at your domain apex (@). Microsoft recommends -all (hard fail) rather than ~all because Exchange Online's sending IP ranges are well-defined and the extra strictness rarely causes legitimate-mail problems. If you send from other services in addition to Microsoft 365, merge their include: mechanisms into the same record.
Does Microsoft 365 require SPF if DKIM is already configured?
DMARC passes if either SPF or DKIM alignment passes — so technically you could rely on DKIM alone. However, Microsoft's own guidance and most security standards require both. SPF protects the envelope sender; DKIM protects the signed headers. Having both gives DMARC alignment two paths to pass, which means forwarded mail (where SPF alignment breaks) still passes via DKIM.
I already publish SPF for Google Workspace — how do I add Microsoft 365?
Merge the Microsoft 365 include into your existing record: v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all. This is a single TXT record at @. Do not publish a separate record — multiple SPF records at the same name cause a PermError that fails authentication for all mail from your domain. Check the total lookup count with the free SPF checker at mailermonk.com/tools/spf-checker.
What is spf.protection.outlook.com?
spf.protection.outlook.com is Microsoft's consolidated SPF include that covers all Exchange Online sending IP ranges. When a receiving server evaluates your SPF record and hits this include, it resolves the full list of Microsoft's sending infrastructure IPs and checks whether the sending IP is among them. Microsoft keeps this list updated — by using include: rather than hardcoding IPs, your SPF record stays current as Microsoft's infrastructure changes.
Want to know if it actually keeps working?
MailerMonk continuously watches your SPF record, aggregate DMARC reports, and inbox placement — and pings you the moment something drifts. Free for the first domain.
Start free trialAbout the author
Other records for Microsoft 365
SPF setup for other ESPs
- workspace.google.comSPF for Google Workspace
- sendgrid.comSPF for SendGrid
- mailgun.comSPF for Mailgun
- aws.amazon.comSPF for Amazon SES