Home / server / Questions / 549990
In Process
Sammitch
Asked: 2013-11-01 10:36:58 +0800 CST

Office365 SPF record has too many lookups

  • 772

For some utterly ridiculous administrative reasons we've got a split domain with one mailbox on Office365 which requires us to add include:outlook.com to our SPF record. The problem with this is that that rule alone requires nine DNS lookups of the maximum of 10.

Seriously, it's horrible. Just look at it:

v=spf1
include:spf-a.outlook.com
include:spf-b.outlook.com
ip4:157.55.9.128/25
include:spfa.bigfish.com
include:spfb.bigfish.com
include:spfc.bigfish.com
include:spf-a.hotmail.com
include:_spf-ssg-b.microsoft.com
include:_spf-ssg-c.microsoft.com
~all

Given that we have our own large-ish mail system we need to have rules for a, mx, include:_spf1.mydomain.com, and include:_spf2.mydomain.com which puts us at 13 DNS lookups which causes PERMERRORs with strict SPF validators, and completely unreliable/unpredictable validation with non-strict/badly implemented validators.

Is it possible to somehow eliminate 3 of those include: rules from the bloated outlook.com record, but still cover the servers used by O365?

Edit:

Commentors have mentioned that we should simply use the shorter spf.protection.outlook.com record. While that is news to me, and it is shorter, it's only one record shorter:

spf.protection.outlook.com
  include:spf-a.outlook.com
  include:spf-b.outlook.com
  include:spf-c.outlook.com
  include:spf.messaging.microsoft.com
    include:spfa.frontbridge.com
    include:spfb.frontbridge.com
    include:spfc.frontbridge.com

Edit²

I suppose we can technically pare this down to:

v=spf1 a mx include:_spf1.mydomain.com include:_spf2.mydomain.com include:spf-a.outlook.com include:spf-b.outlook.com include:spf-c.outlook.com include:spfa.frontbridge.com include:spfb.frontbridge.com include:spfc.frontbridge.com ~all

but the potential issues I see with this are:

  1. We need to keep abreast of any changes to the parent spf.protection.outlook.com and spf.messaging.microsoft.com records. If anything is changed or [god forbid] added we would have to manually update ours to reflect that.
  2. With our actual domain name the record's length is 260 chars, which would require 2 strings for the TXT record, and I honestly don't trust that all of the DNS clients and SPF resolvers out there will properly accept a TXT record longer than 255 bytes.
email

2 Answers

  1. As of some recent date, Microsoft has "fixed" this problem by getting rid of all sub-records and using 2 or 3 "ptr" records instead:

    $ dig TXT spf.protection.outlook.com
spf.protection.outlook.com. IN  TXT "v=spf1 ptr:protection.outlook.com ptr:o365filtering.com -all"

$ dig TXT spf.messaging.microsoft.com
spf.messaging.microsoft.com. IN TXT "v=spf1 ptr:protection.outlook.com ptr:messaging.microsoft.com ptr:o365filtering.com -all"

    Here's the problem: while this will help Office 365 clients avoid stay below the "Too many lookups" PermError ... it does so by forcing every mailserver in the world to do (expensive) PTR lookups for every IP address that connects to them.

    Per the SPF specification:

    If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

    • 3

  2. We have also found this issue. Microsoft are 'encouraging' you to use Office 365 exclusively for your email as there is no room now to add new items.

    The way we got around it was twofold.

    First, we can pare down DNS lookups by adding the other entries as explicit IPv4 entries. This lets us add a number of explicit IPs before we include:outlook.com

    Secondly, we set up a separate subdomain under our main domain for the Office 365 stuff. This way, emails @foo.company.com get the Office 365 SPF, and emails @comapny.com get our normal SPF. It's not perfect, but fortunately the places where we have used Office 365 are all able to use email addresses within the subdomain rather than the base domain.

    • 1