“SPF passes in the tool” and “the recipient reports SPF failure” are not necessarily contradictory. The tool may have validated syntax, tested a different IP or queried newer DNS. The recipient evaluated a particular SMTP connection. Diagnosis starts by reconstructing that connection, not by assuming either result must be wrong.
Identify what the tool actually passed
Save the tool's inputs and exact output. A valid-record indicator is not necessarily an SPF pass for a message. If it performed an evaluation, record the IP address, envelope sender, HELO where relevant and query time. Keep the distinction visible when reporting the incident to other teams.
Then collect the destination's trusted authentication result or SMTP rejection evidence. Do not treat a sender-supplied Authentication-Results field as the destination's verdict. RFC 8601 explains why results need a trust boundary.
Compare the identity and connecting address
SPF evaluates the connection against the relevant SMTP identity, not merely the visible From address. RFC 7208 §2.3 and RFC 7208 §2.4 describe HELO and MAIL FROM checks. Compare the receiver-observed IP and evaluated domain with the tool fixture.
An illustrative case: an application displays From billing@example.com but uses an envelope identity under a provider's domain. A tool test of example.com can be irrelevant to the receiver's actual SPF decision. In another case, the application leaves through a different relay than the administrator expected. Fix the understanding of the route before extending authorisation.
As described in RFC 7208 §10.3, if a forwarder is involved, the final receiver can see the forwarder's connection rather than the original sending IP. Do not add every observed forwarder to the origin domain's SPF as a blanket repair. Assess the complete indirect-mail flow and other authentication results instead.
Compare DNS at the relevant times
Retrieve the current applicable record and dependencies. Preserve the receiver's event time and any contemporaneous DNS evidence. A test performed after a repair cannot prove what the receiver saw earlier. Similarly, a provider dependency can change without a local record edit.
Check authoritative publication, recursive answers and error conditions. Distinguish an old cached policy from a missing policy or a temporary DNS error. RFC 7208 section 2.6 defines different result categories; do not collapse fail, softfail, temperror and permerror into one diagnosis.
Replay the actual path
Use a standards-aware evaluator with the observed inputs. Inspect the matched mechanism, qualifiers, recursive dependencies and any limit or DNS error. Where historical DNS is unavailable, label the replay as a test of current state rather than a reconstruction of the earlier event.
Test both address families if the sender can use both. Compare multiple affected and unaffected samples to see whether the failure follows a route, region, IP family or time interval. This is a recommended diagnostic method, not a claim that any specific provider distributes traffic in a particular way.
Make the narrowest supported repair
Correct the confirmed issue: wrong envelope configuration, missing authorised scope, malformed policy, broken dependency or routing inconsistency. Preserve the original state and obtain the normal change approval. Do not broaden the policy merely to make an unexplained sample pass.
After the repair, send through the same application route and inspect a new trusted receiver result. Check DMARC separately, because a raw SPF pass may be unaligned and an aligned DKIM pass may support DMARC even when SPF fails. The alignment diagnosis guide covers that distinction. Close the incident with the difference between the old and new evidence, not just another green checker screenshot.
DNS background: RFC 1035 section 3.2.1 defines resource-record TTL; RFC 2308 §5 covers caching negative answers. RFC 8767 §4 updates TTL semantics to permit stale use when authoritative refresh fails. These describe DNS behaviour, not a universal completion time for a change.
Use a concrete decision record
Hypothetical comparison: a checker evaluates IP A against example.com today; yesterday’s receiver evaluated IP B against bounce.service.example.net. Those are different input sets. Record both IP/domain/time triples and the DNS evidence available for each. If historical DNS is missing, state that the original result cannot be fully replayed. Do not label either tool faulty from these observations alone. No replay or DNS test was executed here.