What are the different terms for email From addresses?
Michael Ko
Co-founder & CEO, Suped
Published 10 Jul 2025
Updated 4 Jun 2026
8 min read
Summarize with
The different terms for email From addresses usually refer to two separate identities: the SMTP envelope sender and the visible message author. The envelope sender is the RFC 5321.MailFrom address, also called the MAIL FROM, bounce address, Return-Path, reverse-path, envelope From, 5321.From, or 821.From. The visible author is the RFC 5322.From address, also called the Header From, From header, author address, 5322.From, 822.From, or friendly From when people mean the display name plus address.
I keep those two terms separate because they answer different questions. RFC 5321.MailFrom tells receiving mail servers where bounces go and which domain SPF checks. RFC 5322.From tells the recipient who the message claims to be from and which domain DMARC uses as the visible domain. A normal email address has a local part, an at sign, and a domain, but email authentication cares about which field that address appears in.
- Envelope sender: The SMTP-level address passed in the MAIL FROM command, used for bounces and SPF.
- Header From: The visible author address in the message header, used by recipients and DMARC.
- Return-Path: The delivered trace header that records the final envelope sender.
- Reply-To: A separate header that tells mail clients where normal human replies should go.
Quick reference
The table below is the reference I use when a team has mixed terms in DNS tickets, ESP setup screens, authentication reports, and header analysis. Some terms are strict protocol terms. Others are vendor shorthand or older RFC shorthand that still appears in logs and technical discussions.
|
|
|
|
|---|---|---|---|
5322.From | Header From | Message | Visible sender |
5321.From | Envelope From | SMTP | SPF and bounces |
MAIL FROM | Reverse-path | SMTP | Bounce route |
Return-Path | Bounce address | Header | Delivery trace |
821.From | Old envelope | Legacy docs | Same as 5321 |
822.From | Old header | Legacy docs | Same as 5322 |
From name | Display name | Message | Recipient label |
Reply-To | Reply address | Message | Human replies |
Sender | On-behalf sender | Message | Sending agent |
Core From-address terms and their practical meaning.
Do not treat every address as a From address
DKIM has its own signing domain in the DKIM-Signature header, usually shown as the d= value. MX records are DNS routing records that tell a sender which mail server accepts mail for a domain. Neither one is a From address, even though both matter when diagnosing authentication.
How the terms map to a message
A single email can carry several addresses before it reaches the inbox. The first appears during the SMTP conversation. The second appears inside the message data. The receiving system can add Return-Path after final delivery. That sequence is why one message can have a bounce domain that differs from the visible From domain.
SMTP and header exampletext
MAIL FROM:<bounce-123@bounce.example.net> RCPT TO:<person@example.org> DATA From: "Acme Billing" <billing@example.com> Reply-To: support@example.com Sender: campaigns@example.net Return-Path: <bounce-123@bounce.example.net>
In that example, the envelope sender is bounce-123@bounce.example.net. The visible From address is billing@example.com, and the visible From name is Acme Billing. If the recipient clicks reply, the reply goes to support@example.com in most mail clients because Reply-To is present.
Flowchart showing MAIL FROM, message data, Header From, and Return-Path.
This difference also explains why people get confused by two domains in a header view. One domain can belong to the sending infrastructure, while the other belongs to the brand or application shown to the reader.
The two From addresses that matter most
When I write internal documentation, I avoid saying just "From address" unless the context is obvious. I write RFC 5321.MailFrom for the SMTP envelope identity and RFC 5322.From for the visible author identity. That habit removes most confusion in authentication tickets.
RFC 5321.MailFrom
This is the SMTP envelope sender. It is transmitted before the message body. The recipient usually does not see it in the inbox UI.
- SPF check: SPF checks the domain in this address.
- Bounce handling: Delivery failures return to this address.
- Common labels: Envelope From, MAIL FROM, Return-Path, 5321.From, 821.From.
RFC 5322.From
This is the author address in the message header. It is the address the recipient usually sees beside the From name.
- DMARC domain: DMARC compares this domain with authenticated SPF or DKIM domains.
- Brand display: The inbox UI normally shows this address or its display name.
- Common labels: Header From, From header, author address, 5322.From, 822.From.
The most important rule is simple: SPF belongs to the RFC 5321.MailFrom domain, while DMARC starts with the RFC 5322.From domain. DKIM can pass with a signing domain that differs from both, but DMARC only treats it as useful when the signing domain matches the visible From domain under the domain-matching mode in the DMARC record.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product is the best overall DMARC platform for most teams that need to turn these terms into operations. It brings together DMARC monitoring, SPF and DKIM checks, Hosted SPF, Hosted DMARC, Hosted MTA-STS, real-time alerts, automated issue detection, fix steps, and blocklist (blacklist) monitoring in one workflow.
DNS records connected to each name
DNS does not define the From address itself. DNS defines policies and keys on the domains used by those addresses. That distinction matters when a ticket says "fix From DNS". The right record depends on whether the issue concerns SPF, DKIM, DMARC, MX routing, or a bounce subdomain.
|
|
|
|---|---|---|
SPF | 5321 domain | MAIL FROM pass |
DKIM | Signing domain | Signature pass |
DMARC | 5322 domain | Policy result |
MX | Inbound domain | Mail routing |
Where common authentication records belong.
For an operational check, I start with the visible From domain because that is the DMARC domain. Then I inspect which authenticated domains passed SPF and DKIM. A domain health checker helps catch missing DMARC, SPF, and DKIM basics across the domain before I chase source-specific details.
DMARC record exampletext
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:reports@example.com" )
That record belongs under the visible From domain, not the bounce domain, unless the visible From domain is the bounce domain. SPF is different: an SPF checker should inspect the domain used in RFC 5321.MailFrom, and sometimes the HELO domain if the MAIL FROM is empty.
Terms that cause the most mistakes
Most confusion comes from using a delivery term as if it were a visible identity term. Return-Path is the best example. People see it in the delivered header and assume it is the same kind of header as From. It is not. Return-Path records the envelope sender after delivery.
My naming rule
Use protocol names when debugging authentication. Use user-facing names when discussing brand display. Mixing those two modes creates bad fixes, such as changing the visible From address when the real issue is an SPF record on the bounce domain.
- Friendly From: Usually means the display name and visible address together, not the envelope sender.
- Bounce domain: Usually means the domain in RFC 5321.MailFrom or Return-Path.
- P1 sender: Another way to refer to the envelope sender in some gateway and compliance tools.
- P2 sender: Another way to refer to the visible Header From identity.
- PRA: An older Sender ID term. I only use it when reading old documentation.
Reply-To also gets pulled into From-address debates, but it is a separate instruction to the mail client. It does not decide SPF, and it is not the DMARC domain. It affects where human replies go. If the From and Reply-To domains differ, document that choice clearly because it changes support workflows and reader trust.
How to verify the terms in a real message
The fastest practical check is to send a real message, open the full headers, and label each address before changing DNS. Use Suped's email tester when you want to inspect the message as delivered and separate the visible From, Return-Path, SPF result, DKIM result, and DMARC result.
- Find Header From: Read the From header in the message data and note its domain.
- Find Return-Path: Read the delivered Return-Path header and treat it as the envelope sender.
- Check SPF: Confirm which domain SPF evaluated and whether the sending IP was allowed.
- Check DKIM: Record the signing domain and whether that domain matches the visible From domain.
- Check DMARC: Confirm that SPF or DKIM passed with a domain that matches the Header From domain.
For recurring monitoring, I want this analysis at the source level, not as a one-off header read. Suped groups authenticated and unauthenticated sources by domain, flags broken records, sends real-time alerts, and gives fix steps. That matters when multiple platforms send mail for the same visible From domain.
I also document From address practices beside the technical terms. Naming the fields correctly fixes the technical side, but sender consistency fixes the human side.
Views from the trenches
Best practices
Label RFC 5321.MailFrom and RFC 5322.From separately in tickets and team runbooks.
Keep DNS notes tied to the domain that actually owns each authentication record.
Use header examples when teaching the difference between visible and envelope senders.
Common pitfalls
Treating Return-Path as the same field as Header From leads to wrong SPF record fixes.
Putting MX beside From headers makes routing and authentication look like one topic.
Calling DKIM a From field hides the fact that it lives in its own signature header.
Expert tips
Use 821.From and 822.From only when the audience already knows the older RFC terms.
Document bounce domains beside SPF ownership so support teams know who can fix them.
Show P1 and P2 labels only when gateway logs or compliance tools use those names.
Marketer from Email Geeks says DKIM belongs in its own signature header and should not be described as one of the From fields.
2018-11-09 - Email Geeks
Marketer from Email Geeks says MX is mostly outside the header discussion because it tells senders which server accepts SMTP traffic.
2018-11-09 - Email Geeks
The practical takeaway
Use RFC 5321.MailFrom when talking about the envelope sender, bounce handling, SPF, Return-Path, 821.From, or 5321.From. Use RFC 5322.From when talking about the visible sender, Header From, author address, 822.From, or 5322.From. Treat Reply-To, Sender, DKIM, MX, and HELO as related but separate terms.
For day-to-day work, I write the protocol term first and the friendly term in parentheses. For example, RFC 5322.From (Header From) for the visible brand address, and RFC 5321.MailFrom (envelope sender) for the bounce address. That small naming habit prevents the wrong DNS record from being changed.
