Forum Discussion
Exchange Online Protection SPF record
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
- 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.
FYI: It sounds like this is by design / due to those mails not exitting Outlook's infrastructure. There's more detail on this here: https://serverfault.com/a/1154098/137255
It's definitely frustating that the rules aren't consistent, especially as it relies on knowledge of custom MS mail headers if you're using a custom mail client to verify the received mails; but it seems to be legit.
- Thank you for reply.
The interesting thing that I've found is the X-MS-Exchange-CrossTenant-AuthAs: Internal despite the fact that the email was sent to another tenant. I believe it should be CrossTenant.
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.
- 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.- 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.
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.
- 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.
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.
- Did you solve this issue?
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.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.comerror404 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 DocsRick 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-
I'm facing the same issue in certain circumstances. Did you happen to find a solution for this?
Rick no, sadly, i have not found any solution or explanation to this..
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.
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
