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:
I have some questions about this.
I count six domain names here, not 10, so why is it hitting "ten" DNS requests here?Answered hereIs 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 hereIs 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?
Assuming that redundancies (like multiple references to
_spf.google.comand 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.)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.
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.comseems wasteful as that immediately just redirects to a different name.)Mostly already answered, please do note including Google this way is wrong - you want to use
_spf.google.comor incur a penalty for the redirect:That lookup will consume 5/10 all on its own - 4/10 still sucks but 20% less.
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.
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.comfor instance.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 atjeffs-company.example.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::Serverin 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.