A user complained of not receiving an email to his Gmail account, his 365 email address was set to CC his Gmail account on all incoming mail. Looking in to this we found that the email did arrive to his 365 account but the transport rule to CC his gmail account failed due to the SPF/DKIM check not passing.
The above photo is what we saw in message trace (with the domains switched to “example” for security). As you can see the message to “example.com” which is the 365 email arrived.
But the message to “gmail.com” which is the relay destination on a CC mail flow rule failed to go through.
We clicked on the message that failed to see more details about it, here is the output from this example failure:
“Status
Office 365 received the message that you specified, but couldn’t deliver it to the recipient (example@gmail.com) due to the following error:
Error: 550 5.7.26 This message does not pass authentication checks (SPF and DKIM both 550-5.7.26 do not pass). SPF check for [example.com] does not pass with ip: 550-5.7.26 [40.95.31.57].To best protect our users from spam, the message has 550-5.7.26 been blocked. Please visit 550-5.7.26 https://support.google.com/m. OutboundProxyTargetIP: 74.125.137.27. OutboundProxyTargetHostName: gmail-smtp-in.l.google.com”
This is what it looks like in message trace:
EXPLANATION AND RESOLUTION:
Ignoring the “How to Fix it” Section in the above photo here is what you need to know:
Microsoft publishes a set of IP address in their SPF record (spf.protection.outlook.com), when you include Microsoft’s SPF record in your DNS you’re including those IPs as verified send from mail servers.
What’s less known is that Microsoft also has a range of IPs that are NOT included in their SPF record, some people on forums have speculated that Microsoft made a mistake with this but actually it is intentional and the reasoning is explained here in this article from Microsoft:
To summarize the key notes of that publication from Microsoft:
- The IPs that Microsoft uses for relaying mail or sending what they consider “high-risk” mail is going to be in the 40.95.0.0/16 subnet.
- You can tell if a message was sent via this relay pool by locating the outbound IP used to send (message trace) or looking for “rly” in the outbound server name (also message trace)
- This applies to relayed or forwarded mail
- The incoming email to 365 needs to pass its own check, that is to say the senders domain and email content need to pass SPF checks and spam checks – if it doesn’t this can cause the relay transport rule to fail because the receiving mail server (not Microsoft, the mail server that Microsoft is relaying to) rejects it. When an unsecure-ish email does not pass these checks 365 uses a mail server from the relay pool to transport the email and the receiving mail server may reject it.
- Microsoft also filters regular outbound mail (not relayed) and if it determines that the email is “high-risk” (spam, malicious, etc) it will send it from an unpublished mail server. This is to keep their regular IPs from being blacklisted. Microsoft didn’t state in their article (above) whether the high-risk IP pool is the same subnet as the relay pool.
So, if you are seeing message failure issues in your 365 tenant when relaying mail out of 365 via a transport rule, such as a CC rule for example, take a look in Message Trace (https://admin.exchange.microsoft.com/#/messagetrace) and you’ll likely see a failure message explaining that the sending mail server (msft) did not pass SPF check or DKIM check or something of that sort.
You should also see the sending mail server IP listed in that notice which will fall in the 40.95.0.0/16 subnet.
And finally we get to the resolution, which is to add the relay pool subnet to your SPF record. This will allow emails sent through that relay pool to pass SPF checks since the range will be included in your DNS.
–
If you require further help, please leave a comment and we will answer it as soon as possible.
For professional IT support, please contact ProTek IT Solutions.