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.
email_vice
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)

Related Posts

Check your tech

One of the things we do for just about every new client coming into WttW is have them send us an email from their bulk mail system. We then check it for technical correctness. This includes things like reviewing all the different From headers, rDNS of the connecting IP, List-Unsubscribe headers and authentication. This is always useful, IMO, because we often find things that were right when they were set up, but due to other changes at the customer they’re not 100% correct any more.
This happens to most of us. Even a company as small as Word to the Wise misses a rDNS update here or a hostname change update there when making infrastructure changes. That’s even when the same people know about email and are responsible for the infrastructure.
One of the most common problems we see is a SPF record that has accumulated include: files from previous providers. There are a couple reasons for this. One is the fact that SPF is set up while still at the old provider in anticipation of moving to the new provider. Once the move is made no one goes back to clean up the SPF record and remove the old entries. The other reason is that a lot of tech folks don’t like to delete things. Deleting things can lead to problems, and there’s no harm in a little extra in the SPF record. Except, eventually, there are so many include files that the lookup fails.
Every mailer should schedule a regular tech audit for their mail. Things change and sometimes in the midst of chance we don’t always catch some of the little details.

Read More

What is the Mail From field?

When emails are sent, there are two from fields, the Mail From and the Display From address.  The Display From address (technically referred to as RFC.5322 from address) is the from address that is displayed to the end user within their email client.  The Mail From (technically referred to as RFC.5321 from address) is the email address to which bounce messages are delivered.  The Mail From field is sometimes referred to as the Return Path address, Envelope From address, or Bounce address.
It may seem confusing to have an email with two from fields, but knowing the difference is important to properly setup your SPF records.
Taking a look at this email I received from GoPro, the Return-Path (5321.From) goes back to @bounce.email.gopro.com.  If I were to reply to the email, the message would go to @email.gopro.com. The Display From (5322.From) address is gopro@email.gopro.com.
GoPro-Headers
I would want to add the email address GoPro@email.gopro.com to my address book because that is the email address that is displayed in my email client. The reason why the Return-Path is different from the From address is because GoPro likely has an automated system that will process the bounce back messages (sent to @bounce.email.gopro.com) and automatically flag or unsubscribe those email addresses. This allows GoPro to setup automatic processing of the different mail streams sent to them, one stream being the bounce backs after a mailing and the second being an automated customer service system.
Where does SPF fit in?
SPF checks the Mail From (5321.From) address, not the Display From (5322.From) address.  In the example above, there should be an SPF record for the subdomain of bounce.email.gopro.com.  I can check the SPF record using our Authentication tools http://tools.wordtothewise.com/spf/check/bounce.email.gopro.com and I receive the following results:
SPF_GoPro
Checking the headers shows that GoPro does have a SPF record setup and the message was authenticated with SPF.
Authentication Results
For SPF records, make sure the SPF record matches the Mail From (From.5321)/Return-Path domain name.  Have your recipients add the Display From (From.5322) email address to their address book so they will continue to receive your mailings.

Read More

TXTing

txt
On Friday I talked a bit about the history behind TXT records, their uses and abuses.
But what’s in a TXT record? How is it used? When and where should you use them?
Here’s what you get if you query for the TXT records for exacttarget.com from a unix or OS X command line with dig exacttarget.com txt

Read More