As a hosting provider, we send email on behalf of our clients, so we help them set up DKIM and SPF email records in their DNS to get email deliverability just right. We've been advising them to use http://mail-tester.com to test that they didn't miss anything, and I like this tool a lot.

One problem we've run into a few times, and I'm not sure about, is the DNS "limit" on the SPF record based on domain name. So if you have this:

v=spf1 a include:aspmx.googlemail.com include:campaignmonitor.com include:authsmtp.com include:mail.zendesk.com include:salesforce.com include:_hostedspf.discourse.org ~all

You'll get

example.com ... campaignmonitor.com: Maximum DNS-interactive term limit (10) exceeded

Like so:

mail-tester results

I have some questions about this.

  1. I count six domain names here, not 10, so why is it hitting "ten" DNS requests here? Answered here

  2. Is this 10 DNS interactive term limit a warning or a real error? e.g. should we care? It is nagging our customers a bit and they email us for support. Answered here

  3. Is this 10 DNS interactive term limit a real problem on today's web? As you can see, this customer has a lot of services sending email for them and they are all legitimate. Perhaps this DNS limit was set in the year 2000 when delegating email services like this were not common?

Yes, we can have our customers change the include to IPs in the SPF record but that puts us in a bind if we ever change IPs, a bunch of customers' stuff will break. Really don't want to do that..

What workarounds are there for this?


4 Answers 4

  1. Mostly already answered, please do note including Google this way is wrong - you want to use _spf.google.com or incur a penalty for the redirect:

     ○ → host -t txt aspmx.googlemail.com
     aspmx.googlemail.com descriptive text "v=spf1 redirect=_spf.google.com"
     ○ → host -t txt _spf.google.com
     _spf.google.com descriptive text "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

That lookup will consume 5/10 all on its own - 4/10 still sucks but 20% less.

  1. It will stop processing and return a permanent error - it's up to the engine using the SPF to decide how it wants to treat a permanent error.

  2. Yes - without the processing limits SPF mechanisms could be used as a DoS amplifier against a third party or second party.

As a workaround, emails can come from a subdomain of the main property - community.largecorporation.com for instance.

  • I believe using a subdomain breaks DKIM though? I know we've had trouble with this in the past. Seems like that is the only solution though. Aug 24, 2015 at 23:39
  • 1
    @JeffAtwood Normally DKIM is is signed by the sending domaim. If you use a subdomain, then sign with the sub-domain. However, it is legimiate to sign for a subdomain, but may not get the processing. DKIM records need to be created relative to the signing domain. It is also common for the originator to sign the document to allow origin verification.
    – BillThor
    Aug 25, 2015 at 3:08
  • 1
    As long as the respective SPF and DKIM records are present for the mail domain rather than the root domain and you're signing with d=subdomain.example.com, it'll be fine. In theory. Better test it!
    – MikeyB
    Aug 25, 2015 at 13:37
  1. Assuming that redundancies (like multiple references to _spf.google.com and the records it refers to) are only counted once, I count 17 lookups from the point where you've already looked up the initial record. (See below.)

  2. It refuses to look up all the records necessary to evaluate your SPF record because it would be "too much work". Presumably this means it will treat your domain as if it had no SPF record (or possibly reject it). The spec says that this results in permerror, which leaves it fairly open for the recipient to decide what to do.

  3. I think abuse has been going up rather than down, generally. This limit appears to be meant to thwart abusive sender domains that may otherwise be able to overwhelm the recipient with enormous chains of SPF, potentially leading to DoS.

I think that while outsourcing email is common, it's not actually that common to outsource email to six different providers. You'll have to optimize the SPF record somehow.
(For one thing, the reference to aspmx.googlemail.com seems wasteful as that immediately just redirects to a different name.)

<lookup of example.com A>                   #1
$ dig aspmx.googlemail.com TXT +short       #2
"v=spf1 redirect=_spf.google.com"
$ dig _spf.google.com TXT +short            #3
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
$ dig _netblocks.google.com TXT +short      #4
"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ~all"
$ dig _netblocks2.google.com TXT +short     #5
"v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"
$ dig _netblocks3.google.com TXT +short     #6
"v=spf1 ~all"
$ dig campaignmonitor.com TXT +short        #7
"v=spf1 mx ptr ip4: ip4: include:cmail1.com include:_spf.google.com include:stspg-customer.com ~all"
$ dig cmail1.com TXT +short                 #8
"mailru-verification: 95d4c6eb0645b43c"
"v=spf1 ip4: ip4: ip4: ip4: ip4: ~all"
$ dig stspg-customer.com TXT +short         #9
"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: -all"
$ dig authsmtp.com TXT +short               #10
"v=spf1 include:spf-a.authsmtp.com include:spf-b.authsmtp.com ~all"
$ dig spf-a.authsmtp.com TXT +short         #11
"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ~all"
$ dig spf-b.authsmtp.com TXT +short         #12
"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ~all"
$ dig mail.zendesk.com TXT +short           #13
"v=spf1 ip4: ip4: ip4: ip4: ~all"
$ dig salesforce.com TXT +short             #14
"v=spf1 include:_spf.google.com include:_spfblock.salesforce.com include:_qa.salesforce.com ip4: ip4: ip4: ip4: ip4: ip4: ip4: mx ~all"
$ dig _spfblock.salesforce.com TXT +short   #15
"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4:  ~all"
$ dig _qa.salesforce.com TXT +short         #16
"v=spf1 ip4: ip4: ip4: ip4: ~all"
$ dig _hostedspf.discourse.org TXT +short   #17
"v=spf1 ip4: ip6:2001:470:1:3c2::/64 -all"

As the accepted answer to one of the linked questions makes clear, many of the underlying tools for UNIX systems do indeed enforce this limit (though not all in precisely the same way) so any SPF implementation which uses them - which is nearly all on UNIX - will enforce those limits also. Windows systems are a law unto themselves, and I cannot shed any light on them.

The workaround is to have a cron job that evaluates your chain of outsourced SPF records, expresses them all as ipv4 and ipv6 netblocks, and makes that into your record. Don't forget the -all.

In your case, you want customers to be able to publish an SPF record which they then don't need to maintain. One possibility would be to have each customer publish a record containing redirect=spf.client1.jeffs-company.example, and you then do the legwork of maintaining the list of netblocks at jeffs-company.example.

Perhaps this DNS limit was set in the year 2000 when delegating email services like this were not common?

The limit does make it hard to outsource your email to six or seven large operations; but arguably if you are doing that you have for all practical purposes lost control of your email anyway.

Somewhere, someday, some sub-sub-contracted programmer of whose existence you were completely unaware and over whom you have no control is going to misplace a semicolon, and a ton of bogus email will get sent with your SPF imprimatur squarely upon it. Full control of your email requires full control of your email infrastructure, and that is in my opinion entirely inconsistent with that much outsourcing.


Another way of working around those problems is looking at which software exactly is used to check SPF-settings. In my case it's cluebringer/PolicyD, which uses Mail::SPF::Server in the end and that accepts arguments relaxing otherwise hard-coded limits. The problem is that cluebringer itself doesn't support relaxing those arguments currently, but that might get changed in future and one might be able to simply tell receiving service providers about those possibilities to relax their settings.

If they decide to do so is of course out of ones control, but it's at least a chance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .