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.

[#14]

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.

[#15]

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. 

[#16]

I used "v=spf1 ip6:2603:10b6::/37 include:secureserver.net ~all". I believe it includes most IP's starting with 2603:10b6 which overcompensates. But I couldn't think of any other way. Most of the emails pass through with this, but I still see some IP's which are not designated... For example 2603:10b6:a03:202::9 is not designated.
Another odd thing is when I receive an email via Gmail, even if the email passes SPF, Gmail sometimes flags it as possible spam.

[#17]

we had the same issue all of sudden most of our emails was marked spam and when we contacted MS support they fallow the standard MS support spam filter, email policies ..etc even though we clearly told them it seems the emails that was send from IPV6 like 2603:10c6:10:e::17 it was marked as spam and this IP is belong MS. why is that? after 3 days of none sense and lost of emails we did our investigation 

https://www.spf-record.com/spf-lookup/spf.protection.outlook.com?ip=2603:10c6:10:e::17

IPV6 start with 2603: is not part of spf recorders that cause our email to fails SPF check further more the entire 2603:1000::/24 is belong to Microsoft network.

since we added the ipv6 record to our spf record our email seems to be fine 

v=spf1 include:spf.protection.outlook.com ip6:2603:1000::/24 -all

until MS figure out how to implement basic things like SPF 🙂 

[#18]

I've done a few tests now and think I can explain it...

I see 2603:10b6::/37 IPs show up when I send emails to other mailboxes under our tenant.
However, if I send mails externally (e.g. to a gmail address) I see the IPs listed in the SPF record (e.g. 2a01:111:f403:261b::700).

Similarly, mails sent internally don't include a DKIM selector (header.s=selector1 / header.s=selector2), whislt those sent externally do.

So I think this behaviour may be by design; but (to the best of my Google-fu) I can't find this documented anywhere.

i.e. When mails are sent internally, MS already knows they're valid, so doesn't bother following the normal processes which would allow a mail to be verified via DMARC. But when mails are sent externally it does use an IP covered by SPF and a selector covered by DKIM as expected.

That's my theory though; not a verified fact.

[#19]

More info on this thread: https://serverfault.com/questions/1154095/spf-spf-protection-outlook-com-is-invalid-for-messages-wit...
It looks likely that SPF and DKIM are not relevant when the header `X-MS-Exchange-Organization-AuthAs` has value `Internal`.

[#20]

The issue is still there. Emails from our tenant are sent from 2603:10a6:800:16f::8 which is not listed in spf.protection.outlook.com.