22 June 2026 · 5 min read
Every email carries two sender addresses. The header From is the From: line your recipient sees. The envelope From is the address given in the SMTP MAIL FROM command, where bounces go, and it appears in the delivered message as the Return-Path: header. SPF checks the envelope From. DMARC protects the header From, and only counts SPF when the two domains align.
| Envelope From | Header From | |
|---|---|---|
| Also called | MAIL FROM, Return-Path, bounce address, RFC5321.MailFrom | From header, visible From, RFC5322.From |
| Defined in | RFC 5321 (SMTP) | RFC 5322 (message format) |
| Set when | During the SMTP conversation, before the message is sent | Inside the message itself |
| Seen by the recipient | Only in the raw headers, as Return-Path: | Yes, in every mail client |
| Used for | Bounces, and SPF | Display, and DMARC |
The envelope From
The envelope From is given during the SMTP conversation, before any message content is transferred:
MAIL FROM:<bounces@mailer.example.com>
RCPT TO:<alice@example.net>
DATA
From: Example News <news@example.com>
...Its job is to receive bounces. If a recipient address does not exist, the receiving server sends the non-delivery report back to the envelope From. That is why sending platforms usually set it to their own bounce address: it feeds their bounce processing and list cleaning. When the message is finally delivered, the receiving server records the envelope From in a Return-Path: header at the top of the message (RFC 5321, section 4.4).
SPF checks this address. The receiver takes the domain from MAIL FROM and asks whether the connecting IP address is allowed to send for it. Bounce messages have an empty MAIL FROM; in that case RFC 7208 uses postmaster@ plus the domain the server gave in its HELO. SPF never looks at the From: header.
The header From
The header From is the From: line inside the message:
From: Example Billing <billing@example.com>Example Billing is the display name and billing@example.com is the address. The domain of that address is what DMARC protects, because it is what people read when they decide whether to trust a message. DMARC looks up its policy from this domain and asks whether SPF or DKIM passed for a domain that aligns with it.
DMARC cannot stop a misleading display name on someone else's domain, such as Example Billing <billing@another-domain.example>. Your domain never appears in that address, so your DMARC policy is never consulted.
Why the two addresses can differ
SMTP has always separated the envelope from the message so that mailing lists, gateways and forwarders can redirect bounces without touching what the reader sees. A mailing list, for example, keeps your From: header but uses its own bounce address as the envelope From. The same freedom lets an attacker put your domain in the visible From: while using any envelope From they like. SPF, DKIM and DMARC were added to close that gap.
Alignment: where the two meet
DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the header From domain:
- SPF alignment compares the envelope From domain with the header From domain.
- DKIM alignment compares the
d=domain in the DKIM signature with the header From domain.
In the default relaxed mode, the two domains only need to share an organisational domain, so an envelope From of bounce.example.com aligns with a header From of example.com. Strict mode (aspf=s or adkim=s) requires an exact match. The current standard, RFC 9989, finds the organisational domain with a DNS tree walk over DMARC records instead of the Public Suffix List used by the older RFC 7489.
A worked example
A newsletter sent through a platform that has not been set up for alignment:
Return-Path: <bounce@platform-mail.example>
From: Example News <news@example.com>
DKIM-Signature: v=1; d=platform-mail.example; s=k1; ...- SPF passes for
platform-mail.example, which does not align withexample.com. - DKIM passes for
platform-mail.example, which does not align either. - DMARC fails, although both checks passed.
Now the same message after DKIM is set up with your domain:
Return-Path: <bounce@platform-mail.example>
From: Example News <news@example.com>
DKIM-Signature: v=1; d=example.com; s=em1; ...The envelope From still belongs to the platform, but DKIM now aligns, so DMARC passes. The other fix is a custom Return-Path such as bounce.example.com, which makes SPF align as well. Why DMARC fails when SPF and DKIM pass walks through both.
Forwarding changes the envelope, not the header
When a message is forwarded, the forwarding server sends it from its own IP address. If it keeps your envelope From, SPF fails because that IP is not in your SPF record. If it rewrites the envelope From to its own domain, SPF can pass, but for the forwarder's domain, which does not align. Either way SPF alignment is lost. The From: header and a DKIM signature over it survive, as long as the forwarder does not change the signed headers or body. That is why aligned DKIM matters more than aligned SPF. Why forwarding breaks authentication covers this in detail.
How to see both addresses in a real message
Open the original message source (in Gmail, Show original) and look for:
Return-Path:near the top: the envelope From that SPF checked.From:: the header From that DMARC protects.Authentication-Results:: the receiver's verdicts.smtp.mailfrom=shows the envelope domain SPF used,header.d=orheader.i=shows the DKIM domain, andheader.from=shows the domain DMARC judged.
A Return-Path: on a different domain from From: is normal for mail sent through a platform. What matters is that at least one of SPF or DKIM aligns. The email header analyser lays these fields out for you, and the DMARC checker shows the policy and alignment mode your domain publishes. If you want every source's alignment tracked across your aggregate reports, DMARC analytics breaks them down by sender.