Evaluate a path, not a decorative lookup score
SPF evaluation depends on the connecting IP address, the relevant SMTP identity and the DNS state encountered along the evaluated path. A checker that displays only a static count of visible include terms can miss nested dependencies, early matches, errors and redirect behavior. A useful output should show the inputs, ordered evaluation and reason for the result while distinguishing an observed run from a hypothetical worst-case analysis.
RFC 7208 defines SPF and its check_host evaluation. This article proposes checker requirements and defensive fixtures. It does not claim that EmailAuth implements them or that any real sender was tested. No user-domain DNS queries, SMTP connections or test messages were performed. The retained standard is documentary evidence, not an execution transcript.
Record the identity and connection inputs
The worksheet should identify the IP address, domain and sender inputs supplied to the evaluation, with the SMTP context needed to interpret them. SPF evaluates the relevant MAIL FROM identity and has specified HELO behavior, including the null reverse-path case. It does not directly authenticate the human-readable display name or prove that a message's content is legitimate. Keep those boundaries visible before interpreting pass as a broader trust signal.
RFC 9989 adds an alignment relationship to the visible From domain when SPF contributes to DMARC. A successful SPF evaluation for some other domain is not automatically an aligned DMARC pass. The checker should preserve the actual evaluated identity so downstream analysis can assess that relationship without guessing. No received-message sample is available in this manuscript to establish an actual alignment outcome.
Show ordered mechanisms and dependency results
RFC 7208 evaluates mechanisms in order, with the result depending on matches and errors. An early match can mean later mechanisms are not evaluated for that input. The checker should therefore show which terms were reached, which were not and why processing ended. If it also computes a dependency inventory or possible nonmatching path, label that as a different analysis rather than presenting it as the executed path.
An include is not merely text pasted into the parent record. Its referenced evaluation has defined result handling: a referenced pass produces a match for the include, while other results follow the standard's mapping. Redirect is a modifier evaluated under its own rules after no mechanism matches, and any all mechanism causes redirect to be ignored. These distinctions matter when explaining why two superficially similar records behave differently.
Apply the ten-term limit precisely
Section 4.6.4 limits the total evaluated DNS-query-causing terms to ten: include, a, mx, ptr, exists and redirect are the listed mechanisms or modifier. Exceeding that limit requires permerror. The all, ip4 and ip6 mechanisms and exp modifier are not subject to that same limit; exp can cause a later lookup. The limit is not a simple maximum number of TXT records or raw DNS packets observed on the wire.
Nested evaluations contribute to the relevant overall evaluation budget. Additional limits apply to address lookups associated with mx and ptr processing, with different prescribed handling. A checker should implement and report those details rather than flatten them into an unqualified ten DNS queries slogan. It should also distinguish cached resolver activity from the logical terms evaluated: fewer network packets do not authorize ignoring the protocol's evaluation limits.
Distinguish void answers from temporary failures
RFC 7208 describes void lookups as positive DNS responses with no answers or Name Error responses. Implementations should limit these to two, may make the limit configurable, and are recommended to default to two when configurable. Exceeding the applied void limit produces permerror. This is a SHOULD-level recommendation with configurable behavior, not a universal assertion that every implementation always enforces an identical fixed limit.
A DNS timeout or server failure is not simply another void answer. The relevant SPF error rules can produce temperror, while permanent evaluation problems produce permerror. Record the actual DNS response or failure and the rule used to interpret it. Do not turn an unavailable dependency into a guessed nonmatch or a clean pass. The checker should expose uncertainty and preserve enough evidence to reproduce the distinction later.
Represent cycles and malformed records honestly
Cyclic dependencies can repeatedly consume evaluation resources and reach defined limits; they should not be represented as a harmless deduplicated graph that guarantees a successful result. A checker may detect and explain a cycle, but its reported protocol outcome must match the implemented standard and input. Retain the chain of referenced names and the point at which processing stopped without executing uncontrolled retries.
Record selection and syntax matter before path evaluation. Multiple SPF records at the same identity are not a valid way to merge senders and produce permerror under the standard. Unknown mechanisms and unknown modifiers have different treatment; an unfamiliar mechanism is not safely ignored merely because unknown modifiers can be ignored. The test plan should cover these distinctions rather than treating every unsupported item as one generic warning.
A dependency-path worksheet
Create a worksheet with evaluation inputs, implementation version, DNS observation times, selected SPF record, ordered terms, nested dependencies, term budget and void count. For each step, record response status, match or nonmatch, error mapping and stopping reason. Add a separate column for unevaluated dependencies so the reader can distinguish actual path evidence from inventory. Preserve the resolver context and any configurable limits.
Proposed fixtures should include a representative matching path, a nonmatching path reaching later dependencies, a cycle, void responses and unavailable DNS. Use controlled synthetic DNS fixtures rather than querying a customer's infrastructure without authorization. Expected results should cite the relevant standard section and identify implementation-configurable behavior. No fixture was run here, so the worksheet contains requirements rather than fabricated transcripts.
Fictional diagnosis: a short record with a long path
A fictional operator sees only a few include terms in a top-level record and assumes the lookup budget is safe. A proposed fixture review reveals that each term can lead to further dependencies on the nonmatching path. A different input might match early and never reach those later terms. The two paths can therefore consume different logical budgets even though the published top-level text is identical.
The team would retain the actual evaluation inputs and path before recommending a change. It would not blindly flatten provider records into static IP ranges, because that can shift update responsibility and become stale. This scenario is fictional: no provider dependency, address range or real record was queried or modified. It illustrates why a checker must explain the path rather than display only a count.
Keep the conclusion scoped
A useful result says which identity and IP were evaluated, under what DNS state and implementation behavior, and why the result occurred. It does not promise every sender will pass or that a pass establishes business legitimacy. A dependency inventory is valuable, but it should not be confused with an executed SPF evaluation.
The catalogue requires representative matching, nonmatching, cyclic, void and unavailable-DNS cases. Those original fixtures and results remain open. Human specialist review, source applicability, production routes, accessibility and owner release also remain open. This draft supplies a proposed evidence model, not executed scans or verified tool behavior.