Anatomy of an email: envelope, headers, and body

Every email has two "from" addresses, and they are routinely different. One lives on the envelope and is read by servers; your reader never sees it. The other lives in the message and is what appears in the inbox; servers treat it as a claim, not a fact. Nearly everything in email authentication comes down to checking whether those two identities, plus the signatures attached to them, deserve trust. If you learn one thing in this module, learn to keep them apart.

The envelope and the letter

Postal mail got this right first, so let's use it properly. A paper letter has an envelope with a delivery address and a return address. The post office reads only the envelope. Inside is the letter, with a letterhead, a date, a salutation, a signature. Nothing stops you writing "From the desk of the Prime Minister" on the letterhead while the envelope's return address says your flat in Riga. The postal service doesn't check; it just carries.

Email inherited exactly this structure. In the previous lesson you watched the SMTP conversation: MAIL FROM and RCPT TO came first, and the actual message followed only after the DATA command. Those first two commands are the envelope. The stuff after DATA is the letter. The receiving server routes and accepts mail based on the envelope; your reader sees only the letter.

The two layers even have separate rulebooks. The envelope and the transfer conversation are defined in RFC 5321; the internal format of the message is defined in RFC 5322. Deliverability people lean on those numbers constantly, because they give unambiguous names to the two froms.

The three froms

RFC5321.MailFrom is the envelope sender: the address given in the MAIL FROM command. Its job is operational. It answers one question: where should failure notices (bounces) go? When the receiving server delivers the message, it records this address into a header called Return-Path, which is how you can see the envelope sender afterward when reading a delivered message's raw source. Same identity, two names: MAIL FROM during transport, Return-Path at rest.

RFC5322.From is the header inside the letter, the line that starts From:. This is the display identity, the name and address your reader sees. Nothing in the base protocol verifies it. As far as RFC 5322 is concerned, it's letterhead.

Reply-To is the optional third. When present, it tells the reader's mail client where to direct a reply, overriding the From address for that one purpose. Newsletters use it so replies reach a monitored mailbox.

The part that surprises people: for most ESP-sent mail, the envelope sender usually isn't your address. Often it isn't even on your domain. ESPs typically set MAIL FROM to an address on a domain they control, so bounces flow back into their systems for automatic list cleanup. Mailchimp, for one, sends with its own envelope domain and never asks customers to touch SPF, per its own setup documentation. So a Mailchimp campaign might carry an envelope address on a Mailchimp-operated bounce domain while the From: your reader sees is you@yourdomain.com. Two froms, two domains, one legitimate email.

That split is legitimate, but it's also precisely the mechanism spoofing exploits: a spammer can put any address they like in the visible From:. The entire authentication module ahead of you exists because of this. SPF, which you'll meet in its own lesson, validates the envelope domain (the RFC5321.MailFrom). DMARC then asks whether whatever passed actually matches the visible From domain. If you blur the two froms in your head, none of that machinery will make sense; keep them separate and all of it will.

The header block

