18 Dec Email from outlook.com servers failing SPF records
Over the last 24 hours we have seen a few instances where valid email from Outlook.com servers has been rejected by our customers MDaemon and SecurityGateway servers due to SPF record checks.
The emails getting rejected do appear to be valid messages but have been arriving from an IP address not included in the sending servers SPF records. The common factor here is that all the sending domains are using outlook.com services.
If you are new to SPF records before I try to explain the issue its worth having a look at our overview post here.
The SPF rejection problem is not effecting all emails from Outlook.com customers but occasionally when a specific email is delivered via a selection of Microsoft SMTP servers on a specific IP range they get rejected.
If you think that you are missing messages because of this issue the easiest way to check is to use the very useful Dmarcian website to clearly show the SPF record for the senders domain
This will allow you to easily breakdown the SPF record and expands any included records to provide you with a full list of valid sending servers IP address/ranges for the specific domain.
In all the examples we have seen the sending domain includes the SPF records for spf.protection.outlook.com and the servers effected are not listed here.
You can double-check this by looking in the MDaemon or SecurityGateway logs for the IP address of the sending server and then cross reference this against the full list of IP’s in the SPF record.
Typical example.
in this example the sending domain was cmsluk.co.uk
And in the MDaemon logs you can see the SMTP session is arrining from the IP address157.55.234.101
Wed 2014-12-17 18:11:44.796: ———-
Wed 2014-12-17 18:11:47.313: Session 975942; child 0001
Wed 2014-12-17 18:11:47.313: Accepting SMTP connection from [157.55.234.101:39648] to [192.168.254.2:25]
Wed 2014-12-17 18:11:47.314: Performing PTR lookup (101.234.55.157.IN-ADDR.ARPA)
looking on Dmarcian for that domain the result shows
You can see that the IP address is not included in any of the ranges in the list so this is why the SPF check fails.
Interestingly the next SMTP session from this domain then came from the IP 157.56.112.134, which is included under the 157.56.112.0/24 section so the SPF check passed.
Workarround
Whilst writing this article I have re-run some more checks on domains that previously were failing and it does seam that the correct SPF records are now being added by Microsoft, but in other examples they are still missing. so our best advice would be to either whitelist the sending domain in the SPF whitelist using a wild card .
For example if you add *@cmsluk.co.uk then MDaemon would no longer check for SPF records on that domain. Or if you can wait a few hours you may find that the records do get updated correctly and email gets accepted.
Hopefully you can see how we diagnosed this issue and how you can check your own SPF records should you need to.