What are the different terms for email From addresses?
Updated on 17 Oct 2026: We clarified sender address terminology and added an Authentication-Results example for checking SPF, DKIM, and DMARC identities.
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, or 822.From. 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 for email From terms
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, P2 sender | Message | Visible author and DMARC |
5321.MailFrom | Envelope From, 5321.From, P1 sender | 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 | Legacy name for the envelope sender |
822.From | Old header | Legacy docs | Legacy name for Header From |
From name | Display name | Message | Recipient label |
Reply-To | Reply address | Message | Human replies |
Sender | Transmitting-agent address | 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 adds Return-Path using the reverse-path from MAIL FROM. RFC 5321 permits it to remove an existing Return-Path before adding its own. Forwarding or mailing-list processing can change the envelope sender, so the delivered Return-Path does not necessarily identify the original envelope sender. 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. The mailbox address itself is the addr-spec; the display name is optional. Sender identifies campaigns@example.net as the transmitting agent, without changing the bounce address or DMARC Author Domain. 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 fields showing SMTP MAIL FROM, RCPT TO, Header From, and 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 MAIL FROM identity as postmaster at the HELO domain when the reverse-path is null. In this example, that identity is postmaster@mail.example.net.
- HELO or EHLO: SPF can check this SMTP host identity separately even when MAIL FROM is not empty. With a null reverse-path, it also supplies the domain for the derived MAIL FROM identity.
The two From addresses that matter most
In internal documentation, specify RFC 5321.MailFrom (envelope sender) or RFC 5322.From (Header From) rather than an ambiguous "From address".
RFC 5321.MailFrom
This is the SMTP envelope sender. It is transmitted before the message headers and 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 the domain in this address 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. Relaxed alignment compares Organizational Domains; strict alignment requires identical domains. For example, bounce.example.com and example.com satisfy the relaxed comparison when their Organizational Domain is example.com, but fail the strict comparison. These rules are defined in RFC 9989.
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.
Which sender domain owns each DNS record
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 | MAIL FROM domain; HELO domain for a null reverse-path | TXT record at the identity's domain |
DKIM | Signing domain (d=) and selector (s=) | TXT lookup at selector._domainkey.signing-domain |
DMARC | Author Domain | TXT lookup at _dmarc.Author-Domain, with inherited policy where applicable |
MX | Domain receiving mail, including a bounce domain | Inbound mail and bounce routing |
DNS lookup names for authentication and inbound routing.
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 check domain-level DNS configuration. DKIM checks also need the selector from the message's DKIM-Signature header.
DMARC record exampletext
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none; " "rua=mailto:reports@example.com" )
For this example, publish _dmarc.example.com for From addresses at example.com. A subdomain without its own DMARC record can inherit a policy discovered higher in DNS. 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
Return-Path is a delivered trace header recording the envelope reverse-path. From identifies the message author. Confusing their roles leads to changes on the wrong domain.
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: An informal label used for the display name alone or the visible From field. Specify which meaning is intended; it is 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 (Purported Responsible Address): A legacy identity calculated by the deprecated Sender ID protocol. It is separate from DMARC's Author Domain.
Reply-To 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. Without Reply-To, replies normally go to the From address, as specified in RFC 5322. 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 Authentication-Results labels sender identities
A receiving server can record authentication outcomes in the Authentication-Results header. Its property names connect the visible From address to the SMTP identity and DKIM signing domain.
Authentication results with different envelope and author domainstext
Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=bounce.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
- smtp.mailfrom identifies the MAIL FROM identity checked by SPF, reported as a mailbox or domain.
- smtp.helo identifies the HELO/EHLO identity when reported.
- header.d identifies the DKIM signing domain.
- header.from identifies the visible From domain used by DMARC.
Here SPF passes for bounce.example.net, which does not match the Author Domain example.com. DMARC passes through DKIM because header.d and header.from are both example.com.
Use results added by the receiving system you trust. Authentication-Results supplied by an untrusted sender can be forged. RFC 8601 defines the header and its trust boundary.
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: Read smtp.mailfrom or smtp.helo in the receiving system's Authentication-Results and confirm which domain SPF evaluated and whether the sending IP was allowed.
- Check DKIM: Record the signing domain in header.d or DKIM-Signature d= and check its identifier alignment 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.
Which From term to use
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.
