The envelope and the message

An email has two layers: the envelope and the message. They look related, and they often carry the same addresses. But they are separate data, and servers only route on the envelope.

Think of a paper letter. The post office reads the address on the envelope. It never opens the letter to check who signed it. Email works the same way.

Who creates each layer

SMTP commands create the envelope. MAIL FROM gives the return path, the address that gets bounces. Each RCPT TO names one recipient the server should deliver to.

The message comes later, after the DATA command. That’s where the fields you see in your mail app live: From, To, Subject, the body.

This split is what makes forwarding, mailing lists, and Bcc possible. It also tells you where to look when debugging. Delivery problems start with the envelope. “Why does it look like this?” problems start with the message headers.

The two layers side by side

Here I’m sending my newsletter. The envelope and the visible fields point to different places, on purpose:

C: MAIL FROM:<[email protected]>
C: RCPT TO:<[email protected]>
C: DATA
C: From: Flavio Copes <[email protected]>
C: To: [email protected]
C: Subject: New post: the envelope and the message
C:
C: The lesson is up.

The server delivers to [email protected]. Sara’s mail app shows [email protected] in From and [email protected] in To. Her address is nowhere in the message. That’s normal for a list or a blind copy.

If delivery fails, the bounce goes to [email protected], not to my personal inbox. That’s the whole point of a separate return path.

Notice one consequence: the visible From proves nothing about who actually submitted the message. Anyone can type any From. Authentication checks look elsewhere.

Where the envelope leaves a trace

After final delivery, the receiving system usually writes the envelope return path into a Return-Path header. Every server along the way also adds a Received header on top.

These fields are trace data. They record which envelope was used. They don’t change it, because the SMTP transaction is already over.

A common mistake

A developer reads From: [email protected] in a bounce report and concludes I sent the spam. But the envelope sender was someone else entirely. Always check Return-Path and the Received chain before blaming the From address.

Try this on a saved .eml file from your own inbox: find From, To, Return-Path, and the oldest Received line. Write down which values came from the message and which describe transport.