outlook.com sending from MS-owned IPs that are outside their SPF?
Posted by abqcheeks@reddit | sysadmin | View on Reddit | 7 comments
I'm having trouble because we (my SMTP servers) are rejecting emails from outlook.com users (in particular, but maybe not exclusively, messages being forwarded by outlook.com users), that are sent from MS infrastructure, but from subnets outside of the SPF record for outlook.com.
Outlook.com SPF is "v=spf1 include:spf2.outlook.com -all" and spf2.outlook.com contains ip4:40.92.0.0/16
We're seeing messages from outlook.com addresses sent by IPs in 40.93.0.0/16
Also of interest, the SPF record that I believe ms365 customers are told to use, spf.protection.outlook.com contains ip4:40.92.0.0/15 ... note the /15, which means that block includes 40.93.0.0/16
Looking for discussions about this online is often confused by the above. I have seen several people and AI bots say that, e.g. 40.93.2.68 is covered by outlook.com's SPF, because they saw the /15 in spf.protection.outlook.com. But it's spf2.outlook.com that matters in this case.
Anybody got any ideas on where to report this? Most of the suggestions I've seen for reporting it to MS involve logging in to some sort of MS account to start, and I don't have one of those.
Or am I being dumb and SPF is so yesterday and I should let those mails through because of some other signal?
TIA
Budget_Note4222@reddit
You are correct that SPF evaluation depends on the specific domain in the Return-Path and not just any Microsoft SPF record. The /15 in spf.protection.outlook.com does not automatically apply to outlook.com consumer traffic. What you are likely seeing is Microsoft using shared outbound infrastructure that is not fully reflected in every published SPF include chain. This is why strict SPF rejection often breaks legit mail from large providers. The safer approach is combining SPF with DKIM and DMARC alignment instead of relying on IP matching alone
shokzee@reddit
You're not being dumb, this is a legit Microsoft misconfiguration. Their consumer outlook.com SPF (spf2.outlook.com) uses a /16 for 40.92.x.x while their commercial SPF (spf.protection.outlook.com) uses a /15 that covers both 40.92.x.x and 40.93.x.x. So yeah, forwarded mail from outlook.com consumer accounts hitting 40.93.x.x IPs will fail SPF by design of their own record.
This is almost certainly a case where MS is sending from infrastructure they forgot to add to the consumer SPF. We see this with our clients all the time where legit Microsoft mail fails SPF and the only thing saving it is DKIM alignment. Check if those messages have a valid DKIM signature from outlook.com that passes. If DKIM is passing and aligned, DMARC will still pass regardless of the SPF failure, and that's probably why Microsoft hasn't noticed or cared enough to fix it.
As for reporting it, good luck. Without an MS account your best bet is probably their postmaster page at https://sendersupport.olc.protection.outlook.com/pm/ but honestly I wouldn't hold my breath on a fix. In the meantime, if you're doing DMARC-aware evaluation on inbound mail rather than hard-failing on SPF alone, those messages should flow fine assuming DKIM holds up.
lolklolk@reddit
This is expected behavior for emails transiting the relay IP pool. They're not meant to pass SPF by design.
https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-high-risk-delivery-pool-about
abqcheeks@reddit (OP)
Thanks for that info. I don't like this situation but it makes a little more sense now. Kinda wish we'd all recognized in 2000 or so that SMTP wasn't up to the task and we should just start over.
WorryAccomplished160@reddit
This is a known issue — Microsoft's outlook.com SPF (spf2.outlook.com) uses 40.92.0.0/16 but their actual sending infrastructure also uses 40.93.0.0/16, which is only covered under spf.protection.outlook.com via the /15. So you're not being dumb — it's genuinely misconfigured on Microsoft's side.
A few thoughts:
You're right about the SPF gap. 40.92.0.0/15 covers both 40.92.x.x and 40.93.x.x, but 40.92.0.0/16 only covers 40.92.x.x. The outlook.com SPF chain points to spf2.outlook.com which has the /16, not the /15. So 40.93.x.x legitimately fails SPF for outlook.com senders.
Reporting to Microsoft: Without an MS account, your best bet is the https://sender.office.com/ — it doesn't require a login. You can also try postmaster@outlook.com directly. The issue is that Microsoft likely knows and just hasn't updated spf2.outlook.com to match spf.protection.outlook.com.
On "SPF is so yesterday": Not exactly, but you probably shouldn't hard-fail on SPF alone. Check your DMARC evaluation — if the message passes DKIM with a d=outlook.com aligned domain, it passes DMARC regardless of SPF failure. Most modern mail servers evaluate DMARC (SPF or DKIM, either passing + aligned = pass). If you're rejecting purely on -all SPF without considering DKIM/DMARC, that's likely where the pain is coming from.
TL;DR: Microsoft's SPF for outlook.com is genuinely wrong/incomplete. But the practical fix on your end is to make sure your rejection policy is DMARC-based, not SPF-only. Those messages almost certainly pass DKIM.
lolklolk@reddit
This is expected behavior for emails transiting the High-risk Delivery pool. They're not meant to pass SPF by design.
https://learn.microsoft.com/en-us/defender-office-365/outbound-spam-high-risk-delivery-pool-about
The_Koplin@reddit
Outlook.com has an spf include of spf2 as you said and the sender is outside of the /16 allowed. Thus it is proper to drop them. The protection.outlook.com is typically for non outlook users. It’s what I see on o365 tenants not on Microsoft’s own server but that’s just my observations