What are the different terms for email From addresses?
Updated on 10 Aug 2026: We updated this guide for current DMARC terminology and clarified how Return-Path and null reverse-path handling work.
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, reverse-path, envelope From, 5321.From, or 821.From. After delivery, it is normally recorded in the Return-Path header. 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. DMARC calls its domain the Author Domain.
Keeping those two identities separate matters 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 gives DMARC its Author 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 reverse-path.
- Reply-To: A separate header that tells mail clients where normal human replies should go.
Quick reference
Use this table when a team has mixed terms in DNS tickets, sending platform 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 author and DMARC |
5321.From | Envelope From | SMTP | SPF and bounces |
MAIL FROM | Reverse-path | SMTP command | Envelope sender input |
Return-Path | Recorded reverse-path | Delivered header | Bounce route 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 | Transmitting 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 envelope sender appears during the SMTP conversation. The visible author appears inside the message data. At final delivery, the receiving system records the reverse-path in Return-Path and should remove any Return-Path supplied earlier. That sequence is why one message can have a bounce domain that differs from the visible From domain.
SMTP transaction and delivered headertext
SMTP transaction: 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 Delivered header added by the receiving system: 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. The delivered Return-Path is the receiver's record of the envelope reverse-path, not a second author address.
Email address field flow from MAIL FROM through Header From to delivered 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.
When MAIL FROM is empty
MAIL FROM does not always contain an email address. Delivery status notifications and other messages that must not generate another bounce use a null reverse-path. This prevents an error response from triggering a loop of further error responses.
Null reverse-path exampletext
EHLO mail.example.net MAIL FROM:<> RCPT TO:<sender@example.com> Delivered header: Return-Path: <>
- Meaning: Empty angle brackets mean there is no envelope sender mailbox.
- Return-Path: The delivered header can contain empty angle brackets for that null reverse-path.
- SPF identity: RFC 7208 defines the identity as postmaster at the HELO domain when the reverse-path is null.
- HELO or EHLO: This SMTP host identity affects SPF in the null case, but it is not another From header.
The two From addresses that matter most
Internal documentation should avoid saying only "From address" unless the context is obvious. Use RFC 5321.MailFrom for the SMTP envelope identity and RFC 5322.From for the visible author identity. Current DMARC terminology also calls the RFC 5322.From domain the Author Domain. That naming 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 when the reverse-path is not null.
- Bounce handling: Delivery failures return to this address.
- Common labels: Envelope From, MAIL FROM, reverse-path, bounce address, 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 calls this the Author Domain and compares it 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 authenticates the RFC 5321.MailFrom domain, while DMARC starts with the RFC 5322.From Author Domain. DKIM can pass with a signing domain that differs from both, but DMARC only uses that result when the DKIM signing domain has identifier alignment with the Author Domain under relaxed or strict alignment.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's product brings DMARC monitoring, SPF and DKIM results, source-level issue detection, alerts, and fix steps into one workflow. Teams can map each sending source's RFC 5321.MailFrom and DKIM domains against the Author Domain, then work through sources that fail alignment. Suped also includes hosted policy options and blocklist (blacklist) monitoring.
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 | Author Domain | Policy result |
MX | Inbound domain | Mail routing |
Where common authentication records belong.
For an operational check, start with the visible From domain because it supplies the DMARC Author Domain. Then inspect which authenticated domains passed SPF and DKIM. A domain health checker helps catch missing DMARC, SPF, and DKIM basics across the domain before investigating 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 the HELO domain when 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 clearest 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 reverse-path at final delivery.
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 the delivered 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 that mainly appears in legacy 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 Author 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.
RFC 5322 permits more than one author mailbox in a single From field. When it does, the message must include a Sender field identifying the transmitting agent. If the From mailboxes yield more than one domain, normal DMARC validation cannot extract one Author Domain under RFC 9989. Use one From mailbox for routine authenticated mail, and treat Sender as a separate originator field rather than another envelope sender.
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 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 Author Domain.
- Find Return-Path: Read the delivered Return-Path as the final record of the envelope reverse-path, including an empty value when present.
- Check SPF: Confirm which MAIL FROM or HELO domain SPF evaluated and whether the sending IP was allowed.
- Check DKIM: Record the signing domain and whether that domain aligns with the Author Domain.
- Check DMARC: Confirm that SPF or DKIM passed with an authenticated domain aligned to the Author Domain.
For recurring monitoring, Suped's product groups authenticated and unauthenticated sources by domain, flags broken records, sends alerts, and provides fix steps. Source-level analysis matters when multiple platforms send mail for the same Author Domain.
Document From address practices beside the technical terms. Naming the fields correctly fixes the technical side, while sender consistency supports 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
Which From term to use
Use RFC 5321.MailFrom when talking about the envelope sender, bounce handling, SPF, reverse-path, 821.From, or 5321.From. Use RFC 5322.From when talking about the visible sender, Header From, Author Domain, author address, 822.From, or 5322.From. Treat Return-Path as the delivered record of the reverse-path. Reply-To, Sender, DKIM, MX, and HELO are related but separate terms.
For day-to-day work, write the protocol term first and the familiar term in parentheses. Use RFC 5322.From (Header From) for the visible brand address and RFC 5321.MailFrom (envelope sender) for the bounce address. That naming habit prevents the wrong DNS record from being changed.
