SPF for Microsoft 365: using include:spf.protection.outlook.com correctly

Almost every Microsoft 365 tenant you manage needs one SPF entry: include:spf.protection.outlook.com. The record itself is simple. Most mistakes happen around it: a second SPF record, the wrong cloud's include, or a record that has grown past the lookup limit. Here's what Microsoft's documentation actually says, and how to apply it across a client base.

The record for a Microsoft 365-only domain

If Microsoft 365 is the only service sending mail as the client's custom domain, Microsoft's recommended SPF TXT record for Microsoft 365 and Microsoft 365 GCC is:

```

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

```

Publish it at the root of the domain (often entered as @) at the client's DNS host. Microsoft notes that there's no admin portal or PowerShell cmdlet in Microsoft 365 for managing SPF in your custom domains. You create it at the registrar or DNS hosting service.

Government and sovereign clouds use different includes

Get this right for regulated clients. Microsoft documents:

• GCC High and DoD: v=spf1 include:spf.protection.office365.us -all
• Microsoft 365 operated by 21Vianet: v=spf1 include:spf.protection.partner.outlook.cn -all

A GCC High tenant with the commercial include will be authorizing the wrong servers.

The onmicrosoft.com domain

If a client sends only from the *.onmicrosoft.com (MOERA) domain, Microsoft says you don't need to do anything. Microsoft owns that domain and maintains its SPF record. You also can't modify it.

-all or ~all?

For Microsoft 365 domains, Microsoft recommends -all (hard fail), because it also recommends DKIM and DMARC for the domain. Microsoft also points out that DMARC treats both -all and ~all as SPF failures, but the DMARC policy is effectively ignored for ~all failures when the message also lacks a DKIM signature. Its recommendation is -all so DMARC can act on messages that fail SPF and also lack DKIM.

Google's documentation recommends ~all for Google Workspace domains, so you'll see both in the wild. For a Microsoft 365 tenant, follow Microsoft's guidance. If you're still inventorying senders, ~all is a reasonable temporary setting. Either way, never use +all. It authorizes every server on the internet.

Adding other senders without breaking SPF

A domain must have only one SPF record. Microsoft says multiple SPF TXT records cause SPF to return permerror. When a vendor's setup guide tells you to "add a TXT record," merge its include into the existing record instead:

```

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

```

Microsoft's examples cover a few common patterns:

• On-premises or hybrid servers that send as the domain: add their public IPs with ip4: or ip6:, as in v=spf1 ip4:192.168.0.10 include:spf.protection.outlook.com -all. (That's Microsoft's documentation example. Use the client's real public IPs.)
• Bulk or marketing services you don't control: Microsoft recommends sending those from a subdomain such as marketing.contoso.com, which gets its own SPF record. This protects the main domain's reputation and keeps lookups under control.
• Subdomains that send mail each need their own SPF record. The parent domain's record doesn't cover them.
• Parked domains that never send mail should publish v=spf1 -all.

If a tenant sends through both Google Workspace and Microsoft 365 (for example, during a migration), Google's documentation shows a combined record: v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all.

Lookups, TTL, and flattening

SPF is limited to 10 DNS-querying terms per evaluation (RFC 7208). Microsoft's troubleshooting guidance says each include: costs at least one lookup, and nested includes add more. When we checked on Oct 13, 2026, spf.protection.outlook.com contained only ip4/ip6 ranges, so it cost one lookup. Microsoft can change that record at any time, so recount rather than assume.

Two Microsoft-specific notes:

• Don't flatten the Microsoft 365 include. Microsoft states that its sending infrastructure uses IP addresses that change frequently, and lists include:spf.protection.outlook.com under "when you shouldn't flatten."
• TTL: Microsoft recommends a minimum TTL of 3600 seconds (one hour) on SPF TXT records.

Also watch for the syntax errors Microsoft lists: a trailing dot (spf.protection.outlook.com.), include= instead of include:, and a space after the colon.

SPF is only one of the three

Microsoft is explicit that SPF alone is not enough. For a custom domain you should also:

1. Turn on DKIM for the custom domain. In Microsoft 365, this means publishing two CNAME records (selector1._domainkey and selector2._domainkey) with the values Microsoft shows for that domain in the Defender portal or Exchange Online PowerShell, then enabling signing. Without custom-domain DKIM, the signature won't align with the client's From domain.
2. Publish DMARC and move it toward enforcement once reports are clean.

A quick client checklist

• One v=spf1 record at the root, and only one.
• The include matches the client's cloud (commercial/GCC, GCC High/DoD, or 21Vianet).
• Every other sender is merged in or moved to a subdomain.
• The record ends in -all (or ~all while you're still inventorying), never +all.
• Total lookups across the tree are 10 or fewer.
• DKIM is enabled for the custom domain, and DMARC is published with rua.

Check a tenant's SPF now

Run the free SPF checker →

It walks the include tree, counts lookups against the RFC 7208 limit of 10, recognizes Microsoft 365 and other common senders, and flags +all, ?all, duplicate records, and other permerror causes.

Founding Partner: $1,999, one time. Check SPF, DKIM, and DMARC on every Microsoft 365 client from one place. Founding Partner covers 50 client domains with full branding (logo and colors), weekly rescans and change alerts, unlimited Security Briefs (150 prospect scans a month), the Grow toolkit, the Policy library, a branded service menu, webhooks, the API, and MCP access (except quote drafts). If you later subscribe to Pro, you pay $299/mo instead of $399 for as long as that Pro subscription stays active. The offer is capped at 50 seats and closes on Dec 15, 2026, or when all 50 seats are claimed, whichever comes first. Proposals and the Service Library require Pro. Founding Partner is non-refundable, except that you're refunded if the seats run out before your payment can be fulfilled.

See Founding Partner details →