SPF has a hard limit: at most ten DNS lookups that cause further lookups — the include, a, mx, ptr, exists and redirect mechanisms. Go over it and the result is permerror, which most receivers treat as a fail. Nothing warns you. The record still resolves, the mail still sends, and authentication quietly stops working.
Why records creep past the limit
Every tool you add wants its own include. The email provider, the CRM, the support desk, the transactional API, the marketing platform. Each one contributes an include: that itself may contain includes. The count is recursive, and nobody adds up the subtree.
How to count it properly
Resolve the record and walk it. For each include, fetch its TXT record and count the mechanisms inside, then recurse. The official checker does this and reports the number, but you should also fail your own CI if the count goes above nine — leaving one lookup of headroom for the next tool somebody adds on a Friday.
The fix that keeps working
Move anything non-essential to a subdomain. Marketing mail from news.example.com with its own SPF record costs nothing against the root domain's budget, and it isolates reputation as a bonus. For senders that support it, delegation through the provider's own subdomain removes the include entirely.
The detail worth remembering
A record that ends in -all is a promise. If the lookup limit is exceeded, that promise fails closed for legitimate mail and the receiver may reject it outright. Checking the count is not housekeeping, it is availability.
Volanea publishes per-domain authentication state and reports the SPF lookup depth for each sending domain, so the count is visible before it breaks.
