An SPF forwarding investigation starts with two observed inputs: the IP address connecting to the evaluator and the domain being evaluated. Looking only at the visible From address can produce a persuasive but incorrect diagnosis. Write down those inputs at every hop before adding servers to a DNS record. The original author's SPF policy cannot describe every unrelated forwarding service a recipient may choose.
Capture the SMTP inputs
References: RFC 7208 §2.3, RFC 7208 §2.4, RFC 5321 §4.4.
At the initial receiver, identify the sending IP and MAIL FROM identity from trusted logs or reliable receiver evidence. At the final receiver, repeat the exercise for the forwarding connection. A Return-Path recorded after final delivery is useful but is not a complete history of prior envelopes. For an empty reverse path, account for SPF's HELO identity rules rather than inventing an envelope domain. RFC 7208, especially sections 2 and 4, defines the evaluation inputs.
Record DNS answers as observed at evaluation time when available. A later lookup may show changed authorization and cannot conclusively reconstruct a past result. Preserve temporary errors, permanent errors, fail and other outcomes distinctly. Collapsing every non-pass into spoofing loses the evidence needed to separate forwarding from a malformed policy or transient DNS problem.
Compare direct and forwarded delivery
References: RFC 7208 §4.1, RFC 9989 §4.4.2.
Suppose author.example authorizes its originating server but not forwarder.example's server. In the direct path, the first connection can pass against author.example. In the forwarded path with the original envelope retained, the final receiver evaluates a different IP against that same policy. The different result follows from the changed input; it does not imply that the original sender's DNS was necessarily wrong.
If the intermediary rewrites the envelope into its own domain, the evaluation uses that domain's policy. A pass there establishes authorization for the rewritten identity. DMARC separately compares the authenticated identity with the message's From domain. Keep that comparison visible in the case record. RFC 9989 defines the alignment requirement.
Reproduce the identity comparison
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
The retained strict-alignment fixture contrasts an original envelope with an SRS-style forwarder envelope. It supplies SPF pass or fail as input and computes the downstream alignment decision. In the srs-footer case, SPF is true for forwarder.example, DKIM is false, and the visible From remains author.example. The model returns false rather than treating a successful SPF check as sufficient.
This is executable identity arithmetic, not an SPF resolver. It does not implement includes, redirects, macros, lookup limits or DNS caching, and it does not reconstruct a production envelope. Use the result to understand the distinction, then collect authorized direct and indirect samples for the real deployment. External deployment evidence is not present; the historical capture supplies a separate controlled SMTP comparison below.
Choose the responsible repair
References: RFC 7208 §2.4, RFC 6376 §3.4.
For an intermediary under your control, inspect supported envelope rewriting and its own sending authorization. For an originating sender, preserve aligned DKIM through the route. Do not add a recipient's arbitrary forwarder to the original domain's SPF merely because it appears in a failure report; authorization expands who may use that envelope identity.
After a change, compare the same route and message type, then record SPF, alignment, DKIM and delivery as separate outcomes. Keep a rollback plan for the specific configuration changed. A broader SPF record is not a substitute for evidence that the forwarding service is authorized, required and operating as intended.
Retained SMTP laboratory evidence
References: RFC 7208 §4, RFC 6376 §6.
The retained capture dated 7 November 2026 at 21:29:16 UTC records connecting IP and MAIL FROM for six deliveries. With fixture DNS authorizing only 127.0.0.2 for author.example, pyspf returns pass for the direct connection and fail for the 127.0.0.3 forwarder retaining that envelope. Rewriting into forwarder.example, whose fixture policy authorizes 127.0.0.3, changes SPF to pass. The visible author remains author.example, so the strict-alignment evaluator still depends on the actual DKIM result. DNS answers and every lookup are retained.
The historical runner and retained messages were inspected for this revision; the network experiment was not rerun. Its original execution used loopback only and sent no Internet mail. Its receiver creates Authentication-Results from its own checks, giving those fields known laboratory provenance. Authentication outcome and disposition remain separate: all six SMTP samples receive 250 under an explicit capture policy, including failing samples. The trust boundary is this controlled laboratory, not a production mailbox provider. The DNS adapter supplies retained fixture answers rather than querying public DNS, and the DMARC evaluator uses strict domain equality only. Full organizational-domain discovery, production policy parsing and live deployment outcomes remain untested.