Pedro Paiva

Email learning series

Email envelopes and headers: why there is more than one sender

By Pedro Paiva

A welcome message can display hello@example.org while delivery failures go to bounces@example.org. This is normal: an email has delivery instructions outside the content the reader sees.

Two layers of addressing

The SMTP envelope consists of the return address sent with MAIL FROM and recipients sent with RCPT TO. The message itself has headers and a body. Headers are content carried inside that envelope; changing To does not independently change the SMTP delivery destination.

Compare these two views of one fictional message:

SMTP envelope                         Message inside DATA
MAIL FROM:<bounces@example.org>       From: Welcome <hello@example.org>
RCPT TO:<reader@example.net>          To: reader@example.net
RCPT TO:<audit@example.net>           Reply-To: support@example.org
                                      Subject: Welcome

                                      Your account is ready.

reader and audit receive delivery attempts because both are envelope recipients. The visible sender is hello, the ordinary reply destination is support, and a delivery failure normally goes to bounces. The audit address is deliberately absent from visible recipient headers in this Bcc-style example.

The headers To and Cc describe intended visible recipients. A mail client commonly constructs envelope recipients from its composer fields, which makes the layers look interchangeable. At the protocol level, they remain separate.

Replies are messages; failures use the return path

From identifies the message’s author. Reply-To, when present, supplies the address suggested for replies; otherwise a normal reply uses From. Reply-all behavior also considers recipient headers, and client rules vary. This does not guarantee where every client or human will send a reply.

When final delivery happens, the delivery system records the envelope reverse-path in a Return-Path header. For our example, a received copy might start with:

Return-Path: <bounces@example.org>
From: Welcome <hello@example.org>
Reply-To: support@example.org

An application adding its own Return-Path header cannot authoritatively set the SMTP envelope. Configure the provider’s actual return-path feature or SMTP MAIL FROM. Relays and final delivery systems have rules for handling preexisting Return-Path fields; inspect the received message, not just the pre-submission copy.

A failure notification is itself an email. SMTP uses a null reverse-path, MAIL FROM:<>, for delivery-status notifications so another failure doesn’t produce an endless chain of failure notifications. A final received DSN can therefore show Return-Path: <>. The null path is not the same thing as an empty visible From header.

What Bcc does and doesn’t hide

A common implementation removes the Bcc header and includes those addresses only in the envelope. RFC 5322 also permits variants, including separately generated copies and an empty Bcc field. Do not assume every recipient gets identical message bytes.

Bcc keeps addresses out of other recipients’ normal recipient headers. It doesn’t hide them from the sending service, transport logs, or the blind recipient who replies to everyone. Nor does a visible To prove the mailbox accepted the message.

To investigate a routing problem, ask three separate questions: what envelope was submitted, what headers reached the mailbox, and what action did the receiving system take? A screenshot of the sender name answers only part of the second question.

References