What are the differences between 5321.from and 5322.from in email headers?
Published 1 Aug 2025
Updated 19 Oct 2026
13 min read
Summarize with
Updated on 19 Oct 2026: We clarified envelope and header sender identities, corrected the authentication examples, and added forwarding guidance.
The difference is simple: 5321.from is the SMTP envelope sender used during the mail transaction, while 5322.from is the visible From address inside the message headers. SPF checks the domain tied to 5321.from. DMARC protects the domain in 5322.from and passes when either SPF or DKIM passes with domain alignment.
This distinction matters because many legitimate messages use different domains for bounce handling, visible branding, and DKIM signing. A marketing email can show news@example.com to the recipient, use a bounce subdomain owned by the sender or ESP for return handling, and sign with a DKIM domain that still aligns with example.com. The DMARC.org From article gives useful background on why the word From gets overloaded.
- 5321.from: The SMTP envelope sender, also called MAIL FROM, envelope From, bounce address, or Return-Path after delivery.
- 5322.from: The author address in the message header, usually the From address a recipient sees in the mail client.
- DMARC: The policy layer that evaluates the visible From domain and requires SPF or DKIM to pass with alignment.
SMTP envelope sender vs visible From address
The 5321.from address, formally RFC5321.MailFrom, exists at the SMTP layer. A receiving mail server sees it before the body and headers are transferred. It supplies the reverse path for delivery failures, and its domain is the primary identity SPF evaluates. RFC 5321 defines SMTP, while RFC 5322 defines the Internet Message Format (IMF).
The 5322.from address exists inside the message itself. It is the From header field and the sender identity most users see. Reply-To can direct responses to another address, but it does not replace 5322.from for DMARC. The related note on Header From setup covers sender branding and one-click unsubscribe edge cases.
Fast rule
The 5321.from field answers where bounces go and which domain SPF checks. The 5322.from field answers who the message says it is from and which domain DMARC protects.
SMTP envelope
- Domain: The bounce or return-path domain used during SMTP.
- Checked by: SPF uses this domain to authorize the sending IP.
- Seen by: Mail servers, not usually the end recipient.
Message header
- Identity: The visible author address in the From header.
- Checked by: DMARC uses this domain as the protected identity.
- Seen by: Recipients, mailbox providers, and filtering systems.
Where MAIL FROM and From appear
The easiest way to separate the two values is to inspect the raw message and, when available, the SMTP transaction. The SMTP envelope is not the same thing as the message header, even though both can contain addresses that look like senders.
SMTP transaction excerpttext
MAIL FROM:<bounces.123@bounce.example.net> RCPT TO:<person@example.org> DATA From: Example Brand <news@example.com> DKIM-Signature: v=1; d=example.com; s=s1; ...
In that example, the SMTP MAIL FROM value is bounces.123@bounce.example.net. The final delivery system adds a Return-Path header containing that reverse path, as specified in RFC 5321. The visible From header is news@example.com. Those two domains can differ without breaking authentication. Editing a Return-Path header in the outgoing message does not configure SMTP MAIL FROM.
Delivered message headers and authentication resultstext
Return-Path: <bounces.123@bounce.example.net> From: Example Brand <news@example.com> Authentication-Results: mx.example.org; spf=pass smtp.mailfrom=bounce.example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In Authentication-Results, smtp.mailfrom identifies the SPF envelope domain, header.d identifies the DKIM signing domain, and header.from identifies the DMARC Author Domain. Here SPF passes without alignment, while the validated DKIM domain matches the From domain and supplies the DMARC pass.
Email authentication flow comparing SMTP MAIL FROM and DKIM signing domains with the visible From domain for DMARC.
|
|
|
|
|---|---|---|---|
5321.from | SMTP server | Bounces | SPF alignment |
5322.from | Recipient | Visible sender | Protected domain |
DKIM d= | Verifier | Signing domain | DKIM alignment |
Compact comparison of email identity fields.
Null MAIL FROM and invalid From headers
A null reverse path is valid for delivery status notifications and other messages that must not generate another bounce. The SMTP command appears as MAIL FROM:<>. SPF then defines the MAIL FROM identity as postmaster at the HELO or EHLO domain, so there is still a domain to evaluate. A separate HELO SPF pass does not replace a failed nonempty MAIL FROM identity for DMARC.
The visible From side has a different constraint. RFC 9989 calls the domain extracted from 5322.from the Author Domain. DMARC expects one properly formed From field with one domain. With no domain, DMARC validation stops. With multiple domains, validation normally stops, although RFC 9989 permits the receiver to continue at its discretion.
- Null MAIL FROM: Valid for bounce messages and evaluated by SPF using the HELO-derived identity.
- Missing or repeated From: A missing From or multiple From fields makes the message malformed and requires receiver handling outside the normal valid-header case.
- Multiple From domains: DMARC validation normally stops; any continued validation is at the receiver's discretion.
- Reply-To: Controls where a reply goes, but SPF and DMARC do not use it for alignment.
Do not treat every Return-Path difference as a failure
A different Return-Path is common for bounce processing. Check whether its SPF-authenticated domain aligns with the Author Domain, or whether a validated DKIM signing domain provides the aligned DMARC pass.
How SPF, DKIM, and DMARC use them
SPF checks whether the sending IP is authorized by the domain used in 5321.from. SPF by itself does not prove that the visible From domain authorized the message. It proves that the SMTP envelope domain authorized the sending server. When the reverse path is null, SPF uses the HELO-derived MAIL FROM identity described above. Publish SPF at the actual MAIL FROM domain. For bounce.example.net, the SPF lookup is at that subdomain; an SPF record at example.net is not inherited. Adding a sending platform to the visible From domain's SPF record does not authenticate a different MAIL FROM domain. See RFC 7208 for the SPF identity and record lookup rules.
DKIM signs the message with a signing domain in the d= tag. A validated signature authenticates that signing domain, not the visible From address itself. The From header must be signed, but DMARC still requires the signing domain to have alignment with From. The signing domain can match the visible From domain exactly, or both domains can have the same Organizational Domain when relaxed alignment is used. See RFC 6376 for DKIM signing requirements.
DMARC evaluates the domain in 5322.from. It passes when SPF passes and the SPF-authenticated domain aligns with 5322.from, or when DKIM validates and the d= domain aligns with 5322.from. This is why DMARC monitoring needs to show authentication and alignment as separate results.
RFC 9989 defines DMARC and obsoletes RFC 7489. It specifies a DNS Tree Walk to discover Organizational Domains for relaxed alignment, replacing RFC 7489's public-suffix-based approach. Strict alignment requires exact domain matching.
DMARC record exampledns
_dmarc.example.com TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc@example.com; adkim=r; aspf=r" )
DMARC requires one authenticated domain with alignment
Matching 5321.from to 5322.from is not required for every legitimate message. DMARC needs one aligned pass: SPF alignment or DKIM alignment. The aspf tag controls SPF alignment, and adkim controls DKIM alignment. Both default to r (relaxed); s requires an exact domain match. DMARC compares domains, not mailbox local parts or display names.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Our Suped DMARC checker parses the published policy tags, while our domain health checker checks authentication DNS records before another test send. Use delivered headers and DMARC reports to verify actual message authentication and alignment.
Why the same 5322.from can be used at several ESPs
A sender can use the same visible From domain across several ESPs. For example, newsletter and billing streams can both display addresses at example.com. Each stream needs an authentication plan that produces at least one aligned SPF or DKIM pass. Configuring both paths provides resilience when forwarding or message changes disrupt one mechanism.
Separate bounce domains are often easier to manage for 5321.from. A bounce domain often points at one sending system, which uses it for bounce handling and SPF authorization. Many ESPs require provider-specific MX or CNAME records. Sharing is valid when SPF and bounce routing are coordinated; use separate subdomains when provider requirements conflict.
Reusable 5322.from
- Use case: news@example.com can send through more than one sending platform.
- Requirement: Each stream needs at least one aligned SPF or DKIM pass.
- Risk: A poor stream can affect the shared visible domain.
Separate 5321.from domains
- Use case: bounces.news.example.com points at one sending system.
- Requirement: Use a separate bounce subdomain when providers require conflicting DNS records.
- Risk: Uncoordinated sharing can disrupt bounce processing and SPF authorization.
The same DKIM d= domain can be used at multiple ESPs. Give each ESP its own selector to avoid conflicting DNS key records. Dedicated selectors and clear subdomain names make key rotation, incident response, and source mapping easier.
Alignment modes
How relaxed and strict modes treat domain matches for DMARC.
Relaxed
org match
Relaxed alignment applies when RFC 9989 derives the same Organizational Domain.
Strict
exact
The authenticated domain must match the Author Domain exactly.
Unaligned
no match
DMARC needs the other authentication path to pass with alignment.
Common setups and what passes DMARC
The fastest way to debug DMARC is to stop asking whether SPF or DKIM passed in isolation. Ask whether either one passed and aligned with the visible From domain. These common setups cover typical cases when a sender is onboarding a new ESP or cleaning up an old domain.
|
|
|
|
|---|---|---|---|
ESP bounce, brand From | Pass, unaligned | Pass, aligned | Pass |
Brand bounce, brand From | Pass, aligned | Pass, unaligned | Pass |
ESP bounce and DKIM, brand From | Pass, unaligned | Pass, unaligned | Fail |
Brand subdomains, relaxed | Pass, aligned | Pass, aligned | Pass |
Examples assume the stated authentication results and applicable alignment settings. A DMARC pass does not guarantee acceptance or inbox placement.
DMARC alignment examplestext
SPF pass, 5321.from domain=bounce.example.net, 5322.from domain=example.com DKIM pass, d=example.com DMARC result: pass through DKIM alignment SPF pass, 5321.from domain=mail.example.com, 5322.from domain=example.com DKIM fail DMARC result: pass through relaxed SPF alignment SPF pass, 5321.from domain=esp.example.net, 5322.from domain=example.com DKIM pass, d=esp.example.net DMARC result: fail because neither authenticated domain has alignment
Check authentication before comparing domains
- Find: Open the raw message and locate Return-Path, From, DKIM-Signature, and Authentication-Results.
- Compare SPF: Confirm spf=pass for smtp.mailfrom, then compare that domain with From under the aspf mode.
- Compare DKIM: Confirm dkim=pass for a header.d domain, then compare it with From under the adkim mode.
- Decide: DMARC passes when at least one aligned authentication path passes.
How forwarding changes MAIL FROM and DMARC
Forwarding introduces another sending IP. If the forwarder preserves the original MAIL FROM, that IP often lacks authorization in the original sender's SPF record. The visible From address usually stays unchanged. RFC 7960 explains these authentication problems in indirect email flows.
- Sender Rewriting Scheme (SRS) changes MAIL FROM to an address under the forwarding domain. SPF can pass for that domain while SPF alignment with the original visible From domain still fails.
- DKIM can preserve a DMARC pass when the original signature remains valid and its signing domain has alignment with From. Changes to signed headers or the signed body can invalidate the signature.
Check the final receiver's trusted authentication results when diagnosing forwarded mail. An SRS Return-Path identifies the forwarding hop; it does not establish that the original sender's SPF record needs another sending service.
How to troubleshoot mismatches
When a message fails DMARC, write down the domain in Return-Path, the domain in From, and every validated DKIM d= domain. Use the Authentication-Results header added by your receiving system to see which checks passed, then apply the configured alignment mode. Trust only results added by your receiving infrastructure or an explicitly trusted gateway; senders can insert forged copies. This trust boundary is described in RFC 8601. This process prevents teams from fixing SPF when the real issue is a DKIM signing domain, or changing DKIM when a branded bounce path would solve the stream.
Suped is our DMARC reporting and email authentication platform. It turns aggregate DMARC reports into source-level views, identifies unaligned identities, provides fix steps, and sends alerts when a source's results change.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, the diagnostics view brings the domain's DMARC record, SPF record, DKIM status, reverse DNS, and related DNS records together. For domains that need staged policy management, Hosted DMARC reduces repeated DNS editing while a policy moves toward quarantine or reject.
For MSPs and teams with many domains, the main task is repeatable triage rather than a single record lookup. The workflow needs to identify which source changed, which identity stopped aligning, whether the source is legitimate, and which DNS or platform setting fixes it.
One-off debugging
- Best fit: One raw message or a single DNS record question.
- Workflow: Read headers, compare domains, and send a test message.
- Limit: It misses new senders and intermittent alignment failures.
Suped monitoring
- Best fit: Ongoing DMARC work across many streams or domains.
- Workflow: Track sources, alert on failures, and follow fix steps.
- Result: Repeatable source triage and policy rollout with less manual header analysis.
Naming glossary for email headers
A lot of confusion comes from naming. Different ESPs and mail systems use different labels for the same identity fields. Before changing DNS, identify where the domain appears: Return-Path, From, DKIM d=, or Reply-To. That identifies whether the setting affects SPF, DKIM, DMARC, or only reply routing.
- Envelope From: Usually means 5321.from, MAIL FROM, P1 sender, bounce address, return path, or envelope sender.
- Header From: Usually means 5322.from, visible From, P2 sender, author address, or message From.
- DKIM domain: The domain in the DKIM-Signature d= tag.
- Organizational Domain: The domain DMARC derives through the RFC 9989 DNS Tree Walk for relaxed alignment.
- Reply-To: An optional header that directs replies without changing the DMARC Author Domain.
- Sender: The message header identifying the transmitting agent when it differs from the author. It is separate from SMTP MAIL FROM and is not the Author Domain DMARC evaluates.
Email identity glossary comparing the SMTP envelope sender, visible From address, DKIM signing domain, and DMARC result.
If someone says a subdomain is wrong, first identify where it appeared. A subdomain in Return-Path points toward SPF and bounce handling. A subdomain in From points toward the visible sender identity. A subdomain in d= points toward DKIM alignment, while a subdomain in Reply-To affects reply routing only.
Views from the trenches
Best practices
Label the envelope sender, visible From, and DKIM domain before changing any DNS record.
Use separate bounce subdomains for senders so SPF and bounce handling stay easy to trace.
Verify DMARC with raw headers first, then confirm source results in reports after real mail flows.
Common pitfalls
Treating Return-Path as the visible sender makes teams fix the wrong identity field.
Sharing a bounce domain without coordinated DNS and routing can disrupt SPF and bounces.
Assuming DKIM d= always matches From hides failures when providers use their domain.
Expert tips
Keep a sender glossary so support, marketing, and IT use the same header names daily.
Use relaxed alignment unless an exact-match requirement has been clearly documented.
Use Suped alerts to catch new unaligned sources before they reach high sending volume.
Marketer view
Marketer from Email Geeks says teams need to identify where a domain appears in the raw headers before deciding whether the issue is SPF, DKIM, or DMARC.
2021-10-06 - Email Geeks
Marketer view
Marketer from Email Geeks says the same visible From domain can be used across several senders, but each sender usually needs its own 5321.from domain.
2021-10-06 - Email Geeks
Frequently asked questions
Yes. That is common and valid. The envelope sender can use a bounce domain while the visible From header uses the brand domain. DMARC passes when SPF or DKIM passes with alignment to the visible From domain.
DMARC uses the 5322.from domain as the Author Domain. It then checks whether an SPF-authenticated or DKIM-authenticated domain passed with alignment to that domain.
Return-Path records the SMTP MAIL FROM reverse path at final delivery. A forwarder that rewrites MAIL FROM changes the value recorded by the final delivery system. A null reverse path appears as Return-Path: <>.
Yes. Several ESPs can send mail with the same visible From domain if each stream has at least one aligned SPF or DKIM pass. Each ESP should usually have its own bounce domain and DKIM selector.
Exact matching is required only when strict DKIM alignment is configured. With relaxed alignment, the validated DKIM domain and Author Domain must have the same Organizational Domain under RFC 9989.
No. Reply-To controls where a mail client sends a response. DMARC evaluates the domain in the From header and ignores Reply-To when determining alignment.
