A result label is not a diagnosis
Permerror indicates a permanent error in SPF evaluation, but it does not identify a unique defect. A malformed selected policy, multiple applicable SPF records, a missing recursive policy or an exceeded evaluation limit can produce this result through different rules. A support response that translates every permerror into “too many DNS lookups” can send an administrator toward the wrong repair and potentially damage valid sender authorization.
Start by preserving the identity and inputs used for evaluation. Record the connecting address, HELO or MAIL FROM context, evaluated domain, sender argument and time. Then preserve the actual DNS response and selected SPF policy. Without those inputs, two different reports may concern different identities or different snapshots rather than disagreeing about the same policy. RFC 7208, section 2.3, 2.4 and 8.7
Check record selection and syntax first
SPF policy selection has specific rules. Multiple selected SPF records cause permerror; they are not merged into a larger policy and should not be treated as a convenient way to divide suppliers. TXT character strings within one record are a different matter from multiple independent records. Retain record boundaries so the reviewer can distinguish a presentation detail from a real selection problem.
Syntax also needs a complete-policy review. RFC 7208 requires the syntax check before mechanism evaluation; an invalid mechanism can therefore matter even if someone expects an earlier mechanism to match. Unrecognized mechanisms and ignored unrecognized modifiers are not interchangeable categories. Avoid vague guidance to delete every unfamiliar token. Determine its grammatical role and the standard’s handling before deciding whether it is an error. RFC 7208, section 3.2, 4.5, 4.6 and 6
Then classify evaluation-budget failures
For the overall DNS-causing-term budget, include, a, mx, ptr, exists and redirect count during evaluation. The limit is ten, and exceeding it must produce permerror. This is not simply the number of DNS packets, the number of top-level includes or the number of unique suppliers. Recursion shares the budget, and caching does not remove logically evaluated terms.
Other limits need their own labels. Void responses have a SHOULD-level limit of two, with permitted configuration and a recommended default of two when configurable; exceeding the applicable limit produces permerror. MX processing has additional mandatory constraints. A statement that “the record has only nine includes” does not exclude these other causes, and a high raw packet count does not by itself prove the overall ten-term limit was exceeded. RFC 7208, section 4.6.4
Separate error results from authorization results
Fail asserts that the client is not authorized for the evaluated identity. Permerror means the evaluation could not yield the intended authorization result because of a permanent error. Temperror represents a transient error. None is also a distinct result, with special mapping when encountered through include or redirect. These labels should not be collapsed into a single “SPF failed” bucket when explaining a corrective action.
The receiver still decides how to handle results under its own policy. A rejected message does not establish which SPF defect caused rejection unless the evidence supports that link. Similarly, accepted mail does not prove the policy was valid. Keep the authentication diagnosis and delivery disposition in separate fields, and avoid promising that one DNS repair will fix every delivery problem. RFC 7208, section 5.2, 6.1 and 8
Triage worksheet with explicit stop reasons
Use a worksheet divided into selection, parsing and evaluation. In selection, retain the query name, response, TXT record boundaries and count of selected SPF records. In parsing, retain the exact concatenated record text, parser version, offending token if any and the rule violated. Do not normalize away the error before preserving the original evidence.
In evaluation, record each reached mechanism or modifier, current domain, expanded target, cumulative term count, response classification, recursive child result and continuation decision. Keep void totals and supplementary limits distinct. Mark the first supported stop reason. If the parser rejected the policy before evaluation, do not invent a path that the evaluator never executed merely to demonstrate another possible issue.
A proposed correction should name the defect it addresses, the owner who confirms the intended authorization, and the routes that must still work. Record unresolved secondary findings separately. A malformed policy may also contain an excessive dependency graph, but the investigator should explain which conclusion is observed and which remains a static concern pending valid evaluation.
Fictional diagnosis: two identical labels, different repairs
In fictional case A, a domain publishes two separate TXT records that both qualify as SPF policies. The useful diagnosis is a record-selection error, not an excessive lookup count. A proposed repair would require reconciling the intended authorization into one supported policy, after confirming all legitimate routes. Deleting an arbitrary record could silently remove a required service. No real DNS response or correction was collected for this case.
In fictional case B, one syntactically valid policy follows a nested route that attempts an eleventh counted DNS-causing term before any match. The useful diagnosis is the exceeded overall budget. Combining TXT strings would not solve that problem because the policy is already one selected record. The review instead needs the exact dependency path and a supported redesign that preserves sender coverage.
A third fictional report says only “permerror” and contains no record snapshot or trace. The correct outcome is insufficient evidence, not a guess between A and B. Ask for a minimal diagnostic bundle through an authorized channel, with private message content and unnecessary addresses excluded. These scenarios are conceptual comparisons, not executed fixtures, receiver results or evidence that a named provider is misconfigured.
Acceptance and release criteria
A repair claim should be narrower than “SPF is fixed.” State whether record selection, syntax, a particular evaluation path or a specific supplier dependency was corrected and what evidence supports that claim. Validate that the proposed change does not authorize unintended senders or exclude legitimate ones. Keep the receiver’s final delivery outcome outside the claim unless separately observed.
For this draft, the required annotated path showing each counted term and the exact failing branch remains outstanding. If the actual issue is parsing or selection, retain that primary evidence as well and obtain human review of how it satisfies the article’s intended scope. Do not manufacture an evaluated path for an error that stops before mechanisms are processed.
No scans, parser executions, DNS modifications or message tests were performed here. Original evidence, human review, source applicability, production routes, visual accessibility and owner release remain open. The manuscript provides a triage framework and fictional reasoning examples while explicitly withholding any claim of a completed operational diagnosis.