SPF too many DNS lookups: what it means and how to fix it

Where the limit comes from

The SPF specification (RFC 7208) limits evaluation to ten mechanisms and modifiers that cause DNS lookups. The limit exists so that checking one message cannot make a receiver perform an unbounded number of queries.

When an eleventh lookup would be needed, the receiver stops and returns permerror. A permerror is not a soft result: for DMARC purposes SPF has not passed, so the message depends entirely on DKIM.

What counts and what does not

The mechanisms include, a, mx, exists and ptr each count, and so does the redirect modifier. The mechanisms ip4, ip6 and all do not, because they need no query.

The part people miss is that the count is recursive. An include pulls in another domain's SPF record, and every lookup inside that record counts toward your ten. A record with four includes can easily reach twelve once the providers' own records are resolved. There is also a separate limit of two void lookups, which are queries that return no records.

1. Count every include, a, mx, exists, ptr and redirect in your own record.
2. Resolve each include and count the same mechanisms inside it, and inside anything it includes.
3. Add the numbers. If the total is above ten, receivers return permerror.

Four ways to get under the limit

Start with removal. Records collect includes for services nobody uses any more: an old newsletter tool, a previous help desk, a trial that ended. Every include you remove usually saves more than one lookup.

If a provider publishes a narrower include for your region or product, use it instead of the general one. If a service always sends from a small set of fixed addresses, replace its include with ip4 or ip6 entries, which cost no lookups. This is called flattening, and it has a real cost: when the provider changes its addresses your record is silently wrong, so flatten only what you can monitor.

1. Remove includes for services that no longer send mail for the domain.
2. Replace a and mx with explicit ip4 or ip6 entries if those servers have fixed addresses.
3. Move a high-volume sender to its own subdomain with its own SPF record, so it no longer shares the parent domain's budget.
4. Flatten a stable include into IP ranges only if you will be alerted when the provider changes them.

Why subdomains help

SPF is evaluated against the domain in the envelope sender, and each domain or subdomain has its own record and its own ten-lookup budget. If marketing mail is sent from news.example.com and invoices from billing.example.com, each can list only the provider it needs.

This also limits damage: a mistake in the marketing record cannot break invoices.

Check the published record, not the one you intended

Counting by hand goes wrong because provider records change. Use a checker that resolves the full include chain and reports the real total, then re-check after any change. CloudSpex resolves the chain and reports the lookup count against the limit, and says plainly when a part of the chain could not be resolved.