Recognize recursion without inventing an error class
An SPF loop occurs when recursive references lead evaluation back into a policy already on the active path. A graph can show a direct self-reference or a longer cycle involving several domains. That structural observation is valuable, but the diagnosis must also show whether the specific evaluation reaches those references. An earlier matching mechanism can stop a path before the cycle is entered.
RFC 7208 specifies recursive processing and evaluation limits. It does not define a separate standard result named cycleerror. Describe the observed result using the defined SPF vocabulary and explain the path that supports it. A conforming evaluator must apply the overall term limit; unbounded recursion is not an acceptable interpretation. A tool’s own “loop detected” label can be useful diagnostic metadata without becoming a new normative SPF result. RFC 7208, section 4.6.4, 5.2 and 6.1
Include is not policy substitution
Include recursively evaluates another domain using the same client address and sender inputs. Its child pass creates a match; fail, softfail and neutral produce a nonmatch. Errors propagate according to the specified mapping, and none maps to permerror. After a nonmatch, the parent can resume at the next mechanism with its previous domain restored.
This distinction helps explain apparent loops. A child may refer back to a parent only on a later branch that some senders never reach. The graph is still a maintenance concern, but a particular early pass does not prove the cyclic branch was exercised. Preserve the ordered mechanisms and the child-to-parent return mapping rather than drawing an unlabeled arrow and declaring every message broken. RFC 7208, section 5.2
Redirect has different termination semantics
Redirect is applied when no mechanism matches and the modifier is applicable. It delegates the result to the target policy rather than asking only whether a child passes for an include. The standard says redirect is ignored when an all mechanism is present in the record, regardless of order. Therefore a text search for redirect does not establish that the edge can execute.
A redirect target that yields none is an error case, not an implicit authorization or neutral fallback. Record the expanded target and its policy state. If a domain redirects to another domain that redirects back, the review must explain the lack of a terminating match along the illustrated route and the shared budget consumed by recursive processing. Do not claim a successful correction merely because one visible arrow was deleted. RFC 7208, section 6.1
Use an active-path worksheet
For each proposed diagnostic path, retain the starting identity, connecting address, sender argument, current domain, exact record, ordered term and expanded target. Maintain an active stack of domains and reference types. When a target already appears on that stack, annotate the repeated segment with the first and second entry points. A separate visited-node set can describe discovery, but it should not replace the active stack used to explain recursion.
Include a running count of evaluated DNS-causing terms and identify any earlier syntax, missing-policy or temporary-DNS error. The earliest supported termination matters. A static cycle found elsewhere in the graph should not be presented as the cause of a message that already stopped for a different reason. Conversely, an early-pass example should not be used to dismiss a reachable cyclic branch affecting another route.
The worksheet should end with one of three clearly labeled outputs: an actual retained trace, a static structural finding, or a fictional reasoning example. Only the first can substantiate an executed diagnosis, and only within its input and time scope. This article supplies the method and fictional examples, not a real trace.
Fictional diagnosis: a reciprocal include
Suppose fictional policy A includes B, and B includes A before any matching mechanism for the hypothetical client. No queries or evaluator executions were performed. The active path is A, then B, then A again. The repeated domain reveals a reachable cycle under those assumptions. Each evaluated include contributes to the shared counted-term budget; recursion does not reset the allowance when the current domain changes.
It would be misleading to report “the second visit is always a mandated cycleerror.” The standard’s result vocabulary and limits must remain intact. A proposed evaluator may detect recursion early for diagnostics, but any statement about its actual returned result requires its implementation evidence. The manuscript instead explains that the hypothetical path cannot be allowed to recurse without the required limits.
Now add an earlier matching ip4 mechanism to B for a different hypothetical sender. That path can pass before the return to A. The structural cycle still exists in the policy graph, but this sender did not exercise it. A useful repair review considers both the failing path and legitimate early-matching routes so the fix does not accidentally remove authorization that still matters.
Repair ownership before rewriting records
A circular reference often spans administrative boundaries. Identify who controls each record and why the relationship was introduced. A customer policy should not be substituted into a supplier dependency merely because the names appear related. Ask for the provider-supported authorization target or a confirmed correction through an approved support process; this manuscript neither contacts a supplier nor proposes universal replacement values.
The smallest supported repair may be removal of an obsolete reciprocal dependency, correction of a mistaken target, or a provider-maintained policy change. Choose based on ownership and legitimate sender evidence, not solely on reducing graph edges. Preserve the before state and the intended authorization set, and document any services whose needs remain unresolved.
Acceptance requires both the cycle illustration and a minimal provider-confirmed replacement evaluation. A new diagram without a cycle is not enough if the proposed record no longer authorizes a required route. Compare the intended routes, error handling and budget before and after the separately approved change. Avoid claiming that DNS caches everywhere immediately reflect a correction.
Unverified evidence and publication boundaries
The catalogue’s original evidence requirement remains open: show the cycle and a minimal provider-confirmed replacement evaluation. No provider confirmation, production DNS edit, external query or execution result exists for the fictional examples. They explain how to reason, not how a named supplier currently behaves.
All six release gates remain open, including original evidence, human review, source applicability, production routes, visual accessibility and owner release. A later operational article should retain the relevant source snapshots, change approval and bounded verification evidence. Until then, the appropriate conclusion is a proposed diagnostic and repair workflow, not a resolved incident or a guarantee that every receiver would report the same implementation-specific detail.