3

We are migrating from a self hosted mailing platform to Office365 for Businesses. Everything went fine, except for the SPF record. At the moment, we have v=spf1 a mx include:spf.mtasv.net -all as TXT record, but Office365 has to allow v=spf1 include:spf.protection.outlook.com -all too. So, I went ahead and and merged them into: v=spf1 a mx include:spf.mtasv.net include:spf.protection.outlook.com -all. When checking this SPF record against the domain of studentkickoff.be, this results into a PermError SPF Permanent Error: Too many DNS lookups.

My question is the following: How do I work around this error? I know I can replace some records with their ip4 equivalent, but when doing this, the online troubleshooter of Office365 kept complaining that the record was not found: enter image description here

Thanks in advance!

Tom Naessens
  • 133
  • 1
  • 7
  • Do other SPF-checking-tools complain? Does Office 365 work with these records? (or are you not even able to set it up?) - As I understand, those records are only temporary, until your migration is done. So I would leave them as is (if it works), and just correct them once you're finished migrating – MichelZ Apr 19 '14 at 08:59
  • Office365 and pySPF complain. As we use our Office365 for the whole business, it is a priority that Office365 accepts the record. We use an external DNS (not the one from Office365) so we are able to set it up, it just doesn't get accepted. This is not a temporary record; we have already migrated (so everything is up and running) but that record requires Office365 exchange to work correctly. – Tom Naessens Apr 19 '14 at 09:04
  • So why do you need the spf.mtasv.net record at all? That's not required for O365? Or do you send out e-mails using another server than O365? – MichelZ Apr 19 '14 at 09:06
  • We indeed use Postmark to send emails from webapps. Postmark requires the mtasv record. – Tom Naessens Apr 19 '14 at 09:07
  • Have a look at this answer: http://stackoverflow.com/questions/14261214/too-many-dns-lookups-in-an-spf-record/14262788#14262788 – MichelZ Apr 19 '14 at 09:14
  • possible duplicate of [Is the 10-DNS-lookup limit in the SPF spec typically enforced?](http://serverfault.com/questions/584708/is-the-10-dns-lookup-limit-in-the-spf-spec-typically-enforced) – MadHatter Apr 19 '14 at 10:09
  • @MadHatter I don't see how this is a duplicate. I do not ask wether the limit is enforced or not, I want my SPF record to match the specification. – Tom Naessens Apr 19 '14 at 10:19
  • 1
    I hear you, but the answers to the former are all the answers you need to this one (except inasmuch as they don't specify what your SPF record should be, and [we don't do that here](http://serverfault.com/questions/369460/what-are-spf-records-and-how-do-i-configure-them)). I nearly quoted my previous answer back at you, which I'm told is a strong suggestion that the question is really a duplicate (I'd quote the reference post, but I cannot currently find it). Don't worry too much, it's only my opinion, and others may not agree with me - if they don't, it won't get closed. – MadHatter Apr 19 '14 at 10:36
  • 2
    That said, I will add that the short form answer to the question of how to make your record match the spec is **you can't** - or, slightly more wordily, there is no simple way to combine multiple DNS-expensive SPF records into a single SPF record without violating the DNS-lookup restrictions of the spec. The complex ways are covered in the answers to the question that I suggest is a duplicate. – MadHatter Apr 19 '14 at 10:40
  • Also, have you tried removing `A`and `MX`? This should cause less lookups as well. [SPF Record Checker](http://www.kitterman.com/spf/validate.html) passes by removing `A` and `MX` from the SPF record. – MichelZ Apr 19 '14 at 12:38

4 Answers4

6

Answer taken from SO here Author: Swift. Adapted to fit the question. Also, have a read here on general SPF stuff.

We started with:

v=spf1 a mx include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

We get 10 total lookups before we throw the Too many DNS lookups error:

  2 (Initial TXT & SPF Lookups)
  2 (a & mx Lookups)
  1 (_spf.google.com)
  1 (servers.mcsv.net)
 +1 (sendgrid.net)
 -----------------
  7 Lookups

So without even following the included SPF records, we have 7 lookups.

Now, let's dive a level deeper.

1. _spf.google.com

The google SPF record evaluates to:

v=spf1 include:_netblocks.google.com include:_netblocks6.google.com ?all

Each of which resolve to the following values:

# _netblocks.google.com
v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ip4:64.18.0.0/20 ip4:207.126.144.0/20 ip4:173.194.0.0/16 ?all

# _netblocks6.google.com
v=spf1 ip6:2607:f8b0:4000::/36 ip6:2a00:1450:4000::/36 ?all

So google gives us 2 more lookups, bringing the total up to 9 Lookups.

2. servers.mcsv.net

Mailchimp is a bit of a doosey because it adds a whole 3 extra lookups:

v=spf1 include:spf1.mcsv.net include:spf2.mcsv.net include:spf.mandrillapp.com ?all

I would imagine that depending on what you're sending through Mailchimp, you might be able to remove one or two of these records (but you'll have to evaluated that yourself).

Anyway, those resolve to the following:

# spf1.mcsv.net
v=spf1 ip4:207.97.237.194/31 ip4:207.97.238.88/29 ip4:207.97.240.168/29 ip4:69.20.10.80/29 ip4:69.20.41.72/27 ip4:74.205.22.1/27 ip4:69.20.90.0/26 ?all

# spf2.mcsv.net
v=spf1 ip4:204.232.163.0/24 ip4:72.26.195.64/27 ip4:74.63.47.96/27 ip4:173.231.138.192/27 ip4:173.231.139.0/24 ip4:173.231.176.0/20 ip4:205.201.128.0/24 ?all

# spf.mandrillapp.com
v=spf1 ip4:205.201.136.0/24 ip4:205.201.137.0/24 ?all

This brings us up to a total of 12 Lookups (Which is two over the limit already).

2. sendgrid.net

SendGrid ends up being the fewest number of additional lookups for us.

v=spf1 ip4:208.115.214.0/24 ip4:74.63.202.0/24 ip4:75.126.200.128/27 ip4:75.126.253.0/24 ip4:67.228.50.32/27 ip4:174.36.80.208/28 ip4:174.36.92.96/27 ip4:69.162.98.0/24 ip4:74.63.194.0/24 ip4:74.63.234.0/24 ip4:74.63.235.0/24 include:sendgrid.biz ~all

So the only additional lookup here is sendgrid.biz, which evaluates to:

v=spf1 ip4:208.115.235.0/24 ip4:74.63.231.0/24 ip4:74.63.247.0/24 ip4:74.63.236.0/24 ip4:208.115.239.0/24 ip4:173.193.132.0/24 ip4:173.193.133.0/24 ip4:208.117.48.0/20 ip4:50.31.32.0/19 ip4:198.37.144.0/20 ~all

This brings our grand total up to 14 lookups.

So our grand total is 14 Lookups. We need to get that down to 10. I've outlined a couple of options below, you may need to use more than 1 of them to get it down.

  1. Directly include some of the redirected spf records. Now that we know which servers the spf records redirect to, you could cut out the middleman and include them directly. Note: If any of the services end up changing their SPF records, you'll have to go through the process of updating yours manually.

  2. Remove some of the services that you're using. Not sure what your use case is for having all of these services, but there's definitely some overlap that you might be able to use. For instance, SendGrid supports (1) transactional outgoing mail, (2) newsletter / marketing emails, and (3) incoming mail. So there may be some reducible redundancy.

  3. Remove the MX record if it is redundant. Depending on your setup, the MX lookup can be redundant.

Community
  • 1
MichelZ
  • 11,008
  • 4
  • 30
  • 58
  • Thank you for your answer. I did already see that answer in the post you linked to, but that offered no solution. If you check the SPF from Office365, this results in a cluster of a LOT of IPs: `dig spf-b.outlook.com TXT` returns 11 IPs while `dig spf-a.outlook.com TXT` results in a continuous redirection from one lookup to another... – Tom Naessens Apr 19 '14 at 09:28
  • 2
    The `mx` directive can easily lead to more than one additional lookup. If there are N `MX` records where the `A`/`AAAA` records are not included in the initial response (eg, out of zone, which is rather common) there will be N additional lookups. I would question the validity of `a` and `mx`, are those really sending mail? Having GApps included in SPF suggests that your `MX` records may point there? In that case the `mx` bit is just wrong and costs 7 additional lookups if you have their full set of inbound servers specified. – Håkan Lindqvist Apr 19 '14 at 12:12
  • (Ie, the grand total may not be 14 but 21 if that is the case.) – Håkan Lindqvist Apr 19 '14 at 12:20
  • The values in this post are just "examples" from another post. It just demonstrates "how" to do the counting, it is not a direct answer to the question with a step-by-step guide – MichelZ Apr 19 '14 at 12:25
  • Alright, I didn't pay enough attention, thought it had been adapted to the OPs record. Either way, the general idea regarding `mx` applies regardless. – Håkan Lindqvist Apr 19 '14 at 12:32
  • Yeah, I removed some irrelevant chit-chat, but have not replaced the actual records. :) Yes, removing `A` and `MX` could potentially help. – MichelZ Apr 19 '14 at 12:37
4

Apart from everything that has already been said, let's focus on this: 

My question is the following: How do I work around this error? I know I can replace some  
records with their ip4 equivalent, but when doing this, the online troubleshooter of  
Office365 kept complaining that the record was not found:

I recently ran into the same problem.
While it is documented that it should work (http://community.office365.com/en-us/w/exchange/customize-an-spf-record-to-validate-outbound-email-sent-from-your-domain.aspx) we could never get it to verify with a different record.
It didn't matter if it was a:some.host.com or ip4:127.0.0.1, it always complained about the SPF record being wrong/missing.
In the end we changed the record to v=spf1 include:spf.protection.outlook.com -all to make the verification wizard happy and adjusted it back afterwards to the real record.

faker
  • 17,326
  • 2
  • 60
  • 69
  • I've seen some SPF checkers required their domain to be listed first and then it will pass with both domains included. – citadelgrad Sep 08 '14 at 20:37
1

You can just use an SPF Proxy service like spfproxy.org. Then you don't need to flatten DNS entries into IP addresses or even screw around with subdomains. You just setup SPF Proxy and it will do all the lookups on the backend. It's the only way I've found to solve this problem elegantly.

AngularNerd
  • 111
  • 1
0

I can see this this is a great reason to create subdomains specifically for sending out through 3rd-parties:

If you have different 3rd party senders handling different things that can be signed up for, then setting up a separate subdomain can be a great way to manage it:

The subdomain names could be based on what is being sent:

  • NewsLetterName.Example.com for newsletter sent out through a third party could have spf record specific to that 3rd party.
  • Updates.Example.com for when "updates" have been signed up for.
  • Support.Example.com for when "Support" is provided through 3rd party.

Or the subdomain names could be based upon the 3rd party sender it is for:

  • ccMail.Example.com for Constant Contact emails
  • mcMail.Example.com for Mail Chimp emails
  • zendeskMail.Example.com for ZendDesk emails

I actually like this idea now that I've mapped it out! I will try this out myself. It will mean setting up additional email addresses for those subdomains, but that will allow easier organization of emails.

CutNGlass
  • 1
  • 1