Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For some utterly ridiculous administrative reasons we've got a split domain with one mailbox on Office365 which requires us to add 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:


Given that we have our own large-ish mail system we need to have rules for a, mx,, and 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 record, but still cover the servers used by O365?


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


I suppose we can technically pare this down to:

v=spf1 a mx ~all

but the potential issues I see with this are:

  1. We need to keep abreast of any changes to the parent and 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.
share|improve this question
Can you not just add for all of Office365? – Cold T Oct 31 '13 at 18:47
Why isn't the SPF record for O365 the simple current one? (curious to be honest, never seen what you have setup...did the portal tell you to put all of that?) – TheCleaner Oct 31 '13 at 18:47
All the documentation I found said to use, so is news to me. The problem remains though, since that record still requires 8 lookups, and I need to get it down to 6 or lower. – Sammitch Oct 31 '13 at 19:24
Don't forget to count the two PTR lookups under ''. According to RFC 7208 they also count toward the limit of 10 lookups. :( – Martijn Heemels Jun 17 '14 at 13:47

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 IN  TXT "v=spf1 -all"

$ dig TXT IN TXT "v=spf1 -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.

share|improve this answer
@ChrisS - I thought about that too, however the SPF specification does state that the "ptr:" mechanism has to be verified both ways for reciprocal DNS - the receiving mailserver should first do a PTR on the IP, and then do an A on the resulting hostname, and the IP must be listed in the A record. So I don't think it's a security hole, at least not for conforming SPF implementations. – John Hart Nov 10 '14 at 21:47
Ah, good find there. I wasn't aware of the caveat. – Chris S Nov 10 '14 at 21:52

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

Secondly, we set up a separate subdomain under our main domain for the Office 365 stuff. This way, emails get the Office 365 SPF, and emails 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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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