Email carries two sender identities. The envelope sender, set by MAIL FROM, controls routing of bounces. The From header is part of the message content and is what people see. They can differ legitimately, such as with mailing lists, and SMTP itself does not verify either one.
Two layers
RFC 5321 splits an SMTP transfer into the envelope and the content. The envelope is the MAIL FROM (reverse-path), the RCPT TO (forward-path) and any parameters. Transport uses only the envelope. The content is what follows DATA: a header section and a body. Fields like From and To live in the content.
The RFC shows how they diverge. When a list expands a message, the envelope sender changes, but the header section must be left unchanged, and in particular the From field is unaffected. Error reports go to the reverse-path, not to a From or Sender header.
MAIL FROM and RCPT TO
MAIL FROM starts a transaction and names where error reports go. RCPT TO names one recipient and can repeat, with each accepted recipient answered by a 250. A recipient that cannot be delivered usually gets a 550.
Bounces and the null reverse path
If a relay accepts a message and later cannot deliver it, it must send an undeliverable notice to the reverse-path. To prevent loops, that notice is sent with a null reverse-path, written as an empty MAIL FROM. Servers must never send notices about problems with notices.
Store and forward relays
A relay is typically the target of an MX record. If it accepts a message, it becomes an SMTP client and forwards to the next hop. After it sends its success reply at the end of the data, it has taken responsibility for delivering the message or reporting failure. A relay should not alter the header or body, other than adding its Received field and optionally checking for loops.
What this means for security
- SMTP does not authenticate senders. The RFC says methods of verifying return paths are not defined there, and it points to SPF and DKIM as separate work. A sender address cannot be trusted just because it appears.
- Authentication checks different identities. SPF looks at the envelope domain. DKIM signs with its own domain. DMARC then asks whether either aligns with the visible From domain. See what SPF, DKIM and DMARC each prove.
- Forwarding and lists break SPF. The envelope changes in transit. Read email forwarding breaks SPF and DKIM, and what ARC adds.
- Relay abuse. Servers may refuse to relay, and a policy refusal should return 550. Restricted clients must not assume any server on the internet can relay for them.
- Address probing. VRFY and EXPN can reveal addresses, so administrators may disable them.
Practical tips
- When investigating a suspicious email, compare the envelope sender in the Return-Path with the visible From.
- Configure DMARC so mail with an unaligned From domain is treated as suspicious.
- Expect legitimate mismatches from lists and third party senders, and inventory them.
- Do not rely on the display name or the From address alone for trust decisions.
Where Safeguard fits
Safeguard does not run mail systems. It scans dependencies and SBOMs for known vulnerabilities, including in mail libraries your software uses. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Where do bounce messages go?
To the envelope reverse-path from MAIL FROM, not to the From or Sender header.
Why is the bounce sent with a null reverse path?
To prevent error loops, since servers must not send notices about problems with notices.
Sources
Last reviewed: 19 October 2026.
