Exchange Online Protection SPF record

[RNalivaika]

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

[#2]

@RNalivaika 

If you think these messages are being sent by legit Exchange Online senders, then I would say it is the senders responsibility to check and modify their SPF records accordingly to ensure all legitimate entries are included.

[#3]

@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

[#4]

@RNalivaika 

I'm facing the same issue in certain circumstances. Did you happen to find a solution for this?

[#5]

@Rick no, sadly, i have not found any solution or explanation to this..

[#6]

@RNalivaika 
I have the same issue. Last problematic mail was sent from 2603:10a6:20b:1ec::22, that is not included in spf.protection.outlook.com

[#7]

@error404 @RNalivaika @PeterRising 

Did you happen to move your core customer data to another geolocation lately? I believe that this might be related ...

Anfordern der Datenverschiebung - Microsoft 365 Enterprise | Microsoft Docs

[#8]

@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.

[#9]

@Rick Yes, we did request geo move for the tenant in question. That might be related, but I don't think we have any way to test and confirm it. R-

[#10]

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.

[#11]

Did you solve this issue?

[#12]

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.

[#13]

This issue might not be resolved by MS soon or ever, because their infrastructure is huge and with a lot of moving parts. I did not get any help from MS365 support, because the issue is so hard to reproduce. Something you can do is activating DKIM signing for sending domains so that your messages could pass authentication despite issues with SPF.