If your visible message From is enews.example.com but a dashboard shows header.from as example.com, the most likely explanation is DMARC inheritance or unclear labelling in the reporting view. The visible From did not change. The receiver is often showing the organizational domain used for DMARC policy lookup, especially when the subdomain does not publish its own DMARC record and inherits the apex record.
The important test is simple: DMARC passes when either SPF or DKIM passes and has domain alignment with the visible RFC5322 From domain. They do not both need to pass alignment. If the visible From is enews.example.com and the DKIM signature has d= enews.example.com, DKIM is an exact match for that From domain.
- Header label: Treat header.from as a DMARC reporting label until raw headers prove otherwise.
- Visible From: This is the RFC5322 From address the recipient sees in the inbox.
- Envelope From: Return-Path is the bounce address and SPF identity, also called MailFrom.
- Full split: Read more about the 5321 and 5322 From if those labels keep crossing wires.
For one-click unsubscribe, the correct setup is an HTTPS URL in List-Unsubscribe, a List-Unsubscribe-Post header with List-Unsubscribe=One-Click, and a DKIM signature that covers those list headers. The endpoint must accept a POST request and unsubscribe without login, captcha, or a second confirmation screen.
Why the two From values differ
Email has several sender identities, and too many interfaces call more than one of them From. I always start by separating the visible header identity, the bounce identity, and the signing identity.
|
|
|
|---|---|---|
Visible From | Header | DMARC |
Return-Path | Envelope | SPF |
DKIM d | Signature | DKIM |
DMARC apex | DNS | Policy |
Sender identity labels that commonly get confused.
In the common case, the message is sent as Brand News at enews.example.com, the Return-Path uses bounces.example.com or example.com, and DKIM signs with enews.example.com. That can be completely valid. The Return-Path does not have to be identical to the visible From if DKIM already carries the DMARC pass.
The extra wrinkle is DMARC policy discovery. If there is no record at _dmarc.enews, the receiver checks the organizational domain, such as _dmarc.example. A report or dashboard can then display example.com in a DMARC field, even though the inbox-visible From address is still enews.example.com.
Do not diagnose by label alone
A dashboard warning about header.from is a prompt to inspect raw headers. It is not proof that the visible From domain is wrong.
- Raw From: Confirm the actual RFC5322 From address in the message source.
- Policy source: Check whether the subdomain inherits DMARC at the apex.
- Pass route: Find whether SPF or DKIM produced the DMARC pass.
Header identities to compare
From: Brand News <editor@enews.example.com> Return-Path: <bounce@bounces.example.com> DKIM-Signature: v=1; d=enews.example.com; s=s1; ... Authentication-Results: mx.example; dmarc=pass header.from=example.com
How DMARC decides pass or fail
DMARC checks the visible From domain against authenticated SPF and DKIM identities. A message passes DMARC when SPF passes with alignment, or DKIM passes with alignment. That "or" matters. A failed SPF alignment warning does not matter when DKIM passes with the visible From domain.
SPF route
- Identity: SPF uses the Return-Path or MailFrom domain.
- Match: Relaxed alignment matches the same organizational domain.
- Limit: Forwarding breaks SPF often, so DKIM is the safer pass route.
DKIM route
- Identity: DKIM uses the domain in the signature's d value.
- Match: Exact alignment means the d value equals the visible From domain.
- Benefit: DKIM survives forwarding when the signed content remains unchanged.
DMARC outcomes to separate
These are practical reading bands for the raw header result.
Pass
Good
SPF or DKIM passes with From alignment.
Warn
Review
Only one route passes, but DMARC still passes.
Fail
Fix
Neither authenticated identity matches the visible From.
Label mismatch
Verify
The dashboard reports apex policy inheritance.
Strict alignment is cleaner operationally because every visible domain, signing domain, and return path can be tied to one sending stream. Relaxed alignment is still valid under normal DMARC policy unless you publish adkim=s or aspf=s. I prefer exact matching for marketing subdomains because it makes troubleshooting faster and keeps vendor migrations less ambiguous.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's product is useful here because it connects DMARC policy, SPF, DKIM, source identity, and failure reasons in one workflow. Its DMARC monitoring view turns aggregate reports into sender-level actions, which is what most teams need when a dashboard warning and raw headers seem to disagree.
The correct one-click unsubscribe setup
For subscribed marketing mail, one-click unsubscribe needs the header method, not only a footer link in the body. The footer link is still useful for humans, but mailbox providers look for machine-readable list headers.
Compliant one-click unsubscribe headers
From: Brand News <editor@enews.example.com> List-Unsubscribe: <https://u.example.com/o/abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe> List-Unsubscribe-Post: List-Unsubscribe=One-Click DKIM-Signature: v=1; d=enews.example.com; s=s1; h=from:to:subject:date:list-unsubscribe:list-unsubscribe-post; ...
The HTTPS unsubscribe URL should contain an opaque signed token that identifies the recipient, list, and sending program. The endpoint accepts POST and returns a 2xx response after recording the opt-out. It should not require the recipient to visit a preference center, enter an email address, confirm again, or authenticate.
HTTP breaks the one-click path
If the List-Unsubscribe URL uses http instead of https, fix that first. Legacy sending domains and older tracking hosts often need SSL enabled before one-click checks pass.
- HTTPS URL: Use a secure URL in the List-Unsubscribe header.
- Signed headers: Include both list headers in the DKIM signed header list.
- Direct POST: Accept the unsubscribe request without another confirmation step.
- Fast response: Return a 2xx status quickly and process the opt-out within policy.
Flowchart showing one-click unsubscribe moving through header check, HTTPS POST, opt-out save, and 2xx response.
The other easy miss is DKIM signing order. If your ESP adds the unsubscribe headers after DKIM signing, or if the DKIM signature's h= list does not cover them, the receiver cannot trust that the one-click destination was part of the authenticated message.
How I verify the full setup
I verify this in two passes. First I read the raw message headers and identify the visible From, Return-Path, DKIM d value, DMARC result, and list unsubscribe headers. Then I check DNS and the live unsubscribe endpoint.
- From match: Confirm the visible From domain and DKIM d value are the same, or share the same organizational domain under relaxed alignment.
- SPF route: Check whether the Return-Path domain passes SPF and matches the visible From domain at the required mode.
- DMARC DNS: Use the DMARC checker to confirm policy tags, inheritance, and reporting addresses.
- Domain checks: Run a broader domain health check when Gmail delivery issues suggest more than one configuration problem.
- Unsub path: Send a live message and confirm HTTPS, POST handling, DKIM coverage, and a clean 2xx response.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
For teams that manage several senders, Suped's product is the strongest practical choice because it keeps these checks tied to real mail streams instead of isolated one-off tests. It has automated issue detection, real-time alerts, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, and MSP-friendly multi-tenant reporting.
When the fix is policy staging rather than a single header edit, Hosted DMARC helps teams move domains toward enforcement with less DNS churn. That is useful when the sending subdomain inherits the apex record and several business units send under the same root domain.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Common causes and fixes
Most cases end up in one of a few buckets. The fastest fix is to separate display-domain questions from authentication-domain questions, then test the unsubscribe URL as its own workflow.
|
|
|
|---|---|---|
Apex shown | Inheritance | Check raw From |
SPF fail | Bounce host | Set return path |
DKIM warning | Unsigned list | Sign headers |
Unsub fail | HTTP URL | Enable HTTPS |
Gmail issue | Reputation | Review sources |
Fast triage for the most common symptoms.
If SPF and DKIM both pass in raw headers, and at least one has alignment with the visible From domain, the remaining Gmail problem is often reputation, complaint rate, consent quality, content, list age, or engagement. Authentication is necessary, but it does not guarantee inbox placement.
The clean target state
- Visible From: Use a dedicated marketing subdomain such as enews.example.com.
- DKIM d: Sign with that same subdomain when the ESP supports it.
- DMARC: Publish at the subdomain or inherit intentionally from the apex.
- Unsubscribe: Use HTTPS one-click headers signed by DKIM and backed by a POST endpoint.
Views from the trenches
Best practices
Separate visible From, Return-Path, and DKIM d before changing DNS or ESP settings.
Prefer exact DKIM alignment for marketing subdomains when the sending platform allows it.
Verify one-click unsubscribe with a live email, not only a platform settings screen.
Keep DMARC inheritance intentional, documented, and visible to every sender owner.
Common pitfalls
Treating a dashboard header.from label as proof that the visible From changed at all.
Fixing SPF alignment while ignoring a valid DKIM path that already passes DMARC.
Publishing list headers with an HTTP URL on older tracking or unsubscribe domains.
Adding unsubscribe headers after DKIM signing, leaving the list headers unauthenticated.
Expert tips
Use exact matching for DKIM d and visible From when troubleshooting gets noisy fast.
Check the DMARC policy lookup path before assuming a subdomain has its own record.
Make the one-click endpoint accept POST and return a 2xx response without redirects.
Review reputation separately once SPF, DKIM, DMARC, and unsubscribe all pass cleanly.
Expert from Email Geeks says SPF and DKIM do not both need alignment for DMARC. One passing aligned path is enough.
2024-11-05 - Email Geeks
Expert from Email Geeks says a top-level header.from value can appear when the subdomain inherits the apex DMARC record.
2024-11-05 - Email Geeks
The setup I trust
The correct setup is a visible From domain you control, DKIM signing with that same domain where possible, SPF configured on the Return-Path domain, and a DMARC record that clearly applies to the sending subdomain. If a report shows the apex in header.from, check whether that is policy inheritance before changing the sender.
For one-click unsubscribe, use HTTPS, include both list headers, sign them with DKIM, and make the URL accept a direct POST unsubscribe. Once those pass, separate authentication work from reputation work. That split saves time and prevents unnecessary DNS changes.
