When two SPF checkers show different lookup counts, do not choose the more reassuring number. Establish what each tool measured. One may display DNS-dependent terms on an evaluated path, another may expand a policy graph, and a third may show network queries. Those outputs can answer different questions even when they inspect the same domain.
Ask what the counter means
RFC 7208 section 4.6.4 limits evaluated DNS-dependent terms across recursion. That is not simply the count of all TXT strings, every DNS packet or the number of includes visibly written at the top level. Cached answers do not grant a larger logical term budget.
Separate other constraints too. The specification addresses void lookups and mechanism-specific limits in addition to the main evaluated-term ceiling. A tool may present one combined warning while another exposes each category. Save the exact warning text and documentation rather than assuming every red label means the same thing.
Give both tools the same fixture
Record the evaluated domain, connection IP, sender identity, HELO where relevant, resolver view and query time. If the tool accepts only a domain, find out whether its count is a static estimate, a worst-case analysis or a particular synthetic path. A domain-only scan is not automatically equivalent to evaluating a real connection.
For policies using macros, the missing identity inputs can matter directly. Compare IPv4 and IPv6 cases separately when both occur. Preserve the DNS answers or a reproducible controlled fixture so a later provider change does not turn a supposed tool comparison into a comparison of different policies.
Walk a small illustrative example
Consider a synthetic policy:
v=spf1 ip4:192.0.2.10 include:_spf.vendor.example -all
Under RFC 7208 §4.6.2 and RFC 7208 §5.6, for 192.0.2.10 the explicit address can match before the include is evaluated. For another address, evaluation can reach the include and its nested dependencies. A graph-expansion tool may display that branch even when the first message's path never reaches it. The different numbers need explanation, not an automatic verdict that either tool is defective.
Make the include target explicit to compare numeric counts. In this synthetic fixture, _spf.vendor.example has exactly one SPF TXT record, v=spf1 ip4:192.0.2.20 -all. Assume successful DNS retrieval, valid syntax, no additional dependencies and ordinary MAIL FROM evaluation for the parent domain.
- Input 192.0.2.10: the parent's first ip4 mechanism matches. The actual path evaluates 0 DNS-dependent terms and never visits the include.
- Input 192.0.2.20: the parent's ip4 does not match. The include is evaluated, its target ip4 matches, and the parent returns pass. The actual path evaluates 1 DNS-dependent term, the include.
- Input 192.0.2.30: the include target reaches -all and returns fail, so the include does not match. The parent reaches its own -all and returns fail. The actual path still evaluates 1 DNS-dependent term, consistent with RFC 7208 §5.2.
A static graph count of DNS-dependent terms is 1 for this entire fixture, regardless of which connection is selected. The initial TXT retrieval of the parent policy is required but is not itself one of the evaluated terms counted against this limit. Thus a display of 0 for the first input and 1 for the expanded graph can both be explained. These are analytical expected results, not executed measurements or network-packet counts.
Now imagine that the included policy changes between the two scans. A fresh scan could legitimately expose a different dependency tree. Save timestamps and actual answers before escalating the disagreement. A screenshot without inputs is weak evidence.
Compare traces at the first divergence
Build a side-by-side list of the evaluated terms. Find the first place the tools disagree: record selection, an early match, recursion, a DNS error, a macro expansion or a counting convention. Check whether one stops at an error while the other continues for diagnostic purposes. A diagnostic expansion can be useful without representing a valid completed evaluation.
If a tool appears to contradict the standard, produce a minimal synthetic fixture and the expected behaviour with a section reference. Send that to the tool maintainer through your normal support process, avoiding confidential production data where a fixture will do. Do not alter production just to make inconsistent dashboards agree.
Make a decision from the resolved evidence
A valid short path for one sender does not establish health for every sender. Test representative legitimate inputs and a nonmatching input, and inspect the dependencies that could change later. Conversely, a large static graph is not by itself proof that every message exceeds the evaluated-term limit.
Record which measurement supports your decision, any unresolved tool limitation and the expected impact of a proposed change. Use mechanism ordering only after understanding those paths. If you cannot reconcile a consequential discrepancy, retain the current evidence and seek an implementation-specific review rather than presenting an unexplained count as certainty.
Put the decision in writing
For the given two-record fixture, retain the parent and child text, input address, count definition and expected pass/fail. The 0/1/1 values are analytical evaluated-term counts, not measured DNS packets or independent tool execution. If a tool reports a different quantity, label it before comparing. A discrepancy in an error-handling path needs its own fixture rather than extrapolation from these successful lookups.