SPF record: too many DNS lookups, and how to fix it

What the 10-lookup limit is

SPF is defined in RFC 7208. It says that evaluating an SPF record must not require more than 10 DNS-querying terms. If it does, the receiver should return permerror, which counts as an SPF failure for DMARC purposes. Receivers do not do you any favors by guessing which servers you meant.

The limit is about how many DNS queries evaluating the record triggers, including the ones triggered by records you reference. It is not about how long the record is.

Which mechanisms count

• include: counts as one lookup, plus every lookup inside the included record.
• a and mx count as one lookup each (and mx can also trigger further address lookups for the hosts it returns, which have their own limit).
• ptr and exists count, and ptr is discouraged by the spec.
• redirect= counts as one lookup.
• ip4, ip6 and all do not require any lookup and are free.

A separate rule limits void lookups, which are lookups that return no answer or no such domain, to two. A record that includes a dead or misspelled domain can fail for that reason even if it is under 10 total.

Why cold email setups hit it

A typical setup might include Google Workspace or Microsoft 365 for the mailboxes, one include for the sequencing tool, another for a CRM or marketing platform, and one for a helpdesk. Each include can itself contain nested includes. Large providers often use several nested lookups, so two or three includes can use most of your budget.

How to count your lookups

Run your domain through our free checker. It flags records that exceed the limit and tells you how many lookups it found. You can also count by hand: start with your record, count every include, a, mx, ptr, exists and redirect, then open each included domain's TXT record and count the same terms inside it, repeating for nested includes.

How to get back under the limit

1. Remove services that no longer send mail for this domain. Old tools are the most common cause.
2. Use a dedicated sending domain or subdomain for cold email, so it only needs the includes for that traffic. See using a secondary domain.
3. Move different mail streams to different subdomains. Each subdomain gets its own SPF record and its own lookup budget.
4. Replace a and mx mechanisms with ip4 or ip6 ranges if you control static IPs and are sure they will not change.
5. As a last resort, use SPF flattening, which replaces includes with the IP addresses they resolve to.

Be careful with flattening. Providers change their IP ranges over time, and a flattened record that is not kept up to date will silently go stale and start failing legitimate mail. If you flatten, use a service or a process that refreshes it automatically, and monitor the result.

Common mistakes while fixing it

• Publishing two SPF records. A domain must have exactly one v=spf1 TXT record. Merge them into one.
• Putting -all too early. Use ~all while you confirm every legitimate sender is listed, then tighten once you are sure.
• Forgetting that your sending tool may rely on DKIM instead of SPF. DMARC only needs one of SPF or DKIM to pass with alignment, so a correct DKIM setup is a good safety net. See the DMARC guide.

Check again after changes

DNS changes take time to be visible, depending on the TTL of the old record. After publishing a new record, check it again with the free checker, and then send a test message to a Gmail address and look at the Authentication-Results header to confirm spf=pass.