Emails delivered from certain IP Addresses in M365 get rejected due to SPF fail

Question

Hi Moderators,

There have been some cases where emails which are being delivered are rejected. I took a closer look and it seems that the actual IP ranges in spf.protection.outlook.com differs from what was listed on the Microsoft 365 URLs and IP address ranges.

If I did a nslookup for spf.protection.outlook.com, among other IP ranges, I get this result:

[Moderator note: personal info removed]

[Moderator note: personal info removed]

[Moderator note: personal info removed]

while the M365 URLs and IP Address range list this:

[Moderator note: personal info removed]

Emails which are sent outside of the 3 ranges are currently failing (i.e. 52.103.171.x 52.103.194.x, 52.103.202.x)

Shouldn't spf.protection.outlook.com include [Moderator note: personal info removed] instead, so that SPF check will pass?

Answer 1

Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

Hi Andy Choo

Thank you for reaching out to Microsoft Q&A forum

In my opinion, in this context, you shouldn't use the Microsoft 365 “URLs and IP address ranges” list to judge (or build) SPF, and don’t rely on an A/AAAA lookup of spf.protection.outlook.com. SPF validation is done against TXT records, and Microsoft’s recommended configuration is to reference Exchange Online via include:spf.protection.outlook.com in your domain’s SPF record.

That said, your specific symptom (messages from 52.103.xxx.x / 52.103.xxx.x / 52.103.xxx.x failing SPF) is worth investigating because those IPs are inside 52.100.0.0/14, which Microsoft publishes for *.protection.outlook.com / *.mail.protection.outlook.com connectivity.

Given this, you can try the following workarounds to see if it can help you:

1. Validate you are checking SPF via TXT records (not A/AAAA resolution) by querying the TXT record for spf.protection.outlook.com and confirming what it currently publishes, because SPF is DNS TXT–based.
2. Confirm your domain has a single SPF TXT record and that it includes Microsoft 365 as an authorized sender using include:spf.protection.outlook.com (and merge any other senders into the same single record).

Hope my answer will help you, for any further concern, kindly let me know in the comment section

Regards

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".     

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

The Microsoft 365 SPF include spf.protection.outlook.com is designed and maintained by Microsoft to cover all legitimate outbound IPs for Exchange Online, including the ranges documented under Microsoft 365 URLs and IP address ranges. The fact that nslookup on spf.protection.outlook.com shows ranges like 52.100.0.0/15, 52.102.0.0/16, 52.103.0.0/17 while the documentation lists 52.100.0.0/14 does not indicate a misconfiguration of the Microsoft SPF include.

Key points from the documentation and related guidance:

1. Microsoft 365 uses large, shared IP ranges for outbound mail, and these are documented centrally. For Exchange Online, the documented outbound ranges include 52.100.0.0/14 and others:
   • 40.92.0.0/15
   • 40.107.0.0/16
   • 52.100.0.0/14
   • 52.238.78.88/32
   • 104.47.0.0/17
   • 2a01:111:f400::/48
   • 2a01:111:f403::/48
2. SPF evaluation is based on the SPF TXT record of the sender’s domain, not on the Microsoft documentation page. The Microsoft-managed include (spf.protection.outlook.com) already contains the correct and current set of IPs for Exchange Online. Administrators should reference it via include:spf.protection.outlook.com rather than trying to manually mirror or expand the ranges from the URL/IP documentation.
3. SPF failures for messages sent from Microsoft 365 typically indicate an issue with the sender domain’s SPF record or with how mail is routed, not that Microsoft’s own include is missing IPs. The security operations guidance explicitly states that when SPF fails, the sender must ensure that:
   • All legitimate source IP addresses are covered in the domain’s SPF record.
   • SPF syntax and lookups are correct (no permerror due to too many lookups, multiple SPF records, etc.).
4. If messages from Microsoft 365 IPs are failing SPF at recipients, the usual causes are:
   • The sender domain’s SPF record does not correctly use include:spf.protection.outlook.com (for example, custom or truncated records, multiple SPF records, or exceeding the 10-lookup limit).
   • Complex routing or intermediate services that break SPF alignment, which must be handled by correct SPF design, Enhanced Filtering for Connectors, or ARC where applicable.
5. The Microsoft 365 URLs and IP address ranges page is the authoritative list for firewall and network allow-listing, not for constructing custom SPF content. For SPF, the supported and recommended approach is to use the Microsoft-provided include and keep the domain’s SPF record syntactically correct and within lookup limits.

Therefore, spf.protection.outlook.com does not need to be changed to explicitly show 52.100.0.0/14 to make SPF pass. Instead, ensure that:

• The sending domain has a single, valid SPF TXT record that includes include:spf.protection.outlook.com.
• The record does not exceed the DNS lookup limit and follows the syntax and enforcement guidance (for example, using -all or ~all appropriately).
• Any additional sending services or on-premises IPs are correctly added to the same SPF record.

If SPF still fails for specific messages, the sender needs to review the full SPF record and mail routing path in line with the documented troubleshooting guidance.

---

References:

• Microsoft 365 URLs and IP address ranges
• External senders - Troubleshoot email sent to Microsoft 365
• Recipient rejects mail from Microsoft 365 and host name does not match IP address error
• Set up SPF to identify valid email sources for your custom cloud domains
• Security Operations guide for email authentication in Microsoft 365