SPF: too many DNS lookups

SPF allows ten DNS lookups per evaluation. The limit is in RFC 7208 section 4.6.4, and it is not advisory: a receiver that goes past ten must return a permanent error.

The part that catches people is that the lookups inside your includes count against the same ten. A record with four entries in it can be over the limit because one vendor’s record contains six of its own.

How to see your real count

Guessing from the length of your record does not work. The SPF checker walks the entire chain, expands every include, and shows what each one costs.

You are looking for two numbers: the total, and which branch is spending it.

What counts and what does not

Each of include, a, mx, ptr, exists and redirect costs one lookup, every time it is evaluated, at any depth.

ip4, ip6 and all cost nothing. They are answered from the record you already fetched.

That asymmetry is the whole basis of every fix below.

The four ways back under

Remove what you do not use. This alone solves most cases. Nearly every over-limit record contains an include for a tool nobody has sent from in years. Removing it costs nothing and risks nothing.

Flatten the stable vendors. Replace an include with the ip4 and ip6 ranges behind it and you buy back a whole lookup, because addresses are free. The trade is maintenance: when the vendor changes their ranges they will not tell you, and your record will silently stop authorising their mail. Flatten the ones that rarely move, leave the volatile ones alone. The flattener does the expansion and refuses to hand you a record it could not resolve completely.

Split onto subdomains. A subdomain gets its own SPF record and its own budget of ten. Sending marketing from news.yourcompany.com takes its includes out of competition with your transactional mail entirely. This is the cleanest fix and the one large senders use.

Lean on DKIM instead. DMARC passes on SPF or DKIM. If your vendors sign with a key published in your DNS, their mail aligns without appearing in your SPF record at all. This is the only fix that removes the pressure permanently.

Two things not to do

Do not raise the limit. You cannot; it is enforced by the receiver, not by you.

Do not end the record with +all to make the error go away. That authorises every server on the internet to send as you, which is worse than the problem you started with.

Check it

Run the SPF checker for the exact count and the chain that produced it. If you are over, the flattener will show you what the record looks like once the expandable parts are expanded.