Most people think of an email as one thing: a message with a “From” line at the top, a “To” line right under it, a subject, and a body. Type, click send, done. That mentality works fine when everything is going right.
It falls apart the moment you open a log file.
If you administer an MDaemon Email Server, sooner or later you are going to stare at an SMTP session log, a content filter trace, or a bounce report and wonder why the address you see in the message has nothing to do with the address that actually received the mail. The answer almost always comes down to one concept: email has two completely separate sets of addressing information, and they don’t have to agree.
Understanding the difference between the SMTP envelope (the MAIL FROM and RCPT TO commands exchanged during the SMTP session) and the message headers (the From:, To:, and Cc: lines inside the message itself) is one of the most important skills an email administrator can develop. It will save you hours of misdirected troubleshooting on filtering, deliverability, mailing lists, BCC behavior, and bounce handling.
Let’s break it down.
The Postal Analogy
The easiest way to think about it is to picture a physical letter being mailed.
When you put a letter in the mail, there are really two layers of addressing:
- The envelope. This is what the postal service uses to actually route the letter. The carrier never opens the envelope to read the letterhead inside; they look only at what’s written on the outside.
- The letter inside. The letter might begin “Dear Mom,” and end “Love, Sarah.” That’s the human-readable salutation. It’s there for the reader, not the post office.
These can disagree. You can mail a letter that begins “Dear Mom” but is actually addressed on the envelope to your sister’s apartment so she can hand-deliver it. The post office doesn’t care what the letter says inside. It cares about the envelope.
SMTP works exactly the same way.
Figure 1. The envelope (SMTP commands) and the letter (message headers) live on top of each other but mean different things.
What the Envelope Actually Is
When one mail server delivers a message to another, it doesn’t just hand over a file. It opens an SMTP session and exchanges a series of commands. Two of those commands are what we call the envelope:
- MAIL FROM:<sender@example.com> — the envelope sender, also called the “return-path.” This is where bounces and non-delivery reports go.
- RCPT TO:<recipient@example.org> — the envelope recipient. This is the address the receiving server will actually deliver the message to.
There can be multiple RCPT TO commands in a single SMTP session — one per recipient. Once those commands are accepted, the sending server issues the DATA command and transmits the actual message: headers and body together as one blob of text.
The envelope is what the SMTP servers care about. It’s how the mail gets delivered. And it is not stored as part of the message unless the receiving server chooses to record it.
What the Message Headers Are
The message headers are everything inside the DATA portion of the SMTP transmission, above the blank line that separates the headers from the body. These include:
- From: — the human-readable author of the message
- To: — the displayed recipient
- Cc: — visible copy recipients
- Subject:, Date:, Message-ID:, and so on
One thing to keep in mind: the message headers are written by the sending mail client, and the receiving server has no obligation to verify that they match the SMTP envelope at all. A message can say To: board@example.com in its To: header but actually be delivered to fifty different RCPT TO addresses in the SMTP session. That’s not a bug. That’s how BCC works. That’s how mailing lists work. That’s how aliases work.
Why They Often Disagree
Once you understand that the envelope and the headers are independent, a whole category of “weird” email behavior suddenly makes sense.
Figure 2. A complete SMTP delivery. The envelope rows determine routing; the message block is what the user reads.
Mailing lists. When someone sends a message to staff@yourcompany.com and that’s an MDaemon mailing list with thirty members, MDaemon generates a separate copy for each member. Each of those copies has the individual member’s address in the RCPT TO envelope, but the visible To: header still says staff@yourcompany.com. The recipient sees the list. The SMTP envelope shows the actual mailbox.
BCC (blind carbon copy). A BCC recipient is, by definition, not listed in any visible header. The sender’s mail client puts the BCC address in RCPT TO only. From the message body, there is no way to tell who was BCC’d. This is why content filter rules that look only at the To: and Cc: headers will miss BCC recipients entirely.
Aliases and forwarders. A message addressed to info@yourcompany.com may be aliased to jane@yourcompany.com on your server. The envelope RCPT TO becomes jane@, but the To: header in the original message still reads info@.
Bounces and Variable Envelope Return Path (VERP). Bounces follow the envelope sender (MAIL FROM), not the visible From: header. Mailing list software often uses a different MAIL FROM than the visible From: so that bounces are routed back to the list manager rather than to the original author.
Authentication. SPF checks the envelope MAIL FROM. DMARC alignment, on the other hand, compares the From: header domain to the SPF or DKIM result. If you don’t know which address is being checked, you will misdiagnose authentication failures.
How MDaemon Surfaces the Envelope for You
This is where MDaemon does you a favor that not every mail server does. Because the SMTP envelope is conversational metadata that gets discarded after the session ends, MDaemon explicitly preserves it by writing trace headers into the message file. When you open a .msg file from the queue, you’ll typically see headers like these added by MDaemon:
- X-Envelope-From: — the sending server’s MAIL FROM value
- X-Rcpt-To: and X-MDRcpt-To: — the RCPT TO value as MDaemon received it
- X-MDaemon-Deliver-To: — the specific local mailbox the message is being delivered to (especially useful after aliases, forwarders, and list expansion have resolved)
- X-MDArrival-Date: and X-MDRemoteIP: — when and from where the message arrived
These headers are extremely useful for troubleshooting. They are the only way to see the SMTP-level reality of a message after the fact.
Troubleshooting Scenarios Where This Matters
Here are some real situations where confusing the envelope with the headers will lead you in the wrong direction.
Scenario 1: A content filter rule isn’t catching mailing list traffic
This one comes up often. An admin wants to filter every message sent to announcements@company.com. They write a content filter rule that matches when the To: header contains the list address. It works for some messages but mysteriously misses others.
Figure 3. After list expansion, every copy carries the same To: header but a different RCPT TO envelope.
What’s happening? The misses are almost always BCC’d messages or messages where the list was reached through an alias. The visible To: header doesn’t contain the list address — the address only existed in the RCPT TO envelope. The fix is to match against an MDaemon-generated header like X-MDaemon-Deliver-To or X-MDMailing-List, depending on whether the content filter is processing the message before or after MDaemon “cracks” the list into individual copies. The Mailing List Manager setting “Apply content & spam filters to list mail before cracking individual copies” controls which headers are available at filter time, and it’s the source of more confused tickets than almost anything else in this area. If that option is enabled, the per-recipient headers haven’t been added yet — your rule has to look at envelope-style information instead.
Scenario 2: A user complains that they got a message they shouldn’t have
A user forwards you an email and says, “Why did this come to me? I’m not in the To or Cc field.” The envelope is the answer. They were either BCC’d, hit by an alias, or are a member of a list that was the actual recipient. Look at X-MDaemon-Deliver-To and X-Rcpt-To in the raw message source. If those show their address but the visible headers don’t, you’ve found your explanation in two seconds instead of two hours.
Scenario 3: Bounces are going somewhere unexpected
A user is sending newsletters and reports that bounces aren’t coming back to them. They check the From: header — it’s their address. They expect bounces there. Bounces don’t follow the From: header. Bounces follow the SMTP MAIL FROM envelope sender, which is also written into the Return-Path: header by the final receiving server. If their mail client or sending application is setting a different MAIL FROM, bounces will go there instead.
Scenario 4: SPF passes but DMARC fails (or vice versa)
This is the classic alignment problem. SPF authenticates the envelope MAIL FROM domain. DMARC requires the authenticated domain to “align” with the visible From: header domain. If a third-party sender is using their own domain in MAIL FROM but your domain in From:, SPF can pass while DMARC still fails — because the two addresses don’t agree. Knowing which header each protocol checks is the key strategy for diagnosing these failures.
Scenario 5: A spoofed-looking message that “passed” your filters
A phishing message arrives where the From: header displays a trusted name, but the SMTP envelope MAIL FROM is a throwaway domain at some far-flung host. The message technically authenticated against the envelope domain. The right defense is to enforce DMARC, which ties the two together, and to use MDaemon’s IP Shielding with the “Check FROM header address against IP Shield” option, which compares the visible From: to the connecting IP. Without understanding that the envelope and the header are different, none of those controls make sense.
The Bottom Line for Administrators
When you’re troubleshooting an MDaemon delivery issue, train yourself to ask two separate questions:
- What does the SMTP session say? Look at the SMTP logs and the X- headers MDaemon adds. That’s the envelope.
- What does the message say about itself? Look at From:, To:, Cc:, Return-Path:, etc. That’s the letter.
When those two stories line up, mail is straightforward. When they disagree — and they often will — that disagreement is usually exactly where the answer is hiding.
The envelope tells you how the mail moved. The headers tell you what the message claims about itself. An effective admin reads both, and never assumes one is a substitute for the other.