Open any message in your mailbox and find "show original" or "view source" (every major provider has it, tucked in the message's overflow menu). Above the readable content sits a block of headers: named lines, one per fact. A trimmed real-world shape:

Return-Path: <bounce-77.abc@mail.esp-bounces.com>
Received: from mail.esp-bounces.com (mail.esp-bounces.com [192.0.2.10])
        by mx.example-mail.com with ESMTPS; Sat, 18 Jul 2026 09:14:02 -0700
Received: from app-7.internal ([10.1.4.22])
        by mail.esp-bounces.com; Sat, 18 Jul 2026 09:14:01 -0700
From: "Your Newsletter" <you@yourdomain.com>
Reply-To: hello@yourdomain.com
To: reader@example-mail.com
Subject: This week's issue
Date: Sat, 18 Jul 2026 09:14:00 -0700
Message-ID: <20260718161400.7f3a@mail.esp-bounces.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b42"

The ones worth knowing now:

The Received chain is the message's passport stamps. Every server that handles the message adds one at the top, so you read them bottom-up to trace the route: origin first, final delivery last. Because each server writes its own stamp, the topmost stamps (written by the receiver) are trustworthy and the bottom ones are only as honest as the servers that wrote them. There's a whole lesson on reading headers like a professional later in the course; for now, just know the trail exists.

Message-ID is a globally unique identifier for this one message, minted by the sending system. Threading and duplicate detection both hang off it, and abuse investigators lean on it. A missing or malformed Message-ID is the kind of sloppiness spam filters notice, because well-run sending software never omits it.

Date is when the message claims it was written. Claims, again: the sender's software sets it. A Date hours in the future or years in the past is another sloppiness signal.

Subject you know. It's a header like any other, which is worth internalizing: the subject line is data inside the letter, with no special protocol status.

Our path checks read exactly this block from emails sent to a test address, and one pattern shows up often enough to mention: senders who have never once looked at their own Return-Path. They discover, from a header dump, that their bounce domain is some ESP subdomain they've never heard of, and that it has a reputation and a health of its own. The checks reference covers why we grade that bounce domain as a full domain in its own right.

One message, two bodies

Below the headers comes the body, and modern email bodies are almost never a single blob. They use MIME (Multipurpose Internet Mail Extensions, RFC 2045), which lets one message carry multiple parts with labeled types.

The everyday case is multipart/alternative: the same content twice, once as text/plain and once as text/html. The reader's client picks the richest version it can display, which in practice means nearly everyone sees the HTML. The plain-text part still matters. Some clients and some previews use it, accessibility tooling uses it, and a message that is HTML-only, or whose text part is empty or wildly different from the HTML, looks more like spam than one with a faithful text twin. Every serious ESP generates the pair automatically; trouble usually enters when custom-built sending code skips the plain part.

Attachments and inline images extend the same mechanism (multipart/mixed, multipart/related), each part with its own declared type. Nothing more is needed on that here; the point is that "an email" is a structured document with an envelope around it, and each layer is inspected by different machinery.

Why the split exists

The envelope/letter split isn't an accident of history to be cleaned up; it's what makes several ordinary things possible. Bounces have somewhere to go that isn't the author's inbox (imagine a 100,000-subscriber send where every dead address bounced into your personal mailbox). A mailing list can accept a message from one author and re-mail it to thousands of recipients under its own envelope while the author's From: stays intact. An assistant can send on an executive's behalf. An ESP can shoulder the operational mess of failure handling on its own domain while your brand stays on the letterhead.

The cost of that flexibility is that the visible From: is unverified by design, and the fix, bolted on decades later, is the authentication stack: SPF for the envelope domain, DKIM for a signature that travels with the letter, DMARC to tie both back to the From your reader sees. You now know the two identities those systems argue about. That was the hard part. Both of those identities, and the records that will eventually vouch for them, live in DNS, so that is where we go next: the public address book your whole setup depends on.

Terms from this lesson

• envelope - the transport-level addressing from the SMTP conversation (MAIL FROM, RCPT TO), read by servers and invisible to readers.
• RFC5321.MailFrom - the envelope sender address; where bounces go. Recorded as Return-Path on delivery.
• Return-Path - the header the receiving server writes at delivery, preserving the envelope sender of the message.
• RFC5322.From - the From: header inside the message; the identity readers see, unverified by the base protocol.
• Reply-To - an optional header directing replies to a different address than the visible From.
• Received header - a routing stamp each handling server adds at the top of the headers; read bottom-up to trace a message's path.
• Message-ID - a globally unique identifier the sending system assigns to each message.
• MIME - the standard (RFC 2045) letting one message carry multiple typed parts, such as attachments and alternative bodies.
• multipart/alternative - the MIME structure carrying the same content as both plain text and HTML, with the client displaying the best it supports.

Check yourself

1. Where does the Return-Path header come from?

The sender types it into their mail clientIt is a copy of the Reply-To headerDNS publishes it alongside the MX recordsThe receiving server records the envelope MAIL FROM address there at delivery

2. A reader hits reply on a newsletter. Which address does their mail client use, if all three are present?

The Reply-To addressThe Return-Path addressThe RFC5322.From addressThe address in the last Received header

3. Why can a completely legitimate Mailchimp campaign show an envelope domain that isn't yours?

It means the campaign was spoofedDNS rewrote the address during the MX lookupThe ESP uses its own bounce domain so failure notices flow into its systemsThe recipient's server replaced it with a tracking address

4. In what order do you read the Received headers to follow a message's route from origin to inbox?

Top to bottom, since the first server writes the first headerBottom to top, since each server adds its stamp above the previous onesAlphabetically by server nameOrder doesn't matter; they are written all at once