How to set up SPF for Microsoft 365

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.

• 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.

Common 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.