A mail server can send a legitimate message with an empty SMTP reverse path, written as MAIL FROM:<>. Delivery-status notifications use a null reverse path under RFC 5321 §4.5.5 to avoid creating endless bounce loops. Empty reverse path does not mean there is no SPF evaluation to consider: RFC 7208 §2.4 defines a MAIL FROM identity using the local-part postmaster and the HELO domain in this case.
Administrators who test only ordinary user mail can therefore miss a separate authentication path used by the server itself.
Distinguish HELO from the visible sender
HELO or EHLO introduces the SMTP client to the receiving server. Its domain is separate from the message's visible From header and can differ from a non-empty MAIL FROM domain. A host might introduce itself as relay.example.com while transmitting user mail with an envelope sender at example.com.
RFC 7208 §2.3 recommends checking HELO separately and recommends doing so first when both identities are checked. The MAIL FROM rules depend on whether the HELO check was performed and reached a definitive policy result. Do not assume every receiver will emit two independent SPF results for every message.
For the HELO check described in the RFC, the supplied value must be a valid multi-label domain name. A malformed value or address literal cannot be treated as if it were an ordinary queryable hostname. Correct the sending server's configuration through its supported controls rather than inventing DNS entries for malformed identities.
Publish for the hostname that is actually used
Capture a controlled SMTP transaction or trusted receiver log to establish the HELO value. Then query SPF TXT at that exact hostname. The SPF policy at example.com does not automatically apply to relay.example.com.
For a server with stable, explicitly controlled egress addresses, a narrow policy can describe those addresses. For hosted sending infrastructure, follow the provider's supported configuration and ownership boundaries. Do not publish a guessed record on a hostname you do not control, or assume that a hostname's A record is necessarily the SMTP egress address.
Include IPv6 in the review. An MTA can present the same HELO over different address families, and a policy that covers only its IPv4 source may produce different outcomes over IPv6.
Exercise normal and empty-envelope traffic separately
Illustrative test plan, using documentation-only addresses:
- A server connects from 192.0.2.10 and introduces itself as
relay.example.com. - The hostname publishes
v=spf1 ip4:192.0.2.10 -all. - For a message with
MAIL FROM:<>, SPF derivespostmaster@relay.example.comas the MAIL FROM identity. That source is authorised by the hostname policy. - Repeat using a different, unauthorised test IP. With the same hostname policy, the unmatched source reaches fail.
These are expected evaluator outcomes, not results from a live system. Use controlled, authorised recipients for real notification tests. Do not provoke bounces toward arbitrary external addresses merely to observe behaviour.
Record the identity as well as the verdict
Retain the session's connecting IP, HELO value, reverse path and receiver-generated result. A generic “SPF pass” without an identity is insufficient for troubleshooting. A successful ordinary user message does not prove that null reverse-path mail exercised the same domain.
When a test fails, decide whether the problem is the announced hostname, DNS publication, egress inventory or an unexpected route. Changing the employee domain's SPF policy will not repair a hostname policy that was never queried.
Make server-generated mail part of change control
Add notification tests to MTA upgrades, relay migrations and IPv6 enablement. Preserve the previous identity configuration and approved recovery path. Close the change only when ordinary mail and the server-generated flows relevant to your organisation have been assessed. This prevents a healthy user-mail test from concealing broken operational notifications.
Use the evidence for a decision
Keep ordinary MAIL FROM and null-path notification rows separate. For a null path and HELO=relay.example.com, the constructed sender is postmaster@relay.example.com; the test IP must be evaluated against that domain’s policy. An ordinary user-message pass for example.com does not establish that result. Use authorized recipients and controlled notifications; no bounce test or server change was executed.