Microsoft 365 sends mail from infrastructure you do not control, so SPF has to name it explicitly. The record itself is one line, but most broken M365 setups fail for one of three reasons: the record is missing, the lookup budget is exhausted, or a second SPF record was added alongside it.
The record Microsoft 365 needs
A domain that only sends through Exchange Online needs a single TXT record at the root:
v=spf1 include:spf.protection.outlook.com -all
The include authorises Microsoft's outbound servers. The -all qualifier tells receivers that anything not listed is unauthorised. Use ~all (soft fail) temporarily if you are still discovering senders, then tighten — but do not leave ~all in place for years and call it done, because soft fail still allows delivery.
Step by step
- Open the public DNS zone for your sending domain, not the
onmicrosoft.com domain created with the tenant.
- Look for an existing
v=spf1 TXT record. If one exists, edit it rather than adding a new one.
- Append
include:spf.protection.outlook.com to the existing mechanisms if other senders are already authorised.
- Save and wait for propagation. TTL determines how long stale answers persist.
- Validate with the SPF Checker and confirm the lookup count it reports.
The 10-lookup limit is the real constraint
SPF allows at most 10 DNS-querying mechanisms per evaluation. Every include:, a, mx, ptr, exists and redirect counts, and nested includes count against the same budget. Exceed it and receivers return permerror — which behaves like a failure, not like "unknown".
This bites M365 tenants that also send through a CRM, a helpdesk, a website form and an ESP. Each one adds an include that may itself contain includes. Tools that report "lookups used" are more useful than tools that only report pass or fail.
If you are over budget, options in order of preference:
- Remove senders you no longer use. Stale includes are the most common cause.
- Move a third-party sender to its own subdomain, so it gets its own SPF record and its own budget.
- Use a static IP or IP range with
ip4: when the sender publishes stable ranges.
- Avoid SPF flattening services unless you understand the trade-off: they replace includes with static IPs, which silently break when the provider changes ranges.
Where SPF stops helping
SPF authenticates the envelope sender (MAIL FROM), not the visible From header. Forwarding breaks it, because the forwarding server becomes the new envelope sender. That is why DMARC exists and why DKIM does the heavy lifting for forwarded mail. If SPF passes but messages still fail DMARC, the problem is alignment, not authorisation — inspect a real message with the Header Analyzer.
For the signing side, see the companion guide on Microsoft 365 DKIM. For a combined check of SPF, DKIM, DMARC, MX and DNS, run the Email Health check.
FAQ
Should the SPF record go on the root domain or a subdomain?
Whatever domain appears in the envelope sender. For M365 that is normally the root domain. If you send marketing mail from a subdomain, that subdomain needs its own record.
Can I have two SPF records?
No. Two records on the same name produce a permanent error. Merge them into one line.
Does -all break forwarding?
It can cause forwarded mail to fail SPF, but that mail can still pass DMARC through DKIM. Do not weaken -all just to accommodate forwarding; fix alignment instead.
