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

Setting up DNS for sending email

Email – and email filtering – makes a lot of use of DNS, and it’s fairly easy to miss something. Here are a few checklists to help:

Read More

A brief history of TXT Records

txt
When the Domain Name System was designed thirty years ago the concept behind it was pretty simple. It’s mostly just a distributed database that lets you map hostname / query-type pairs to values.
If you want to know the IP address of cnn.com, you look up {cnn.com, A} and get back a couple of IP addresses. If you want to know where to send mail for aol.com users, you look up {aol.com, MX} and you get a set of four hostname / preference pairs back. If you want to know the hostname for the IP address 206.190.36.45 you look up {45.36.190.206.in-addr.arpa, PTR} and get a hostname back.
There’s a well-defined meaning to each of those query types  – A is for IP addresses, MX is for mailservers, PTR is for hostnames – and that was always the intent for how DNS should work.
When DNS was first standardized, though, there was one query type that didn’t really have any semantic meaning:

Read More

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