SPF glossary
What counts toward SPF's 10-DNS-lookup limit?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed September 8, 2026
SPF allows at most 10 DNS-querying terms during one evaluation. The include, a, mx, ptr, and exists mechanisms and the redirect modifier count when evaluated, including terms reached inside referenced records. ip4, ip6, and all do not consume this budget. RFC 7208 section 4.6.4 requires a permerror result when the limit is exceeded.
10-DNS-lookup limit at a glance | |
|---|---|
| Tag | Evaluation limit, not a DNS tag |
| Valid values | At most 10 evaluated DNS-querying terms across the complete SPF evaluation |
| Default | Exceeding the limit produces permerror; it does not determine the receiver's delivery decision. |
| Where it goes | Includes recursively evaluated records, not just the root TXT record. |
How 10-DNS-lookup limit works
Count evaluated terms, not packets sent to a DNS resolver. The initial SPF TXT retrieval is outside this ten-term budget. An evaluated include counts once, and DNS-querying terms reached inside its target also count. DNS caching does not grant a larger budget. See RFC 7208 section 4.6.4.
SPF evaluates mechanisms in order. A matching mechanism can end evaluation before later terms are reached; redirect is used only when the record's mechanisms do not match. A count therefore needs the SPF identity, test IP, record contents and path evaluated. The number of includes visible in the root record is not enough. RFC 7208 sections 4.6 and 6.1 define that evaluation order.
For example, a root record with two includes consumes two terms if both are evaluated and their targets contain only ip4/ip6 and all. If the first target instead evaluates two additional includes before returning, that path consumes four terms in total. Separate limits also apply to MX/PTR processing and void lookups; staying within ten does not establish that the entire record evaluates successfully.
If the observed error is already 'too many DNS lookups', use the SPF PermError repair guide for the evidence, authorization decisions and retest sequence. This reference explains the count; it does not establish which of your senders can safely be removed.
Correct record vs common mistake
Correct
Root: v=spf1 include:a.example include:b.example ~all
a.example: v=spf1 ip4:192.0.2.0/24 ~all
b.example: v=spf1 ip6:2001:db8::/32 ~allIllustrative records only. If both includes are evaluated, the two include terms consume two units. The ip4, ip6 and all mechanisms consume none. Use your provider's real records when configuring a domain.
Common mistake
Root include count: 2
Additional nested include terms evaluated: 9
Total evaluated DNS-querying terms: 11Counting only the two root includes misses the nested work. An evaluation that reaches the eleventh DNS-querying term exceeds the limit.
Which terms consume the SPF lookup budget?
| Evaluated term | Counts toward ten? | Counting boundary |
|---|---|---|
| include / redirect | Yes | Count the term and any DNS-querying terms reached in its target |
| a / mx / ptr / exists | Yes | Count evaluated terms; additional processing limits can also apply |
| ip4 / ip6 / all | No | These mechanisms do not consume the DNS-querying-term budget |
Why it matters for MSPs
A provider can change a referenced SPF record without an edit to the client's root record. Keep the recorded identity, test IP and include-chain evidence with the client finding so a later check can explain what changed.
Trusted by MSPs
“We absolutely love it. We are actively selling it and growing the usage.”
Ravi Ramharak , Co-Founder, MSP CorpRead the case study →5.0 out of 5 on G2Trusted by over 10,000 domains
More customer stories →
DMARC software that does the work
Palisade analyzes aggregate reports and prepares prioritized authentication-remediation tickets. An operator reviews the sender evidence and proposed changes. A passing lookup does not establish sender authorization, message alignment or inbox placement.
15-day full-product trial. Nothing is charged until it ends.
Questions readers ask