SPF answers a narrow question: is the connecting server authorised to use the domain presented in a particular SMTP identity? It does not start with the sender name displayed in an inbox. That distinction explains why changing the wrong DNS record can leave an authentication problem untouched.
For a normal non-empty reverse path, the relevant identity is the domain in SMTP MAIL FROM. The address can be a provider-managed bounce address rather than the visible author. A separate HELO check can also occur. When MAIL FROM is empty, SPF constructs its MAIL FROM identity using the HELO domain and the local part postmaster. These identity rules are defined in RFC 7208 §2.3 and RFC 7208 §2.4.
Follow the envelope through one delivery
Imagine an application sending an invoice. The SMTP connection comes from 192.0.2.44, its MAIL FROM is receipts@bounce.example.com, and the message header says From: billing@example.com. These are synthetic values reserved for documentation, not a deployment recipe.
The receiver evaluates the connecting IP against the SPF policy at bounce.example.com. It does not select example.com's SPF policy simply because that domain appears in From. A policy at the parent does not automatically authorise its child.
Suppose bounce.example.com publishes v=spf1 ip4:192.0.2.44 -all. The ip4 mechanism matches and the result is pass. If the connecting address were 192.0.2.45, it would not match; evaluation would reach -all and return fail. Neither outcome says whether the invoice is genuine or the account sending it has been compromised.
Identify evidence you can trust
Ask for the original received message rather than a screenshot of its display name. Record the receiver, receipt time, connecting IP, evaluated SMTP identity and SPF result. Under RFC 8601 §7.1, the receiver's trusted authentication results or logs are stronger evidence than a header supplied by an arbitrary sender.
Under RFC 5321 §4.4, a delivered Return-Path can help reveal the envelope sender, but it is a trace of delivery rather than a command you can safely edit to change SPF. Gateways, resubmission and forwarding may create another SMTP transaction. Diagnose the transaction where the failing receiver performed its check.
Keep a short identity worksheet: visible From domain; MAIL FROM domain; HELO name; connecting IP; SPF record observed at the time; result; and any aligned DKIM result. The point is to prevent a record editor from becoming the first diagnostic step.
Handle bounces and forwarding separately
An empty reverse path is normal for certain delivery notifications. Do not treat it as missing evidence and substitute the visible From domain. Capture HELO and apply the null-path rule instead.
Forwarding introduces a different problem. The next receiver sees the forwarder's connecting IP, which may not be authorised by the original envelope domain. Rewriting the envelope can change the identity being checked. A pass for the rewritten identity is not automatically aligned with the visible author. Investigate the complete route and any surviving aligned DKIM signature rather than adding every forwarder to your policy.
Connect SPF to the business decision
DMARC adds an identity comparison: a passing SPF result must align with the author domain to satisfy its SPF path. A separate aligned DKIM pass can satisfy DMARC even when SPF does not. RFC 9989 describes that relationship.
For the invoice example, evaluate alignment under the applicable mode and organisational-domain discovery rules; do not assume that a shared text suffix proves alignment in every namespace. Strict SPF alignment requires exact domain equality under RFC 9989 §3.2.10.2; relaxed organizational-domain discovery is specified in RFC 9989 §4.10.2.
Before approving a change, ask the service owner which envelope identity the product supports and who controls its DNS. Preserve the previous record, make the smallest authorised change, and send a new representative invoice through the affected route. Close the issue only when the observed identity, result and required alignment meet the intended outcome.
The practical takeaway
Start with the SMTP envelope and connecting IP. Editing a domain that SPF never evaluated is not a repair, even if a record-checking tool turns green.
Keep the decision reproducible
For the invoice fixture, retain connecting IP 192.0.2.44, MAIL FROM domain bounce.example.com and visible Author Domain example.com as separate fields. A parent TXT edit is not evidence of a repaired child check. For a forwarded copy, capture a new transaction row instead of carrying the original IP forward. These are hypothetical inputs, not executed SPF or delivery observations.