I'm encountering a problem where my SMTP servers are rejecting emails sent from Outlook.com users, especially those that are forwarded, due to the messages originating from IP addresses that don't appear in Outlook's SPF record. The SPF for Outlook.com is set to 'v=spf1 include:spf2.outlook.com -all', and spf2.outlook.com only includes the IP range 40.92.0.0/16. However, I've noticed emails from Outlook.com being sent through IPs in the range 40.93.0.0/16.
Interestingly, the SPF record recommended for Microsoft 365 customers, spf.protection.outlook.com, includes the wider range 40.92.0.0/15 which covers the problematic 40.93.0.0/16 range. There seems to be confusion in discussions online about this SPF overlap, with some claiming that IPs like 40.93.2.68 are covered by Outlook's SPF simply because they reference the /15 range. But it's really the spf2.outlook.com record that matters in my situation.
I'm seeking advice on how to report this issue. Most suggestions for reporting to Microsoft involve having an MS account, which I don't have. Alternatively, am I misunderstanding something about SPF, and should I just allow these emails through based on other signals? Thanks in advance for any help!
3 Answers
Absolutely! SPF validation is highly dependent on the Return-Path domain, not just any Microsoft SPF entry. The /15 range in spf.protection.outlook.com doesn't uniformly apply to all Outlook.com consumer traffic. Microsoft likely uses shared outbound infrastructure that isn’t completely outlined in their SPF records. This can lead to legitimate emails being incorrectly rejected. Instead of only relying on SPF, combining it with DKIM and DMARC alignment is a more reliable approach!
You're definitely not alone in this! This seems to stem from a misconfiguration on Microsoft's side. The consumer Outlook.com SPF (spf2.outlook.com) specifies a /16 for the 40.92.x.x range, while the commercial SPF (spf.protection.outlook.com) covers both 40.92.x.x and 40.93.x.x with a /15. This means if forwarded emails come from 40.93.x.x, they'll fail SPF checks by design.
You should check if those emails have a valid DKIM signature from Outlook.com. If DKIM passes and aligns, DMARC will succeed despite the SPF failure, which might explain why Microsoft hasn’t fixed it yet. As for reporting, without an MS account, your best bet might be the postmaster page, though I wouldn't hold my breath for a fix soon. In the meantime, if you're not strictly failing SPF checks, emails should come through fine if DKIM is okay!
You're right, dropping those emails is the correct action since the sender is outside the allowed /16 range. The protection.outlook.com SPF is mainly for non-Outlook users, which confirms your observations about those on Office 365 tenants rather than Microsoft’s own servers. The distinction is crucial, especially when handling email from large providers.
That makes total sense! I didn't realize DKIM could provide a workaround for SPF failures. Thanks for the tip!