What are the differences between 5321.from and 5322.from in email headers?
Published 1 Aug 2025
Updated 11 Aug 2026
12 min read
Summarize with
Updated on 11 Aug 2026: We updated this guide for RFC 9989, including its alignment rules and edge-case handling.
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.
The short answer
The 5321.from address 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.
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 each value appears
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.
Simplified SMTP and headerstext
MAIL FROM:<bounces.123@bounce.example.net> RCPT TO:<person@example.org> DATA From: Example Brand <news@example.com> Return-Path: <bounces.123@bounce.example.net> DKIM-Signature: v=1; d=example.com; s=s1; ...
In that example, the SMTP MAIL FROM value is bounces.123 at bounce.example.net. After final delivery, the receiving system normally records that reverse path in a Return-Path header. The visible From header is news@example.com. Those two domains can differ without breaking authentication.
Flowchart showing SMTP MAIL FROM, SPF, Header From, DKIM, DMARC alignment, and policy result.
|
|
|
|
|---|---|---|---|
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.
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. If no domain or more than one domain is extracted, standard DMARC validation cannot produce the normal result.
- Null MAIL FROM: Valid for bounce messages and evaluated by SPF using the HELO-derived identity.
- Missing or repeated From: The message is malformed, so a receiver cannot select one Author Domain reliably.
- Multiple From domains: DMARC validation normally stops because there is no single Author Domain.
- 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.
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 signing domain can match the visible From domain exactly, or both domains can resolve to the same Organizational Domain when relaxed alignment is used.
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 now defines DMARC and obsoletes RFC 7489. For relaxed alignment, receivers use its DNS Tree Walk to discover the Organizational Domain rather than relying only on a public suffix list. Exact domain matching still applies when strict alignment is configured.
DMARC record exampledns
_dmarc.example.com TXT ( "v=DMARC1; p=quarantine; " "rua=mailto:dmarc@example.com; adkim=r; aspf=r" )
Important caveat
Matching 5321.from to 5322.from is not required for every legitimate message. DMARC needs one aligned pass: SPF alignment or DKIM alignment.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The Suped DMARC checker parses a published record and shows whether its policy tags are valid before report data is interpreted.
For a broader check across DMARC, SPF, and DKIM, the Suped domain health checker can validate the domain before more test mail is sent.
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.
The same is not usually true for 5321.from. A bounce domain often points at one sending system, and that system uses it for bounce classification, suppression, and SPF authorization. Sharing one bounce domain across multiple ESPs creates confusing SPF records and broken return handling unless the whole mail path is under one operator's control.
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.
Unique 5321.from
- Use case: bounces.news.example.com points at one sending system.
- Requirement: Each sender gets its own return path or bounce domain.
- Risk: Sharing one bounce path breaks bounce processing and SPF control.
The same DKIM d= domain can be used at multiple ESPs if each one has a different selector. 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
Domains align 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 | No align | Aligns | Pass |
Brand bounce, brand From | Aligns | No align | Pass |
ESP bounce, ESP DKIM | No align | No align | Fail |
Brand subdomains, relaxed | Aligns | Aligns | Pass |
Alignment outcomes for common sender setups.
DMARC alignment examplestext
SPF pass, 5321.from=bounce.example.net, 5322.from=example.com DKIM pass, d=example.com DMARC result: pass through DKIM alignment SPF pass, 5321.from=mail.example.com, 5322.from=example.com DKIM fail DMARC result: pass through relaxed SPF alignment SPF pass, 5321.from=esp.example.net, 5322.from=example.com DKIM pass, d=esp.example.net DMARC result: fail because neither path aligns
Simple test
- Find: Open the raw message and locate Return-Path, From, DKIM-Signature, and Authentication-Results.
- Compare SPF: Check the Return-Path and From domains under the configured strict or relaxed mode.
- Compare DKIM: Check each validated d= domain against From under the configured alignment mode.
- Decide: DMARC passes when at least one aligned authentication path passes.
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 the receiving system to see which checks passed, then apply the configured alignment mode. Treat the final receiver's result as authoritative for that delivery. 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, bounce address, return path, or envelope sender.
- Header From: Usually means 5322.from, visible From, 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.
Infographic labeling the envelope sender, visible From, DKIM 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 bounces stay easy to trace.
Verify DMARC with raw headers first, then confirm reports after real mail flows.
Common pitfalls
Treating Return-Path as the visible sender makes teams fix the wrong identity field.
Reusing one bounce domain across providers creates SPF sprawl and routing errors.
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 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 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
The practical takeaway
Treat 5321.from as the SMTP bounce identity and 5322.from as the visible author identity. SPF starts with the envelope sender. DMARC starts with the visible From domain. DKIM supplies a second way to pass DMARC when its validated signing domain aligns with that visible From domain.
For a single message, raw headers are usually enough to diagnose the difference. For an operating mail program, map every sender source, give each ESP its own bounce domain, publish DKIM selectors carefully, and monitor DMARC reports continuously. Suped supports that workflow by connecting source-level authentication results to the alignment and policy decisions that affect delivery.
