The SPF 10-lookup limit: the record that breaks by growing

SPF records fail in an unusual way: not when you edit them, but when they grow. Every tool your company adopts asks for one more include: in the record — the CRM, the newsletter platform, the helpdesk, the invoicing service — and each looks harmless. The record is syntactically fine at any length. What breaks is a budget almost nobody knows exists.

The budget

When a receiver evaluates your SPF, it may perform at most ten DNS lookups — the standard says so, to keep SPF from being a denial-of-service tool. Every include: costs one lookup, and so does everything inside the included record, recursively: an include that itself includes three others just cost you four. The mechanisms a, mx, ptr, exists and redirect each cost one more. Plain ip4: and ip6: entries cost nothing. Cross the limit and evaluation stops with a permanent error — and at most receivers, a permanent error means your SPF simply does not count, silently, for every message.

The treacherous part is who spends your budget: the vendors inside your includes. Their records change without telling you. A record that evaluated at nine lookups for a year goes to eleven because one provider restructured theirs — nothing in your DNS changed, and your mail's authentication just degraded.

Walking a record back under the limit

First, remove what is dead: tools you stopped using, an a or mx mechanism that duplicates what an include already authorizes, includes for services that actually send from their own domain (a service that DKIM-signs as itself and uses its own envelope does not need to be in your SPF at all). Second, prefer the cheap forms: if a sender has stable published addresses, ip4: ranges cost zero lookups. Third, treat "flattening" services — which replace includes with their expanded addresses — as a last resort with a maintenance contract attached: the addresses behind an include change, and a flattened record goes stale unless something re-expands it continuously.

Knowing before it breaks

Because the budget is spent by other people's records, this is a monitoring problem, not a set-up problem. Sojka checks your record on a 15-minute cycle, expands the whole SPF tree — every include, recursively, both address families — and flags a record that breaks, the moment it breaks, instead of leaving it to a customer to notice. When a verified sender of yours is missing from the record, it drafts the exact amendment rather than a generic warning.

Check your domain free — it reads your public DNS and grades what is there.