SPF and the ten-lookup limit

A receiver checking SPF may make at most ten DNS lookups to evaluate your record (RFC 7208). Past ten, it stops and returns permerror, and most receivers then treat the domain as if it published no SPF record at all.

Nothing visibly breaks on the day you cross the line. Mail that DKIM signs still passes DMARC. Mail that relies on SPF to align starts failing, and the record still looks correct to anyone reading it.

What counts

In your record	Lookups
include:	1, plus everything inside the included record
a, mx	1 each
ptr, exists:	1 each
redirect=	1, plus everything in the target record
ip4:, ip6:, all	0

The nesting is what catches people. This record looks like it costs three:

v=spf1 include:_spf.example.net include:mail.example.org mx -all

But if _spf.example.net itself includes three more records and mail.example.org includes two, the real cost is eight. Add one more service whose record includes two others and you are at eleven, without having written anything that looks long.

What DMARCLoop shows

The SPF card on a domain’s DNS records tab says how many lookups a receiver makes to evaluate the record, for example A receiver makes 4 DNS lookups to evaluate it (the limit is 10). The free SPF Check expands any domain’s include tree the same way.

A self-managed SPF record that would need more than ten lookups isn’t saved: saving it says This needs 12 DNS lookups; receivers stop at 10.

Three alerts cover SPF; see Notifications and alerts:

Alert	Sent when
SPF lookup limit exceeded	The SPF record needs more than ten DNS lookups, so receivers treat it as failing.
SPF record invalid	The SPF record doesn’t parse, or the domain publishes more than one.
Hosted SPF not updating	The flattened SPF record we serve couldn’t be rebuilt three times in a row.

Getting back under ten

In rough order of how much they help:

1. Remove includes for services you no longer use. The record outlives the contract more often than not.
2. Move a service from SPF to DKIM. A service that signs with your domain aligns through DKIM, so it may not need to be in your SPF record at all. The DKIM aligned column in Sources shows which do.
3. Replace ptr with the ip4:/ip6: ranges it stood in for.
4. Flatten the record: replace includes with the addresses they resolve to. Done once by hand, this goes stale the next time a provider changes its addresses, which is what hosted SPF is for.

Hosted SPF and flattening

With hosted SPF, the record on your domain is a single include of ours:

v=spf1 include:….spf.h.dmarcloop.net -all

Behind it, you list your senders on the SPF card, one SPF term per line (include:_spf.google.com, ip4:192.0.2.0/24, mx), and choose how mail from anyone else is treated under Mail from anyone else: ~all: soft fail (while setting up) or -all: fail.

Tick Flatten (resolve includes to addresses so the record stays under SPF’s 10-lookup limit, and re-resolve them every six hours) and the record we serve lists addresses instead of includes. The include on your domain then costs one lookup, however many senders sit behind it, and a provider’s new addresses are picked up within six hours. Flattening is a plan feature; where your plan doesn’t include it, the box says so.

Preview shows what would be published before you save. If the senders can’t be resolved exactly, the preview lists why and saving is refused, rather than publishing a record that quietly authorises fewer senders than yours does. If a later re-resolve fails, the record already being served stays as it is; three failures in a row send the Hosted SPF not updating alert.

Next

Lock down a parked domain.