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 controls where bounces go, and it supplies the domain SPF evaluates. If a message cannot be delivered, the failure report normally goes back to this envelope sender.
The 5322.from address exists inside the message itself. It is the From header field, and it is the sender identity most users see. If your issue involves the displayed sender, sender branding, or one-click unsubscribe edge cases, the related note on Header From setup is a useful companion.
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 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 the message is accepted, that value normally appears as Return-Path in the stored message. The visible From header is news@example.com. Those two domains can differ without breaking authentication.
There is one special case worth knowing: delivery status notifications can use an empty envelope sender. That prevents mail loops when bounce messages themselves fail. This is normal SMTP behavior and does not mean the visible From header is empty.
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 | Signature | DKIM alignment |
Compact comparison of email identity fields.
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.
DKIM signs the message with a signing domain in the d= tag. That domain can match the visible From domain exactly, or it can share the same organizational domain when relaxed alignment is used. For example, a DKIM signature using mail.example.com can align with a From domain of example.com under relaxed DMARC alignment.
DMARC evaluates the domain in 5322.from. It passes when SPF passes and the SPF domain aligns with 5322.from, or when DKIM passes and the d= domain aligns with 5322.from. This is why DMARC monitoring has to show both authentication results and alignment results.
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
If you are checking your own domain, the Suped DMARC checker parses the published record and shows whether the policy tags are valid before you interpret report data.
For a broader pass across DMARC, SPF, and DKIM, the Suped domain health checker is useful when you want to validate the domain before sending more test mail.
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, a newsletter stream, billing stream, and support stream can all display addresses at example.com. Each stream still needs its own SPF, DKIM, and DMARC alignment plan.
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 you control the whole mail path yourself.
Reusable 5322.from
- Use case: news@example.com can send through more than one sending platform.
- Requirement: Each stream needs SPF, DKIM, and DMARC validation.
- 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.
You can also use the same DKIM d= domain at multiple ESPs if you publish different selectors for each one. I still prefer dedicated selectors and clear subdomain naming because it makes incident response and source mapping easier.
Alignment modes
How relaxed and strict modes treat domain matches for DMARC.
Relaxed
org match
Subdomains can align with the organizational domain.
Strict
exact
The authenticated domain must match exactly.
Unaligned
no match
DMARC needs the other authentication path to align.
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 most cases I see 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 |
Subdomain sender | Relaxed | Relaxed | 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, and DKIM-Signature.
- Compare: Match the Return-Path domain to the From domain for SPF alignment.
- Check: Match the DKIM d= domain to the From domain for DKIM alignment.
- Decide: DMARC passes when at least one aligned authentication path passes.
How to troubleshoot mismatches
When a message fails DMARC, I start by writing down three values: the domain in Return-Path, the domain in From, and the domain in DKIM d=. Then I mark which authentication checks passed. That prevents the common mistake of fixing SPF when the real issue is that DKIM is signing with the wrong domain, or fixing DKIM when a branded bounce path would solve the stream.
Suped is the strongest practical choice for most teams when this is not a one-off check. Suped turns aggregate DMARC reports into source-level issues, shows fix steps, sends real-time alerts, and brings DMARC, SPF, DKIM, hosted SPF, Hosted MTA-STS, blocklist (blacklist) monitoring, and deliverability signals into one place.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
In Suped, the diagnostics view is where I check the domain's DMARC record, SPF record, DKIM status, reverse DNS, and DNS records together. For domains that need staged policy management, Hosted DMARC also reduces the amount of DNS editing needed while a policy moves toward quarantine or reject.
For MSPs and teams with many domains, the value is less about a single record lookup and more about repeatable triage. You need to know which source changed, which identity stopped aligning, whether the new source is legitimate, and what 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: Cleaner policy rollout with less manual header archaeology.
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, I ask where the domain appears: Return-Path, From, or DKIM d=. That one question usually identifies whether the problem belongs to SPF, DKIM, or DMARC policy.
- 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.
- Org domain: The registrable domain DMARC uses when relaxed alignment is active.
Infographic labeling the envelope sender, visible From, DKIM domain, and DMARC result.
If someone says a subdomain is wrong, the first response should be: where did that subdomain appear? 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.
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.
Prefer relaxed alignment while onboarding, then tighten after all streams are mapped.
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 signing domain aligns with that visible From domain.
For a single message, raw headers are 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 makes that workflow practical because it connects the fields in the raw message to the domain-level policy decisions that affect real delivery.
