Setting up SPF for Microsoft 365 — Step-by-Step Guide (2026)

Last updated: July 2026

In short: After this guide your domain publishes a correct SPF record for Microsoft 365 — including the special cases of hybrid setup, newsletter subdomain, and parked domains.

Prerequisites

A Microsoft 365 tenant with your own domain
Access to your domain’s DNS management — which is not at Microsoft, but at your domain/DNS provider

What is SPF?

SPF (Sender Policy Framework) is a TXT record in your domain’s DNS. It lists which mail servers are allowed to send email with your domain as the sender. Receiving servers look up the record on every incoming message and check whether the delivering server is on the list. Without SPF, any server can send mail in your name — and your legitimate mail lands in spam faster.

For context: SPF alone is not complete protection. Only together with DKIM and DMARC does it become a solid foundation — and Microsoft itself explicitly recommends all three.

The starting point at Microsoft 365

Two things distinguish Microsoft 365 from classic hosts:

1. There is no SPF interface in Microsoft 365. Microsoft’s documentation says it plainly: the SPF TXT entry is created at the domain registrar — no SPF configuration is available in Microsoft 365 itself. So you enter the record where your DNS zone is. How that works in each case is shown in our guides for IONOS, Strato, All-Inkl, and Netcup.

2. Microsoft recommends -all (hardfail). While German hosts almost universally suggest the milder ~all, Microsoft explicitly recommends -all for 365 domains — reasoning that DKIM and DMARC belong to the picture anyway, and that DMARC with ~all doesn’t take effect without a DKIM signature.

The only exception: you can’t change the SPF entry of your *.onmicrosoft.com domain — that one is managed by Microsoft.

Step-by-step guide

1. Check whether SPF is already active

Fastest via the terminal:

dig TXT example.com +short | grep spf1

Alternatively, drop your domain into the free MXAudit scanner — it checks the record for syntax and lookup limits at the same time. Many domains already have an SPF record from the host; that one then has to be extended for Microsoft 365, not replaced.

2. Choose the right record

Only Microsoft 365 sends (the normal case):

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

Most Microsoft 365 organizations need exactly this include value. It points to a flat list of Microsoft IP ranges (IPv4 + IPv6) and costs only a single DNS lookup.

Hybrid setup with a local Exchange/mail server: add your server’s public IP, Microsoft’s own example:

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

Newsletter/bulk sending via an external service: Microsoft recommends a dedicated subdomain for this (e.g. marketing.example.com), so your main domain’s reputation stays untouched. The subdomain’s record (Microsoft’s example with the fictional service Adatum):

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

Parked domains that never send: forbid sending entirely:

v=spf1 -all

3. Enter the record at the DNS provider

Create the chosen value as a TXT record on the main domain (host @) — at your registrar or DNS host, not in the Microsoft 365 admin center. If a TXT entry with v=spf1 already exists there, edit it and add include:spf.protection.outlook.com — only one SPF entry is allowed per domain.

4. Consider subdomains

According to Microsoft, every defined subdomain needs its own SPF entry — the main domain’s record doesn’t apply automatically. For undefined subdomains, DMARC takes over protection.

5. Wait until the change is live

DNS changes take time: depending on TTL and caching it can take a few hours until every server worldwide sees the new record.

The components in detail

Component	Meaning
`v=spf1`	version identifier, always at the start
`include:spf.protection.outlook.com`	allows the Microsoft 365 sending infrastructure (flat IPv4/IPv6 list, 1 lookup)
`ip4:` / `ip6:`	allows individual servers of your own (hybrid scenario)
`-all`	hardfail: non-listed servers are rejected — Microsoft’s recommendation for 365 domains

Special cases for US government clouds: GCC High and DoD use v=spf1 include:spf.protection.office365.us -all instead of the standard include.

Verify the result

Check your configuration with the free MXAudit scanner — it shows immediately whether your SPF record is syntactically correct and how many DNS lookups it consumes (the limit is 10).

Or directly in the terminal:

dig TXT example.com +short | grep spf1

The output must contain exactly one record with v=spf1.

Common mistakes

Created a second SPF record instead of extending the existing one. Placing the Microsoft record next to the existing host record produces a permerror — receiving servers then ignore SPF entirely. All include values belong in a single record.

Forgot subdomains. Every sending subdomain (newsletter, ticketing system) needs its own SPF entry. The main domain doesn’t cover them.

~all out of old habit. With Microsoft 365 there’s no case for softfail: Microsoft recommends -all, precisely because DKIM and DMARC are added. Keeping ~all gives away protective effect.

+all at the end. A +all allows any server to send and makes the whole record useless — don’t copy it.

Forwarding fails. If a recipient auto-forwards your mail, SPF often fails at the final recipient — the forwarding server isn’t in your record. That’s a design weakness of SPF, not a configuration error; DKIM and DMARC catch this case.