Optimize your SPF records

I talked on Monday about the SPF rule of ten and how it made it difficult for companies to use multiple services that send email on their behalf.
Today I’m going to look at how to fix things, by shrinking bloated SPF records. This is mostly aimed at those services who send email on their customers behalf and ask their customers to include an SPF record as that’s the biggest pain point, but some of it is also useful to people publishing their own SPF records.

Get rid of costly SPF directives
First, rethink using the “mx” directive. It’s often used in example SPF records, because it makes them look simpler. But an MX directive always triggers a DNS lookup that counts against your limit of ten, and it’ll also trigger a DNS lookup for each hostname in your MX record – they don’t count against the SPF limit but may increase the latency of your delivery a little. Better than using “mx” is to use explicit “ip4” and “ip6” records to list the addresses your smarthost and MX send mail from. Even though this makes your SPF record look longer it’ll actually make it smaller, as measured by DNS queries, as a single “mx” directive costs more than 20 “ip4” directives.
Similarly, avoid the “a” directive. It’s much less commonly seen but again can usually be replaced with “ip4” or “ip6” directives.
Don’t use “ptr” directives. They’re deprecated by the current SPF RFC.
Check the address ranges
If you have many “ip4” and “ip6” directives, make sure they’re not redundant. Are there any address ranges that you’re not using any more? Are there any adjacent address ranges that can be merged? For example, “ip4:x.y.z.4/24” and “ip4:x.y.z.5/24” can be replaced with “ip4:x.y.z.4/23” (note that you can’t always replace adjacent address blocks of the same size – read up on CIDR notation).
If you’ve generated your CIDR blocks from address ranges you can sometimes have very inefficient representations. The address range 10.11.12.1-10.11.12.254 needs 14 “ip4” directives to represent precisely. Instead you can use the single directive “ip4:10.11.12.0/24”, even if you’re not sending any email from the .0 or .255 addresses.
You don’t need a “~all” or “-all” at the end of a TXT record that is only included in another SPF record, not used directly. It won’t do any harm but it wastes a few characters.
Once you’ve got your list of SPF directives cleaned up the next thing to do is to pack them into one or more DNS TXT records.
Use as few TXT records as you can
Some SPF tutorials say that you can’t put more than 255 characters of SPF data into each TXT record. That’s not quite true, though.
A TXT record contains one or more strings of text and each string can contain no more than 255 characters. But an SPF checker will take all of the strings in a TXT record and concatenate them together in order before it starts looking at the content. So you can have more than 255 characters of SPF data in a TXT record by splitting it into more than one string. (Some low-end DNS management web front ends don’t really understand TXT records and won’t let you include multiple strings – you should check that your DNS management system does before relying on this).
How much more than 255? That’s where you have to get a little familiar with the DNS protocol, as the real limitation is that you don’t want your DNS packets to be more than 512 bytes long. (Why 512 bytes? That’s a long story of protocol changes and incompatibility, but 512 bytes are about as big as you can reliably use over UDP. Just trust me.)
The DNS overhead for a reply that contains a single TXT record with two strings is about 34 bytes, plus the length of the hostname that’s being queries (e.g. “spf.example.com” is 15 bytes). So to keep within the 512 byte limit you need to break your SPF into chunks of no more than 478 minus the length of the hostname. Then you need to break that SPF data into two strings (remembering that they’ll be concatenated with no white space added, so if you break it at a space you need to include the space at the end of the first string or the beginning of the second).
That’ll give you a TXT record that looks something like this:

spf.example.com 3600 IN TXT “v=spf1 ip4:10.11.12.13 … more spf” ” yet more spf ~all”

TXT records other than SPF
Note that the size of the DNS reply is driven by all the matching TXT records. For an SPF record designed to be included – such as spf.example.com – that’s not a problem, but for the actual SPF record for a domain you need to be aware of other TXT record pollution at the domain root. “spf2.0/pra”, “v=msv1”, google validation records, all that junk makes your DNS response bigger. You can use the dig commandline tool – dig example.com txt – to see what records you have and how big your DNS reply is. This also means that when you’re providing an SPF record for your users to include it’s important that you provide it explicitly – for example “include:spf.example.com” – rather than telling them to include your whole SPF record as “include:example.com”. This avoids a lot of other potential problems with unexpected nested includes.
How much it can help
Making these changes to slim down the SPF records you ask customers to include is important to the health of SPF. If a customer cannot add your SPF record because they don’t have enough available DNS queries to do so then either they’re not going to use you as a vendor, or they won’t be able to use SPF to authenticate mail you send and delivery is likely to suffer (unless you also support delegated DKIM signing – if you do that’s great, but it’s much more work than cleaning up your SPF).
The two vendors I currently have in my SPF record each consume three DNS lookups. I could add one more similar vendor before it broke my SPF record. If the vendors I use shrank their included SPF records down from costing three lookups to one lookup then I could use ten vendors before I needed to worry about SPF size.
(Think your customers won’t be aware of how costly their SPF records are? Just this morning we got a call from someone whose ESP is using our SPF checking tool to check the health of new customers SPF as part of their onboarding process.)
A tool to do the hard work for you
Optimizing your SPF to this degree is important, but it’s hard. We’ve created a prototype tool to help with optimizing your included SPF records at tools.wordtothewise.com/spf/minimize. Enter your SPF include record, hit the Minimize button and read the “Read Me First” tab to see how to use it.
Checking some email vendors I use or like there’s definitely room for improvement.
Zoho shrank from 3 queries to 1
MailChimp shrank from 3 queries to 1
SalesForce shrank from 3 queries to 1
Google Apps shrank from 4 queries to 1
Outlook shrank from 3 queries to 2
(If you grok SPF or DNS and you see any issues with what I’m suggesting, please leave a comment here or send me email)