Start with the evaluated identity
The statement “we published -all, so receivers must reject impersonation” combines three different decisions. A domain publishes an authorization policy, an evaluator obtains an SPF result for a connecting address and identity, and a receiver decides what to do with the message. Keeping those decisions separate makes troubleshooting more accurate and prevents a configuration change from becoming an unsupported security promise.
SPF evaluates the HELO identity or the MAIL FROM identity, not simply the address displayed in the message’s From field. Record the connecting address, identity type, evaluated domain and time before interpreting any policy. A result for a provider’s envelope domain does not automatically describe the visible brand domain. For a null reverse path, the identity handling also needs to be captured rather than guessed from a screenshot. RFC 7208, section 2.3 and 2.4
What the all mechanism actually does
The all mechanism always matches. With the minus qualifier, a reached -all yields fail. That statement is precise but conditional: an earlier matching mechanism can finish evaluation first, and an error can interrupt evaluation before the terminal mechanism is reached. Calling the terminal token a “hard reject switch” hides both conditions. Its meaning is an authorization assertion, not a command executed inside every recipient’s mail system.
Mechanisms are processed in their specified order. A permitted address may match an earlier ip4 or ip6 mechanism and produce pass without reaching -all. An include may also match. Conversely, an invalid policy or exhausted evaluation budget can produce permerror instead of the fail someone expected from reading the final token. The record’s last characters cannot replace an actual evaluation path. RFC 7208, section 4.6, 5.1 and 8
Separate child results from parent results
An include is a recursive check whose result is mapped into the parent mechanism. It is not text pasted into the parent policy. A child pass makes the include match; a child fail, softfail or neutral makes it not match. The parent then continues to its next applicable mechanism. A child temperror or permerror propagates as an error, while a child none is treated as permerror for the include.
This matters when a supplier ends its own policy with -all. A sender not authorized by that supplier does not automatically fail the customer’s entire policy. Another authorized service may appear later in the parent record. Preserve the child result and parent continuation separately in the diagnostic worksheet. Otherwise a legitimate multi-service design can be incorrectly described as contradictory or broken. RFC 7208, section 5.2
Receiver policy is another evidence layer
RFC 7208 describes fail as an explicit statement that the client is not authorized to use the domain in the given identity. Its result-handling guidance leaves disposition to the receiver’s policy. A receiver may reject during SMTP, accept and mark, or use the result alongside other information. The exact action cannot be proven by public DNS alone. A report of acceptance does not demonstrate that the published mechanism was ignored; it might reflect the evaluated identity, an earlier match, or the receiver’s chosen treatment.
Do not turn this distinction into advice to weaken SPF indiscriminately. An accurate policy still matters. First inventory legitimate routes, including forwarding behavior and third-party sending, then distinguish an authorization mismatch from the handling chosen by a particular receiver. Claims about DMARC additionally need its own identity-alignment and policy evidence. SPF fail by itself is not a complete DMARC diagnosis. RFC 7208, section 8.4 and 10
Acceptance worksheet for a proposed review
Create one row per authorized message example, not one row per screenshot. Capture the route owner, connecting address, HELO name, envelope sender, evaluated domain, exact TXT record set, retrieval time, parser version and final SPF result. Attach the ordered mechanism path and explain why evaluation stopped. Keep the receiver’s Authentication-Results trust boundary and provenance separate from any untrusted header supplied by a sender.
Add a second part for disposition: SMTP response if available, receiving system, timestamp, queue or event identifier, and whether the evidence demonstrates acceptance, rejection, quarantine or merely an application status. Redact unnecessary recipients and message content. A “delivered” status from a sending application does not automatically establish inbox placement. Mark unavailable fields as unavailable rather than filling them from expectations.
The review passes only the claim actually evidenced. A complete policy trace can support an SPF conclusion while receiver handling remains unresolved. An SMTP rejection can establish a particular transaction’s outcome without proving all receivers behave alike. Record those two acceptance decisions independently and retain an owner for missing evidence.
Fictional diagnosis: two services and one terminal fail
Consider a fictional organization with a parent policy that checks a newsletter supplier, then a transactional supplier, then -all. No DNS was queried and no message was sent for this example. The newsletter child returns fail for a transactional address. The correct next step is to resume the parent, not declare a final failure. If the transactional include returns pass, the ordinary positive include matches and the parent returns pass.
Now imagine a different address that matches neither supplier. If no earlier error occurs, evaluation reaches -all and returns fail. Whether a particular receiver rejects that message is a separate observation. A support note saying “the supplier’s -all blocked us” would be premature in the first case and incomplete in the second. The useful correction is to label the child result, the parent result and the receiver action separately.
A third hypothetical case has a temporary DNS failure while evaluating the first supplier. The policy cannot be diagnosed by jumping directly to the final -all. Preserve the error path and avoid changing the record merely to force a preferred interpretation. These examples illustrate reasoning only; they are not received-message evidence or tested outcomes.
Publication and operational holds
This manuscript does not establish the behavior of any real sender or receiver. Before publishing an operational diagnosis, obtain the catalogue-required result-specific examples and their DNS or message evidence through an authorized workflow. A qualified reviewer should inspect the complete path and confirm that the receiver evidence belongs to the same transaction and time window.
Keep changes separate from diagnosis. Removing a legitimate service, changing qualifiers or adding broad authorization can affect real mail and requires its own review. The draft’s original evidence, human expertise, source applicability, production route, visual accessibility and owner release gates remain open. A fictional example is not a substitute for those gates, even when its logic follows the standard.