0365 mail users are encouraged to use include:spf.protection.outlook.com -all in their SPF record.

I have followed this guidance. My company's spf record says:
v=spf1 include:spf.protection.outlook.com -all

the spf.protection.outlook.com record ends with include:spfa.protection.outlook.com -all which ends with include:spfb.protection.outlook.com

Each of those includes has a set of CIDRs for IPs used by outlook.com when sending email.

However, I am getting DMARC reports from google.com indicating an SPF FAIL for an IP that is actually covered by one of the includes in the SPF record. I think this is incorrect, yet is happening frequently.

Here is an example:







the rejected ip is part of ip4: which is part of the spfb.protection.outlook record:

spfb.protection.outlook.com. 394 IN TXT "v=spf1 ip6:2a01:111:f400::/48 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: -all"

So, why is Google's email server treating this as an SPF fail?

This is not an isolated example - I receive frequent SPF fail notifications with respect to IPs included in the SPF record.

  • Is the mail in question sent directly from a regular office 365 mailbox? It would help to see the entire set of email headers on a rejected message. You can obfuscate the email addresses, but everything else should be left intact. – Appleoddity Feb 4 '18 at 5:31
  • The mail is not being rejected. DMARC evaluates DKIM and SPF, and if either pass, the mail is treated as 'pass'. What I am trying to figure out is why the SPF is failing, when it shouldn't. Also, these are outgoing emails, so I do not receive them, so cannot review their headers. The information about the SPF is coming to me via DMARC aggregation reports sent to me by DMARC participant mailservers - including Google and Yahoo. I have included an extract from one of those in the OP. And, yes, the outgoing mail is being sent from regular 0365 mailboxes. – OzPHB Feb 4 '18 at 5:52
  • Please help, I think i'm asking similar question here – Yevgeniy Afanasyev Jun 12 '19 at 4:07

I have figured it out. Not surprisingly, it was me misinterpreting the report, not Google getting their DMARC implementation wrong :)

The SPF result in the policy evaluated section that I was being confused by (copy posted in OP) is the DMARC evaluated SPF result after considering alignment.

This quote here explains the issue:

Please note that the SPF and DKIM results in the auth_results are raw results, regardless of Identifier Alignment; he results of the DMARC evaluation with Identifier Alignment are in the policy_evaluated section.

I checked the rest of the record and found that the raw results for the same record were, correctly, SPF pass.

So, what the DMARC report was telling me was that, while the SPF result was indeed from outlook.com (and hence was a raw 'pass') the return path header did not match my sending domain, which produces a DMARC evaluation SPF fail. Another reference here.

Basically, do not attempt to read the XML reports directly - they are hard for humans! I found this DMARC xml parser which does a fabulous job of allowing you to clearly see what the DMARC report is trying to tell you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.