A single wrong character in your SPF record can send an entire cold email campaign to spam, and Microsoft 365 will never warn you it happened. Most senders discover the problem weeks later, after reply rates have already cratered. The Microsoft 365 cold email SPF record is one of the most common failure points we see. Almost every case traces back to the same handful of mistakes: two SPF records instead of one, the wrong include value, or a record that quietly blows past the 10-lookup limit and throws a PermError. This walkthrough fixes all of them. You get the exact record to publish, the reason each error happens, and a 5-minute test to confirm the fix before you send another email.
The Silent Failure Nobody Catches Until It's Too Late
Here's the thing about a broken SPF setup. It doesn't throw an error you can see. Your emails still send. Your outbound queue still clears. Everything looks fine from your side of the screen.
But on the receiving end, Gmail and Outlook are quietly reading your authentication results and deciding you're not who you say you are. So they route you to spam. Or worse, in 2026, they reject you outright.
Most teams blame the copy first. They rewrite subject lines. They swap out the offer. They test new sending times. None of it moves the needle, because the problem was never the message. It was the envelope — and specifically, a broken Microsoft 365 cold email SPF record sitting quietly in your DNS.
🚩 The tell-tale sign your SPF is broken
Your open rates were fine for a week, then dropped off a cliff. Replies stopped. Bounce rate is normal. If that pattern sounds familiar, stop editing your copy and go check your authentication records. In practice, a sudden reputation drop with clean bounces is almost always a DNS problem, not a content problem.
We see this pattern constantly with new Litemail customers who bring their own domains. The domain sends through Microsoft 365, the SPF record looks roughly correct, and yet inbox placement is a coin flip. The fix is almost always one of the four errors below. By the end of this, you'll know exactly which one is hitting you and how to clear it.
The One Record That Actually Works
Let's start with the answer, then explain it. If Microsoft 365 is the only service sending mail from your domain, your Microsoft 365 cold email SPF record should be a single TXT record on your root domain, exactly like this:
💡 The correct Microsoft 365 SPF record
v=spf1 include:spf.protection.outlook.com -all
That's it. This is the value Microsoft publishes verbatim in its own documentation. Three parts, each doing a job.
v=spf1 tells receivers this is an SPF version 1 record. include:spf.protection.outlook.com authorizes all of Exchange Online's sending infrastructure — and because Microsoft's IP addresses change constantly, this single include covers every server they use without you ever touching it again. -all is the hard fail. It tells receivers to reject anything that isn't on the list.
Where the record goes
Publish it as a TXT record on the root of your domain. Not a subdomain. Not a new record type. Log into wherever your DNS lives — your registrar or DNS provider — and add or edit the TXT record at the host @ (your naked domain).
Open your DNS management panel.
Look for an existing TXT record starting with v=spf1.
If one exists, edit it — don't add a second one.
Set the value to v=spf1 include:spf.protection.outlook.com -all.
Leave TTL at the default, or set it to 3600 seconds.
Save. Changes usually propagate within an hour.
One caveat worth flagging early. This exact record only applies if Microsoft 365 is your only sender. The moment you add a cold email platform, a CRM, or a form tool, the record changes — and that's where most people break it. More on that in a second.
If your inboxes come pre-configured, this step is already done for you. Every Litemail inbox ships with SPF, DKIM, and DMARC set up correctly on delivery, which removes the single most common first-campaign failure before you even log in. But if you're managing your own DNS, the manual record above is what you need. For the wider setup, our complete Microsoft 365 cold email setup guide covers the MX, DKIM, and DMARC records alongside SPF.
Four SPF Errors That Break Outlook Cold Email
Almost every broken Microsoft 365 cold email SPF record is one of these four errors. Find yours, apply the fix, retest.
Error 1 — Two SPF records on one domain
This is the most common one, and it's brutal because it looks harmless. You had an old SPF record, you added Microsoft's, and now there are two. The rule is absolute: one SPF record per domain. Two records starting with v=spf1 cause a PermError, and SPF fails for every single email you send.
The fix: delete one, and merge everything into a single line. Never stack them.
🚩 Wrong — two records
v=spf1 include:_spf.google.com ~all
v=spf1 include:spf.protection.outlook.com -all
✅ Right — merged into one
v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all
Error 2 — The wrong include value
The only correct include for Microsoft 365 is spf.protection.outlook.com. That's it. And yet we constantly see records using outlook.com, microsoft.com, office365.com, or the old spf.messaging.microsoft.com. None of those authorize your mail. They just sit there doing nothing while your emails fail.
Check your record character by character. If the include isn't exactly spf.protection.outlook.com, that's your bug.
Error 3 — Too many DNS lookups (the PermError trap)
SPF has a hard ceiling. An SPF record can only trigger 10 DNS lookups during evaluation, a limit set by RFC 7208. Go over it and you get a PermError, which fails authentication for every message from your domain.
Why does this keep happening to cold email senders? Because they stack includes. Microsoft's include alone typically eats 2 to 3 of your 10 lookups. Add Google Workspace, a sending platform, a CRM, and a form tool, and you're over the limit before you notice. This drives me crazy because it's invisible — the record looks fine, it's just doing too much.
The fix has three moves, in order of preference:
Remove includes you don't use. Most bloated records carry old tools nobody sends from anymore. Audit and cut.
Split senders onto subdomains. Send marketing from a subdomain with its own lean SPF record, keep the root domain minimal.
Flatten as a last resort. Replace includes with the raw ip4/ip6 ranges. It works, but it goes stale when providers change IPs, so only do this if you can't cut lookups any other way.
Error 4 — SPF passes but DMARC still fails
This one confuses everyone. Your SPF check passes. MXToolbox is green. And your emails still land in spam. What gives?
Alignment. DMARC doesn't just want SPF to pass — it wants the domain that passed SPF to match your From address. If your sending platform passes SPF using its own domain instead of yours, you authenticate but you don't align. DMARC fails. The fix is to make sure your return-path domain matches your From domain, which usually means setting up custom domain authentication inside your sending tool.
Not sure which record is throwing the error? Our guide to checking SPF, DKIM, and DMARC walks through the exact tools to isolate it.
Should You Use -all or ~all? The Cold Email Answer
You'll find endless debate on this. Hard fail (-all) rejects anything not on your list. Soft fail (~all) marks it suspicious but lets it through. So which one for cold email?
Microsoft recommends -all, the hard fail, and publishes it as the default. For a clean single-sender setup, that's the right call. It's the strictest signal you can send, and receivers reward strict, well-configured domains with better placement.
But here's the honest caveat most guides skip. If you run a messy multi-sender setup and you're not 100% sure every legitimate source is listed, -all will reject your own mail the moment you miss one. In that case, start on ~all while you confirm every sender in your DMARC reports, then tighten to -all once you're certain. In practice, move to hard fail — just don't do it blind.
Qualifier | What it does | Best for |
|---|---|---|
-all (hard fail) | Rejects unlisted senders outright | Clean setups, Microsoft's default |
~all (soft fail) | Accepts but flags unlisted senders | Temporary, while auditing senders |
?all (neutral) | No opinion — offers no protection | Never use for cold email |
One thing that is commonly recommended but actually wrong: leaving your record on ~all permanently because it's "safer." It isn't safer. Receivers read a lingering soft fail as a domain that never finished its setup, and DMARC enforcement gets weaker. Soft fail is a pit stop, not a destination.
Merging Multiple Senders Without Breaking Anything
Running Microsoft 365 plus a cold email platform plus a CRM? Then your single SPF record needs all of them on one line, in the right order, under the lookup limit. This is where the real-world mess lives.
Say a 4-person B2B SaaS team sends 300 emails a day. They run Microsoft 365 for their main mailboxes, a sending platform for outreach, and Salesforce for automated follow-ups. Three senders, one domain, one SPF record. Here's what a correct merged record looks like:
✅ Correct merged record (three senders)
v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com -all
Notice what's happening. One v=spf1. One -all at the end. Every sender in between as its own include. The order of includes doesn't matter for validity, but keeping your primary sender first makes the record easier to audit later.
Now watch the lookup budget. Microsoft's include burns 2 to 3 lookups. SendGrid and Salesforce add more. You can hit 8 or 9 fast. Before you publish, run the record through a lookup counter and confirm you're under 10. If you're close, that's your signal to move a sender to a subdomain.
You might be thinking — can't I just add each new tool's include whenever I onboard it? You can, but that's exactly how domains drift into PermError over 18 months. Every time you add an include, recount your lookups. Treat the SPF record as something you maintain, not something you set once and forget.
This is one reason cold email operators increasingly skip DIY DNS entirely. When you buy inboxes with authentication pre-built, the SPF, DKIM, and DMARC records arrive correct and stay correct. If you're weighing that trade-off, our breakdown of pre-warmed inboxes versus DIY warmup lays out where each approach makes sense.
Test the Fix in 5 Minutes Before You Send
Never trust a DNS change until you've verified it. A record that looks right in your DNS panel can still fail in the wild. Run these three checks on your Microsoft 365 cold email SPF record, in order, before your next campaign.
Step 1 — Run an SPF lookup check
Go to mxtoolbox.com, run an SPF Record Lookup on your domain, and confirm three things: exactly one SPF record exists, the syntax is valid, and the lookup count is under 10. If it flags PermError or multiple records, you've found your problem.
Step 2 — Send a test email to Gmail
Send one email from your Microsoft 365 inbox to a Gmail address you control. Open it, click the three dots, and choose Show original. Look at the Authentication-Results header. You want to see:
SPF: PASS
DKIM: PASS
DMARC: PASS
Any FAIL or SOFTFAIL means stop. Don't run a campaign until all three pass. This single test would prevent most of the deliverability disasters we see.
Step 3 — Confirm alignment, not just a pass
In that same Show original view, check that the domain passing SPF matches your From domain. A pass with the wrong domain is the alignment trap from Error 4 — technically green, functionally broken.
💡 Why this matters more in 2026
As of 2026, Gmail and Yahoo reject non-compliant bulk mail outright — a 550 error, not a spam-folder placement. Send more than 5,000 emails a day to Gmail addresses and you're permanently classed as a bulk sender. That means SPF, DKIM, and DMARC all passing, with spam complaints kept under 0.3%. A broken SPF record isn't a soft penalty anymore. It's a wall.
For a full pre-send audit beyond SPF, our DNS setup checklist for cold email covers every record you should confirm before scaling volume.
When the Fix Doesn't Work: Edge Cases
Sometimes you do everything right and SPF still fails. Here's what's usually going on.
You just changed the record and it's still failing. DNS propagation takes time. Most providers update within an hour, but it can take up to 48. Wait, then recheck. Don't keep editing — that just resets the clock.
Your record is right but sits on a subdomain. SPF is checked against the exact domain in your MAIL FROM. If you send from mail.yourdomain.com but published SPF on the root, the subdomain has no record. Publish SPF where you actually send from.
You're on the onmicrosoft.com domain. If you never connected a custom domain, you're sending from the default onmicrosoft.com address, which is a poor look for cold outreach and limits your authentication control. Connect a proper custom domain before you scale — recipients trust it more and you own the reputation.
Hybrid setup with on-prem Exchange. If some mailboxes live on your own servers, you need both the Microsoft include and ip4 entries for your on-prem egress IPs. Miss the ip4 entries and your on-prem mail fails SPF.
And a blunt one: if you're fighting SPF errors across 20+ domains by hand every week, the math has changed. At that scale, manual DNS maintenance costs more in lost deliverability than buying inboxes that arrive pre-authenticated. Know when to stop patching and switch approaches.
Skip the DNS headaches entirely. Litemail pre-warmed Microsoft 365 and Google Workspace inboxes ship with SPF, DKIM, and DMARC already configured — dedicated US and EU IPs, full admin access, $4.99/inbox. Connect via OAuth in 3 minutes and send with a Postmaster-verified reputation from day one. No manual records, no PermError surprises. Get Pre-Warmed Inboxes from $4.99 →
About Litemail — Litemail provides pre-warmed Google Workspace and Microsoft 365 inboxes for cold email outreach. From $4.99/inbox with automated DNS, dedicated US and EU IPs, and full admin access. View pre-warmed inbox plans →
Related reading: Microsoft 365 Cold Email Complete Setup 2026 · DKIM Setup for Microsoft 365 Cold Email · How to Check SPF, DKIM & DMARC · DMARC Not Working? Fix Guide 2026 · Microsoft 365 Cold Email Suspension: How to Avoid It · Litemail Pre-Warmed Inboxes — Plans and Pricing
The Bottom Line
Publish exactly one SPF record per domain. Two v=spf1 records cause a PermError and fail every email you send.
For a Microsoft-only domain, the correct record is v=spf1 include:spf.protection.outlook.com -all — nothing else.
The only valid Microsoft include is spf.protection.outlook.com. Not outlook.com, microsoft.com, or office365.com.
Stay under the 10 DNS lookup limit. Microsoft's include alone uses 2 to 3, so recount every time you add a sender.
SPF passing isn't enough — the passing domain must align with your From address or DMARC still fails.
Use -all hard fail for clean setups; drop to ~all only while auditing senders, then tighten back up.
In 2026, Gmail and Yahoo reject non-compliant bulk mail outright, so verify your Microsoft 365 cold email SPF record, DKIM, and DMARC all pass before sending.
Frequently Asked Questions
What is the correct SPF record for Microsoft 365 cold email?
If Microsoft 365 is your only sender, publish v=spf1 include:spf.protection.outlook.com -all as a single TXT record on your root domain. This is the value Microsoft publishes in its own documentation. If you also send through a cold email platform or CRM, merge every sender into that one record as separate include entries — never create a second SPF record.
Why is my Microsoft 365 SPF record failing even though it looks correct?
The three usual culprits are: two SPF records on the same domain (which causes a PermError), more than 10 DNS lookups in the record, or an SPF pass that doesn't align with your From domain. To debug a Microsoft 365 cold email SPF record, run your domain through MXToolbox to check for duplicate records and lookup count, then send a test to Gmail and read the Authentication-Results header.
What does a PermError mean in SPF?
A PermError is a permanent SPF failure. It usually means your record triggered more than the 10 DNS lookups allowed by RFC 7208, or you have two SPF records on one domain. When SPF hits a PermError, authentication fails for every email you send, which tanks deliverability. Fix it by removing unused includes, splitting senders onto subdomains, or merging duplicate records into one.
Should cold email use -all or ~all in the SPF record?
Use -all (hard fail) for a clean, correctly configured domain — it's Microsoft's own default and receivers reward it with better placement. Only use ~all (soft fail) temporarily while you confirm every legitimate sender is listed in your record, then tighten to -all. Leaving a domain on ~all permanently signals an unfinished setup and weakens DMARC enforcement.
How many DNS lookups does the Microsoft 365 SPF include use?
The spf.protection.outlook.com include typically consumes 2 to 3 of your 10 allowed DNS lookups on its own, because it chains to several nested records. That leaves limited room for other senders, so if you also run Google Workspace, a sending platform, and a CRM, you can hit the 10-lookup ceiling fast. Always recount lookups whenever you add a new include.
Can a wrong SPF record get my cold emails rejected outright in 2026?
Yes. As of 2026, Gmail and Yahoo reject non-compliant bulk mail with a 550 error rather than routing it to spam. If you send 5,000 or more emails a day to Gmail addresses, you're permanently a bulk sender and need SPF, DKIM, and DMARC all passing, with spam complaints under 0.3%. A broken SPF record can stop your mail from reaching any folder at all.
Does Litemail handle the SPF record for cold email inboxes?
Yes. Every Litemail pre-warmed inbox ships with SPF, DKIM, and DMARC pre-configured on delivery, so you avoid the PermError, duplicate-record, and alignment mistakes that break most DIY setups. Inboxes come with dedicated US and EU IPs, full admin access, and a Postmaster-verified reputation from $4.99/inbox — connected to your sending platform via OAuth in about three minutes.
Buy Pre-Warmed Email Inboxes & Domains | Litemail
Buy pre-warmed email accounts, inboxes and domains from $4.99/inbox. Google Workspace & Microsoft 365. Automated DNS with SPF, DKIM, and DMARC done for you, dedicated US & EU IPs, setup in 5 minutes.
No minimum order · SPF/DKIM/DMARC pre-configured · Works with all platforms · US and EU IPs included
Related reading: Microsoft 365 Cold Email Complete Setup 2026 · DKIM Setup for Microsoft 365 Cold Email · How to Check SPF, DKIM & DMARC · DMARC Not Working? Fix Guide 2026 · SPF, DKIM & DMARC Setup Guide for Cold Email · Litemail Pre-Warmed Inboxes — Plans and Pricing
