EOP SPF Record Now Using PTR

The above alphabet soup could be replaced with, "The Day Microsoft Stopped Hogging all the DNS lookups." First a little background: Sender Policy Framework, or SPF, is used to combat spoofing of email addresses. If you're not familiar with SPF, here's a little background information: http://www.openspf.org/Introduction 

Even if you are familiar with SPF, you may not be familiar with the fact that there is a limitation in the specification regarding how many DNS lookups may be performed. This limit is 10 DNS lookups total. According to the spec, if the number of DNS lookups required to query your SPF records exceeds 10, the MTA MUST return a PermError. Until very recently, Microsoft has pushed up against this limit by consuming 8 or 9 of the available 10 DNS lookups. A recent change has made the situation much more workable.

Most MTAs treat this condition of publishing a record that forces too many DNS lookups the same as a syntax error in your SPF record or no SPF record at all, so your domain may currently be experiencing this symptom without your knowledge. (In other words, this problem in an SPF record does not necessarily mean that your servers will be treated as a hard-fail. I've only ever seen one MTA configured to do that.)

Consider this scenario:

Domain

Record Type Value
 domain.com TXT   "v=spf1 a mx mx:domain2.com -all"
 domain.com A  10.10.10.100
 domain.com MX  10 mail1.domain.com
 domain.com
MX  10 mail2.domain.com
 domain.com MX  20 mail3.domain.com
 domain.com MX  20 mail4.domain.com
 domain2.com MX  10 smtp1.domain2.com
 domain2.com MX  10 smtp2.domain2.com
 domain2.com MX  10 smtp3.domain2.com

What appears to be a simple and modest SPF record is busted with 11 DNS queries: 

  1. Pull SPF record for domain.com
  2. Pull A record for domain.com
  3. Pull MX record for domain.com
  4. Pull A record for MX hostname for mail1.domain.com
  5. Pull A record for MX hostname for mail2.domain.com
  6. Pull A record for MX hostname for mail3.domain.com
  7. Pull A record for MX hostname for mail4.domain.com
  8. Pull MX record for domain2.com
  9. Pull A record for MX hostname for smtp1.domain2.com
  10. Pull A record for MX hostname for smtp2.domain2.com
  11. Pull A record for MX hostname for smtp3.domain2.com

Busted!

This 10 domain limitation has been particularly difficult to work with in Exchange Online for the past several years because the records Microsoft historically published for SPF for EOP and FOPE consumed 8 or 9 of the available 10 DNS lookups. This means that if you had any mail going out of on-premises servers or any third-party mailing services (to work around those outbound limitations in EOP), you were really limited / in big trouble!

Now that the introduction is out of the way... I haven't seen anything from Microsoft on this, but I noticed when looking up the SPF record for spf.protection.outlook.com the other day that the typical maze of nested include: statements is no longer there. Instead, I see this:

"v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

 

I had never seen the PTR mechanism in an SPF record before, and it took me a few minutes to wrap my mind around it. The basic workflow as I understand it is this:

  1. Pull TXT record for domain.com
  2. Pull (included) TXT record for spf.protection.outlook.com
  3. Pull PTR record for IP of sending server and check for match of PTR mechanism domains from step 2

Now, instead of consuming 8 or 9 of the available 10 DNS lookups, EOP's SPF record consumes only 3 which leaves 7 more to be used by on-premises servers or 3rd party mailing services. Many thanks to Microsoft for being willing to share!

Here's more information on the PTR mechanism in SPF: http://www.openspf.org/SPF_Record_Syntax#0.1.6 Would love to discuss with you below! Thanks for reading!

Comments

CAPTCHA Image

Contact

Exact Technical Solutions LLC
2435 E. North Street, #118
Greenville, SC  29615
phone: 864.292.9391

Login