For a null reverse-path, SPF derives its MAIL FROM identity from HELO. A pass authenticates that identity; DMARC still requires it or a valid DKIM signer to align with the visible From domain.
A delivery status notification, or bounce, often arrives with an empty SMTP reverse-path: MAIL FROM:<>. That is deliberate. If a failure notice itself cannot be delivered, an empty reverse-path helps prevent another failure notice from bouncing back indefinitely. It also makes the authentication result easy to misread.
What SPF checks when MAIL FROM is empty
SPF normally evaluates the domain in the SMTP MAIL FROM address. For a null reverse-path, RFC 7208, section 2.4defines the SPF MAIL FROM identity as postmaster@ plus the sending server's HELO domain. In practice, a receiver can report SPF pass for a bounce whose HELO name is mx1.mailer.example. The pass says that this server is authorized to use that derived SPF identity. It says nothing by itself about the domain displayed in the message's From header.
Why DMARC can still fail
DMARC compares an authenticated identity with the RFC 5322 From domain. Under RFC 9989, section 4.4.2, its SPF path uses the SPF-validated MAIL FROM identity, including the derived identity for a null reverse-path. That domain must align with the visible From domain. An aligned, valid DKIM signature can satisfy DMARC independently.
SMTP MAIL FROM: <>
HELO: mx1.mailer.example
Header From: notices@example.org
SPF: pass for mx1.mailer.example
DMARC: fail via SPF (domains do not align)The example is a simplified diagnostic, not a verdict on whether the notification is malicious. A DKIM signature from example.org that verifies would give it a separate DMARC pass. Conversely, a HELO SPF pass alone does not make an unrelated visible From domain trustworthy.
How to investigate a failing bounce stream
- Confirm that the message really has a null SMTP reverse-path; do not infer it from the subject.
- Record the HELO name, connecting IP, visible From domain, SPF result, DKIM result, and DMARC result from the receiver's trusted authentication results.
- Check which identity SPF validated and whether its domain aligns with the visible From domain.
- If you operate the notification system, use a stable HELO name with an appropriate SPF record and choose a visible From domain that aligns, or sign with an aligned DKIM domain.
- Send a fresh controlled notification and inspect the receiver's actual results before changing DMARC policy.
Do not add a third-party server to your organization's SPF record merely because its notification shows your brand in the From header. First establish who owns the sending system and which domain it authenticates. If the bounce is generated by a receiver or a forwarding service you do not control, investigate its route before treating the failure as a broken sender configuration.
The useful reading of the report
An SPF pass and a DMARC fail can both be correct. SPF answers whether the connecting host is authorized for its SPF identity. DMARC asks whether that authenticated identity, or a valid DKIM signer, matches the author domain readers see. For bounces, the null path makes the HELO-derived identity especially important to inspect.
Disclosure: AI tools were used in the process of creating this blog post.