May 04 2020 11:16 AM
May 04 2020 11:16 AM
Hi, I have received a message sent via Exchange Online host IPv6 "2603:10a6:20b:c0::31". The message was marked as spam because of SPF fail. Subnet "2603:10a6:20b:c0::/64" is not in the list of O365 servers Microsoft provides: https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges#exchange-online
I see this type of thing happening quite often, both with IPv4 and IPv6 hosts in Exchange Online , with messages sent by legit senders via Exchange Online. What would be the right procedure to deal with this? more than registering a case in O365 admin portal.. Thanks, Ruslan
May 05 2020 08:28 AM
@PeterRisingsender's SPF is OK
"v=spf1 include:spf.protection.outlook.com -all"
but the IP of the exchange online transport server used was not in the list of host in spf.protection.outlook.com , message header states "protection.outlook.com does not designate 'sample ip here' as permitted sender". BR, Ruslan
Jan 25 2021 02:55 AM
Jan 25 2021 07:20 AM
@Rick Looks like that is not related.
I am using as SPF include:spf.protection.outlook.com, most of e-mails go with corrct ip adresses, but few are using incorrect ones.
Another one record i found is spf.protection.outlook.de that is related only to Germany, but our tenant have nothing to do with Gernany, also those few e-mails are never sent from those IPs.
Jul 28 2021 02:43 AM - edited Jul 28 2021 03:04 AM
This occasionally happens to my organisation. We are not involved in geo-relocations.
By far most mails are processed correctly. Just every so often a genuine email gets flagged as spam because O365 delivers using an IPv6 in the 2603: range. What is not part of outlook.com 's SPF include.
The solution is clear: Microsoft should have the ranges being used in their SPF record.
I've contacted Microsoft Support on this issue on 3 occasions in the past year. Support is at all ignoring the fact the mail delivered from a 2603: address. Instead they try so swamp me in standard solutions. Support even sent me a guide how to edit the SPF-record. Microsoft's record.
I beg Microsoft to fix the status of Support. So Support is allowed to provide the engineers with feedback on what's going wrong. Instead of getting fired for not meeting KPIs on standard solutions spat out.
Oct 25 2021 11:30 PM
Just found this post while searching for "SPF Failed for IP - 2603:10a6:102:ad::15". The issue is still there! I cannot believe that MS is aware of having such a problematric issue and not fixing it for months. We are losing money when our emails are filtered out!
For us, it's already too late - we migrated all our services to the cloud years ago ... including exchange 365. But for someone thinking about a migration, I would suggest to wait until this issue has been addressed, fixed and the fix has been publicly announced. Today, I would NOT migrate to exchange 365, because of this issue and the way Microsoft fails to handle it. Email is one of the core services for companies today - a SaaS provider must be able to address such issues quickly and in an appropriate way.
Nov 22 2021 03:47 AM
Aug 03 2022 10:37 AM - edited Aug 03 2022 10:38 AM
I've come across the same issue. Many of my coworkers are using an old version of Outlook which sends mail through smtp.office365.com. Apparently this server uses IP addresses starting with 2603:10b6. However none of these servers are included with
"v=spf1 include:secureserver.net ~all"
So all their mail fails spf and gets flagged. Going through these servers also does not use the DKIM I set up. However if we use the web based email the servers used pass SPF and DKIM is used.
I wish MS would add all the correct IP's to their secureserver.net.
Oct 07 2022 12:43 AM
I see the same thing happing with emails send from an application and using Office365 as SMTP.
The address: 2603:10a6:102:1ce:6 is not in the record spf.protection.outlook.com
Looks like MS is not updating the record, or there are servers which a sending emails which should not be going on the internet that route.
Which IPv6 range should be added, any one an idea? Not planning on manually adding each IP address.
Oct 07 2022 08:50 AM