SPF Too Many DNS Lookups: Understand the 10-Lookup Limit
An SPF record can look short and still use too many DNS-querying terms. The limit applies to the evaluation path, including included records and redirects, rather than simply counting the words in the record you publish.
Illustrative SPF evaluation path. The number of DNS-querying terms depends on the evaluated mechanisms, not the number of published TXT records (RFC 7208 §4.6.4).
In brief
An SPF record can look short and still use too many DNS-querying terms. The limit applies to the evaluation path, including included records and redirects, rather than simply counting the words in the record you publish.
The worked examples on this page are explanatory, not results from your domain or a mailbox-provider test.
What the SPF ten-lookup rule actually counts
Under RFC 7208 section 4.6.4, an SPF evaluation cannot use more than ten terms that cause DNS queries. The relevant terms are include, a, mx, ptr, exists, and redirect. This includes the lookup-causing terms reached through nested include or redirect processing.
An ip4 or ip6 mechanism does not consume that DNS-querying-term budget. Neither do all or the exp modifier. The limit is about evaluated lookup-causing mechanisms, not a blanket limit on the total number of words in a TXT record.
The SPF specification says an implementation must return permerror when the ten-term limit is exceeded. A static top-level token count is a useful warning but cannot replace evaluation of the actual sender identity, IP address and DNS path.
permerror. RFC 7208 §4.6.4.An illustrative nested include
Suppose an invented domain publishes v=spf1 include:_spf.vendor.example -all. The visible record has one include, but the included policy may refer to still more records. The combined evaluated path matters. This is a teaching example using reserved example-domain names, not a working vendor policy.
A second independent issue is multiple SPF policies at the same owner name. A receiver selecting more than one SPF record can return a permanent error under RFC 7208 record selection rules. Do not solve a lookup-limit warning by publishing an additional SPF record.
A safe investigation sequence
Start by inventorying each legitimate system that sends using the relevant SMTP identity: staff mail, billing, website forms, marketing platforms and transactional services. For each, obtain the current documented SPF setup from that provider.
Inspect the record through a public DNS lookup, then examine the relevant include and redirect paths. Some mechanisms are conditional, and DNS responses can fail temporarily, so do not call every observed absence a permanent SPF failure.
Remove unused sending sources only after confirming they are not used. Avoid blindly flattening dynamic provider includes into hard-coded IP ranges: provider addresses may change. When necessary, ask the mail provider for a supported configuration.
SPF mechanisms and DNS-querying terms
This reference separates evidence from interpretation. It is general guidance, not the result of a live check of your domain.
| SPF term | Counts toward 10-term limit? | What to check |
|---|---|---|
include, redirect | Yes, if evaluated | Nested records can consume further terms. |
a, mx, exists, ptr | Yes, if evaluated | Some mechanisms have additional DNS constraints; ptr is discouraged. |
ip4, ip6, all | No | Direct mechanisms do not consume the term budget. |
exp modifier | No | An explanation lookup is separate from the ten-term limit. |
A single mx term can also involve additional DNS work. RFC 7208 separately restricts the number of MX records and address records examined, so a ten-term count by itself is not a complete evaluation.
What our SPF Generator can and cannot do
The SPF Record Generator creates or carefully adjusts a draft TXT policy and warns about obvious lookup-budget risks. It does not independently prove that every real mail sender will pass SPF.
Use the Email Domain Checker to inspect published records. For a real failing message, compare the evaluated identity and IP with the receiver-reported authentication results in the Header Analyzer.
Common questions
Is it ten TXT records?
No. It is a limit on DNS-querying terms encountered during SPF evaluation, including terms within nested policies.
Can I publish two SPF records to split the limit?
No. Multiple SPF policies at one owner name can cause SPF record-selection errors. Review the sending architecture instead.
Primary sources and fact-check
Reviewed October 20, 2026 against the specifications and provider documentation below. Provider products, interfaces, and requirements can change; check the official source before making a production DNS or mailing decision.