What v=spf1 include:spf.protection.outlook.com Means, and What 38 Real Companies Add to It

This post contains affiliate links. If you buy something through one of them, Veravix may earn a commission at no extra cost to you.

You open your DNS panel and find a line that you do not remember writing: v=spf1 include:spf.protection.outlook.com -all. It is the SPF record Microsoft tells every Microsoft 365 customer to publish, and it looks too short to be doing much. It raises three fair questions. What does each part do, what actually sits behind that include, and why do almost no real companies leave the record that short?

To answer the last two I looked up the live record behind the include, and the SPF records of 91 well-known domains, on 11 October 2026. Ninety of them publish an SPF record, and 38 of those use this exact include. If you want the full setup from scratch, the Microsoft 365 SPF, DKIM and DMARC guide walks through it. This page is the decoder.

Read it left to right

Receiving mail servers read an SPF record from the left and stop at the first term that matches the sending server. Here are the three terms:

Term	What it tells a receiver
v=spf1	This TXT record is an SPF record. A domain gets exactly one of them.
include:spf.protection.outlook.com	Look up Microsoft’s own SPF record. If the server that sent this message is listed there, SPF passes.
-all	Anything not matched above fails. ~all would mean softfail, a probable fake that is accepted but marked.

Microsoft’s documentation recommends -all for Microsoft 365 domains, on the condition that you also set up DKIM and DMARC, since DMARC then decides what happens to a message that fails. It also notes that DMARC’s policy is effectively ignored for a ~all failure when the message carries no DKIM signature, which is the practical reason to prefer the hard fail.

What is behind the include

An include is a pointer, so the real content lives at spf.protection.outlook.com. I queried it through Google’s public DNS on 11 October 2026:

What I counted	Result
IPv4 ranges listed	6, covering 458,752 addresses
IPv6 ranges listed	5
Further includes inside it	None
Cost toward the ten-lookup limit	Exactly 1
Length of the record	248 characters
How it ends	-all

Two things follow from that table. First, this is one of the cheapest big includes you can add. It is a flat list, so the whole of Microsoft 365 costs one lookup of your ten, which leaves room for your other senders. If your record is already crowded, the guide to SPF subdomains and the ten-lookup limit explains how the counting works.

Second, the -all at the end of Microsoft’s record does not hard fail your domain, which surprises people. Under RFC 7208, when an include evaluates to a fail, that only means the include did not match, and the receiver moves on to the next term in your record. Your own final all is what decides the outcome. This is why you can safely put other senders after Microsoft’s include.

Do not paste those ranges into your own record

It is tempting to replace the include with the six IP ranges and save the lookup. Microsoft advises against it for Microsoft 365, because the sending addresses change often and a copied list goes stale without any error to tell you. Flattening is for vendors with a stable, documented set of addresses. For Microsoft, keep the include.

What 38 real organisations wrote around it

I queried the SPF record of 91 large organisations, a mix of universities, public bodies and companies, and 38 of them use this include. Here is how they use it:

What I counted among the 38	Result
Records that are only Microsoft’s include plus an ending	0 of 38
Records that also carry ip4 terms	20 of 38
Records ending in -all	27 of 38
Records ending in ~all	10 of 38
Records ending in ?all	1 of 38
Records with Microsoft’s include as the first term	11 of 38
Records longer than 255 characters	10 of 38
Lookup-costing terms at the top level (Microsoft’s included)	1 to 9, average about 4

The first row is the real answer to why nobody leaves it short. Not one of the 38 has the bare record, because each of these organisations also sends mail through a newsletter tool, a ticket system, an HR platform or an old server. My sample is large organisations, so a small business that only uses Microsoft 365 will look simpler, but the pattern still holds: the one-line record is where you start, not where you stay.

Seven in ten used the recommended -all. One in four was longer than 255 characters, and the longest, from tudelft.nl, ran to 504. A long record is stored as several quoted strings that receivers join back together, and some DNS panels reject a long paste or add a space at the join. How to add an IP address to your SPF record without breaking it covers that length problem in detail.

That average counts only the top level of each record. Whatever is nested inside each include comes on top, so a busy record can pass the limit of ten quickly, and past it every check ends in a permanent error.

Adding your website next to Microsoft

The most common reason to extend this record is a website that sends its own mail, such as order notices or contact form messages. The extended record keeps one SPF record and puts each include on the same line:

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

That example assumes the site is hosted at Hostinger and sends through its mail server. In my lookup that include chains to two more includes, so it costs about three lookups on its own. Together with Microsoft’s one, the record sits at about four of ten, which is comfortable. Your host will publish its own include, so take the exact value from its documentation rather than from this page.

Not the same as outlook.com

The consumer service uses a different record. outlook.com publishes v=spf1 include:spf2.outlook.com -all, and that points to a short list of four ranges, two IPv4 and two IPv6. On the day I checked, all four fall inside the ranges that spf.protection.outlook.com publishes, so the business include already covers them. None of the 90 domains I looked at used include:outlook.com, and Microsoft’s guidance for custom domains names the protection include only.

Government and regional tenants use different includes. Microsoft’s documentation lists spf.protection.office365.us for GCC High and Department of Defense environments and spf.protection.partner.outlook.cn for the 21Vianet service in China. If your tenant is one of those, the commercial include will not match your mail.

Four ways this record breaks

All four come from Microsoft’s own troubleshooting list, and each one makes SPF validation fail:

• A trailing period after the domain, as in include:spf.protection.outlook.com.
• An equals sign instead of a colon, as in include=spf.protection.outlook.com
• A space after the colon, as in include: spf.protection.outlook.com
• A second SPF record for the same domain. Two records cause a permanent error, so edit the existing one rather than adding another.

Each subdomain that sends mail needs its own SPF record too. The record on example.com does not cover shop.example.com, although DMARC does cover subdomains that have no record of their own.

Check yours in five minutes

1. Run nslookup -type=TXT yourdomain.com or dig TXT yourdomain.com +short. You should see exactly one line starting v=spf1.
2. Confirm that line contains include:spf.protection.outlook.com with no trailing period, no equals sign and no stray space.
3. Count your include, a, mx, exists and redirect terms and add what each include nests. If the total is near ten, move bulk senders to a subdomain.
4. Send a test message from a Microsoft 365 mailbox to Gmail, choose Show original and look for spf=pass.
5. If a message still bounces after SPF passes, DMARC may be the cause. Email Rejected by DMARC Policy: How to Read the Bounce and Fix the Sender explains how to read that error.

Checked for accuracy on 11 October 2026 against Microsoft’s SPF setup documentation (last updated July 2026), RFC 7208 and live DNS lookups of 91 domains.