An SPF incident that appears limited to one recipient network is a comparison problem. First establish whether that network evaluated the same sending IP, envelope domain and DNS policy as your successful controls. A broad authorisation change can hide the difference while increasing who may send using your domain.
Build a matched comparison
Select a failed transaction and a successful transaction from the same application and approximate time. Record the UTC time, connecting IPv4 or IPv6 address, SMTP MAIL FROM, HELO name, recipient network, exact SMTP reply, and trusted authentication result if the message was accepted. A message rejected during SMTP may never have a delivered header to inspect. Preserve the sender's transaction log instead. Treat identifiers and message contents as restricted operational evidence.
SPF normally evaluates the MAIL FROM domain; for a null reverse path, its MAIL FROM identity is constructed using postmaster and the HELO domain. The visible From address is not the lookup instruction. A forwarding service can also change the connecting IP seen by the final receiver. RFC 7208, sections 2.3–2.4 and 10.3.
Separate the failure classes
An explicit fail points toward an evaluated path that did not authorise the client. Permerror calls for inspection of policy syntax, multiple SPF records, recursive dependencies and evaluation limits. Temperror calls for investigation of temporary lookup or processing problems. None means no usable evaluated domain or no applicable SPF record was found, rather than an explicit prohibition. Neutral means the policy makes no definite authorization assertion; softfail expresses a weaker negative assertion than fail. Neither is an SPF pass. Capture the result before interpreting a generic “authentication problem” ticket.
Compare authoritative DNS answers with recursive answers and their timestamps. Query the exact owner name and every dependency reached for that IP. SPF's ten-term limit covers evaluated include, a, mx, ptr and exists mechanisms and the redirect modifier, including nested evaluation, rather than every DNS packet or TXT fragment. The ip4, ip6 and all mechanisms do not consume that term budget; separate limits can still apply to other DNS work. A static tool scan and a receiver's actual path can therefore disagree. RFC 7208, sections 4.5–4.6.4 and 8.
Work through a controlled example
Illustrative scenario: the sender reaches network A over an authorised IPv4 address but reaches network B over an unlisted IPv6 address. The application's name and From address look identical. The useful intervention is to verify ownership and intended use of the IPv6 route, then authorise it narrowly if appropriate or stop using it. Adding the recipient network to SPF would address the wrong side of the connection.
A second possibility is forwarding: network B receives from an intermediary rather than your original outbound host. Do not add arbitrary forwarders to your policy. Check the forwarding path, surviving aligned DKIM and the receiver's policy. A passing SPF result can still be unaligned for DMARC. RFC 9989, section 4.4.
Close with reproducible evidence
Make one controlled change with an owner, saved prior value and rollback condition. Repeat the matched tests through the affected route, including both address families where used. Confirm SPF, aligned authentication and SMTP handling separately. If the same inputs and policy still yield different results, prepare a redacted evidence packet for the receiving operator. Record the unresolved implementation difference instead of labelling the whole network broken.
Use a matched evidence worksheet
- Failed/control pair: record UTC times, application and recipient network for both.
- Connection: compare the actual IPv4 or IPv6 source and any forwarding hop.
- Identity: compare MAIL FROM, HELO and the domain the receiver actually checked.
- Policy: retain dated TXT answers and the evaluated dependency path.
- Result: preserve fail, softfail, neutral, none, temperror or permerror exactly, plus the SMTP reply.
- Action: repair only a verified difference; repeat the same route and retain unresolved differences for escalation.