SPF: the ten DNS lookup limit

The reason for the limit is defensive: without it, a maliciously constructed SPF record could make any server evaluating it perform hundreds of DNS queries, turning it into an amplifier for a denial-of-service attack.

The consequence for you is blunt: past ten, evaluation does not return “fail”, it returns permerror. And a permerror is not a fail: most receiving servers then treat the message as though no SPF record existed at all.

Recursion is what makes records overflow: an include costs one lookup for itself, plus whatever the included record consumes in turn. A provider that nests three inside it consumes four.

v=spf1 include:_spf.google.com include:sendgrid.net
       include:mailgun.org include:servers.mcsv.net
       include:spf.protection.outlook.com mx a -all

Five services at one lookup each, plus a and mx, which costs one more per listed host: that reaches nine or ten. The record is syntactically perfect and it still holds. The next tool added tips it over, and nobody will see it happen.

The same RFC caps void lookups at two: queries that come back empty, with NXDOMAIN or no answer. Past two, that is also a permerror.

This is how ageing records fail: an include pointing at a provider you parted with, whose SPF domain no longer exists, consumes a void lookup. Three former providers are enough to break an otherwise correct record.

1. Delete what is no longer used. The first pass is nearly always enough: former providers, the tool trialled for six months, the ptr inherited from a configuration template. Free, and risk-free.
2. Remove mx and a if they are pointless. They are in almost every record out of habit. Your receiving server is not necessarily your sending server; if it is not, mx does nothing but consume lookups.
3. Delegate by subdomain. Sending each family of services from a dedicated subdomain, mail.example.com for the newsletter, invoices.example.com for billing, gives each its own budget of ten lookups. It is the clean answer, and it makes the reports easier to read too.
4. As a last resort, replace an include with its ip4 blocks. It works, and it creates a debt: see below.

dig +short TXT example.com | grep spf1

Flattening means replacing an include with the list of IP addresses it resolves to at the moment you look. The lookup count drops, the record becomes valid again, and the problem appears solved.

It is not: it has been moved in time. Those addresses belong to your provider, who changes them whenever they like without telling you, which is precisely why they publish an include rather than a list. The day they add a block, your messages fail SPF with nothing having changed on your side.

SPF checks the Envelope-From, an address your recipient never sees. A perfect record therefore stops nobody displaying your domain in the field a human reads: only DMARC, by requiring the two to align, closes that door.

SPF also does not survive forwarding, since the IP address changes in transit. That is why DKIM is not optional: in a world where messages get forwarded, it is the only one of the two checks that holds.