SPF: The rule of ten

Some mechanisms and modifiers (collectively, “terms”) cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the “include”, “a”, “mx”, “ptr”, and “exists” mechanisms, and the “redirect” modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return “permerror”.

RFC 7208 section 4.6.4

This is the SPF rule of ten. It means that any SPF record that causes more than ten DNS queries (other than the original TXT query and any A record lookups triggered by “mx” terms) is not valid, and any attempt to authenticate SPF for email from the domain will lead to an error.
Ten queries seems like a lot. You probably only have an “mx” and a few “include” terms. That’s nowhere near ten.
But … the limit is the number of DNS-performing terms both in your SPF record and all the SPF records you include. That can add up quickly.
We – wordtothewise.com – have an SPF record that’s about as well optimized as it can be, given the services we use. We don’t use an “mx” term or any “a” terms, instead we include “ip4” and “ip6” terms for our mailservers. We use two external mail services – MailChimp and Zoho.
How many DNS-performing terms does that add up to? Six. Look at tools.wordtothewise.com/spf/check/wordtothewise.com and click on the “DNS” tab to see how it adds up that quickly.
We include “zoho.com” (1) which then includes “spf2.zoho.com” (2) and “spf.zoho.com” (3). We include “servers.mcsv.net” (4) which then includes “spf1.mcsv.net” (5) and “spf.mandrillapp.com” (6).
You can check your SPF records using our tool at tools.wordtothewise.com/spf. Want to see what a “too many DNS queries” error looks like? Check the SPF for “ebay.com“.
More later in the week about what you can do to reduce your SPF record size – particularly important if you’re providing records for your customers to include.

Related Posts

Four things to check before your next mailing

Like many bits of technology, email is often set-and-forget. Everything is checked and rechecked during setup, and then no one goes back and looks at it again. But mail programs are not static, and people make changes. These changes don’t really break things, but over time they can create their own set of problems.
Setting aside some time every quarter or even every year to check and make sure all the bits of mail are configured correctly is a good idea.

Read More

SPF debugging

Someone mentioned on a mailing list that mail “from” intuit.com was being filed in the gmail spam folder, with the warning “Our systems couldn’t verify that this message was really sent by intuit.com“. That warning means that Gmail thinks it may be phishing mail. Given they’re a well-known financial services organization, I’m sure there is a lot of phishing mail claiming to be from them.
But I’d expect that a company the size of Intuit would be authenticating their mail, and that Gmail should be able to use that authentication to know that the mail wasn’t a phish.
Clearly something is broken somewhere. Lets take a look.
Looking at the headers, the mail was being sent from Salesforce, and (despite Salesforce offering DKIM) it wasn’t DKIM signed by anyone. So … look at SPF.
SPF passes:

Read More