Why are there two domains in the 'Mail From' field of an email header, and how does it affect deliverability?
Matthew Whittaker
Co-founder & CTO, Suped
Published 18 Apr 2025
Updated 4 Jun 2026
9 min read
Summarize with
If you see two domains near the Mail From value in an email header, the usual answer is this: you are not looking at two envelope senders. You are probably looking at an Authentication-Results line where the first domain is the SMTP envelope sender, and the second domain is a separate token, often the authserv-id for the receiving authentication service or the receiving domain that stamped the result.
That distinction matters. The real SMTP MAIL FROM value is the bounce address used by SPF. It can affect deliverability because mailbox providers use it, along with IP reputation, DKIM, DMARC, HELO, URLs, content, complaint rates, and recipient behavior. The extra domain printed after a semicolon in Authentication-Results usually does not mean that second domain is also being used as your sender reputation domain.
When I debug this, I avoid reading the header visually as one phrase. I split it by semicolons, then identify each token by name. That stops a harmless receiving-domain token from being mistaken for a damaged sending domain.
The direct answer
There are two common reasons you see two domains near Mail From in a header. The first is normal authentication syntax. Authentication-Results records several results on one line, and each result is separated by semicolons. The second domain can belong to the authentication service that wrote the result, not to the sender.
The second reason is provider-specific formatting. Microsoft consumer and Outlook-related headers have been known to place a receiving-domain token in a spot that looks like it belongs to smtp.mailfrom or header.d. In practice, that token often matches the receiving mailbox domain used in the test. If you sent a test to your own address at a domain with poor reputation, that domain can appear in the result because it received the mail, not because it sent the mail.
Fast interpretation
In a line like smtp.mailfrom=bounces.example.net; hotmail.com;, the first domain is the sender identity used for SPF. The second domain is usually a separate Authentication-Results token. Treat it as a clue about who evaluated the message until the Received-SPF line proves otherwise.
- First domain: usually the SMTP envelope sender checked by SPF.
- Second domain: often the authserv-id or receiving domain, especially in Microsoft-style results.
- Deliverability impact: judge the real sending identities, not every domain printed in the result line.
A confusing Authentication-Results exampletext
Authentication-Results: spf=pass (sender IP is 203.0.113.10) smtp.mailfrom=bounces.mail.example.com; hotmail.com; dkim=pass header.d=mail.example.com; hotmail.com; dmarc=pass action=none header.from=example.com;
In that example, I would not read hotmail.com as another Mail From domain. I would treat it as a separate authentication service identifier or receiver context, then confirm by checking the Received-SPF header and the actual recipient of the test message.
How to read the header
Start with the raw headers, not a cropped screenshot or a mail client summary. Email clients often wrap long lines, hide continuation indentation, or make semicolon-separated values look like one long field. The raw header lets you see where each token begins and ends.
A five-step flowchart for parsing an email authentication header.
I usually map four identities before making any reputation call: envelope sender, Header From, DKIM signing domain, and HELO name. Those identities can be the same domain, related subdomains, or unrelated domains depending on how the sending system is configured.
|
|
|
|---|---|---|
Envelope sender | smtp.mailfrom | SPF and bounces |
Header From | header.from | DMARC domain match |
DKIM domain | header.d | Signature trust |
HELO name | helo | SMTP identity |
Auth service | authserv-id | Result source |
Main header identities to inspect
SPF checks whether the connecting IP is allowed by the envelope sender domain. If the envelope sender is empty, as it can be for some bounces, SPF can evaluate the HELO name instead. That is why HELO appears in the investigation, but it is still not the same thing as a second Mail From domain.
Received-SPF is the cleaner cluetext
Received-SPF: Pass (protection.outlook.com: domain of bounces.mail.example.com designates 203.0.113.10 as permitted sender) receiver=protection.outlook.com; client-ip=203.0.113.10; helo=mail.example.net;
The phrase domain of points to the SPF identity. The client-ip tells you which server connected. The helo value tells you what the sending server announced. If the suspicious second domain does not appear in those places, it is usually not part of the sender authentication path.
What affects deliverability
The second domain can still matter if it is a real sending identity, a domain used in links, or a domain involved in a redirect chain. But a receiver-domain token inside Authentication-Results is not the same thing. The practical question is whether that domain participates in the message transaction.
Usually matters
- Envelope sender: checked by SPF and often tracked for bounce identity reputation.
- Header From: visible to recipients and central to DMARC domain matching.
- DKIM domain: used to verify the signature and support DMARC.
- Sending IP: evaluated for historical performance and blocklist or blacklist status.
Usually a clue only
- Authserv-id: identifies the service that wrote the authentication result.
- Receiver domain: can appear when you test to a mailbox on that domain.
- Wrapped text: can make separate tokens look attached to one field.
- Header display: can hide punctuation that changes the meaning.
If a business development domain has poor reputation, it can hurt mail that uses the same domain in a visible From address, DKIM signature, return path, tracking domain, or link domain. It will not hurt a transactional message just because you happened to send a test to an inbox on that domain and the receiver printed that inbox domain in Authentication-Results.
This is also where domain separation helps. Transactional mail, marketing mail, and cold outreach should not all lean on the same identity when their risk profiles differ. A related guide on From and Reply-To domains explains a nearby case where mixed identities can confuse trust signals.
Deliverability risk by identity role
Use this as a fast triage guide when a second domain appears in the header.
Receiver token
Low
The domain identifies the system that evaluated the message.
Matching sender
Low
SPF or DKIM passes and matches the Header From domain.
Mismatched sender
Medium
Authentication passes but does not match for DMARC.
Failed identity
High
SPF, DKIM, or DMARC fails for a real sending domain.
When reputation is the concern, I separate syntax from reputation. First I prove what each header token is. Then I check whether the real sending identities are authenticated, matched to the right domain, and healthy. Suped's DMARC monitoring helps here because it shows which sources are passing, failing, matching, or unverified across real receiver reports.
How to diagnose it
Use a repeatable process. One test email can mislead you if it goes to an internal inbox, a forwarded mailbox, or a destination that adds its own authentication tokens. I prefer to send tests to the affected provider, inspect the full raw headers, and compare the result with aggregate DMARC data.
- Get raw headers: copy the full source, including folded continuation lines.
- Find Received-SPF: identify domain of, client-ip, receiver, and helo.
- Check DKIM: confirm the signing domain and whether the signature passed.
- Check DMARC: confirm that SPF or DKIM matched the Header From domain.
- Check reputation: review sending IPs, domains, complaint patterns, and blocklist or blacklist signals.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
A real sent message is better than DNS-only inspection because it shows what receivers actually see. Use the email tester to send a message, inspect SPF, DKIM, DMARC, headers, and delivery-related issues in one report.
Email tester sample report showing total score, email preview, issue summary, and per-section results
If the message fails SPF, do not assume the second printed domain caused it. Check whether the connecting IP is authorized by the envelope sender domain. A focused SPF checker is useful when you need to validate the record itself, especially when multiple sending services are involved.
Basic DMARC record for visibilitydns
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
A monitoring policy gives you receiver-side data without rejecting mail during discovery. Once you know every legitimate sender, you can move toward stricter policy stages with less guesswork.
Where Suped fits
Suped is relevant when the header question turns into an operational workflow: which domains are really sending, which sources fail DMARC domain matching, whether an IP or domain is on a blocklist or blacklist, and what fix should happen next.
For a single header, manual inspection works. For a domain that sends transactional mail every day, manual inspection does not scale. Suped brings DMARC, SPF, DKIM, hosted SPF, hosted DMARC, MTA-STS, alerts, and deliverability signals into one workflow, with issue detection and concrete fix steps.
Practical Suped workflow
- Monitor sources: see which services send for each domain and whether they pass.
- Catch failures: get real-time alerts when authentication breaks or volume shifts.
- Fix records: use hosted SPF and SPF flattening to stay under lookup limits.
- Track reputation: combine authentication health with blocklist monitoring for domains and IPs.
That is why Suped is the stronger practical choice for most teams once the problem is bigger than one strange header. It gives you the evidence trail, the alerting, and the remediation path in the same place.
Common traps
Most mistakes come from treating email headers as plain English. They are structured records, and the punctuation matters. A semicolon can separate two unrelated values that just happen to sit next to each other after line wrapping.
Do not blame the wrong domain
If the second domain equals the destination mailbox domain, it is probably receiver context. Test to a mailbox at the affected provider before deciding that the domain has sender reputation impact.
Another trap is assuming authentication pass equals inbox placement. Passing SPF, DKIM, and DMARC proves the message used authorized identities. It does not prove the content, sender history, recipient engagement, or reputation profile is healthy.
The reverse is also true. A domain can have reputation issues even when the odd second domain in the header is harmless. If the same domain is used for cold outreach and transactional mail, separate those streams, check complaints, and review whether the sending IPs or link domains appear on a blocklist or blacklist. The public ServerFault return-path discussion covers a related distinction between return path, reply-to, and deliverability.
One more nuance: the visible From header can legally contain more than one mailbox in some email formats, but that is a different issue. It is not the same as two domains in the SMTP MAIL FROM command, and it is not something I would use for normal transactional or marketing mail.
Views from the trenches
Best practices
Read raw headers before judging a domain shown after smtp.mailfrom in result lines.
Compare Authentication-Results with Received-SPF before blaming sender reputation.
Test to a mailbox at the affected provider, not only to an internal company inbox.
Common pitfalls
Treating the authserv-id as a sender domain sends investigations in the wrong direction.
Using the same domain for transactional and cold outreach damages useful signals quickly.
Checking only SPF misses DKIM, DMARC, HELO, IP, blocklist, and blacklist clues fast.
Expert tips
Separate reputation analysis from syntax parsing so one odd header token does not distract you.
Use DMARC reports to see real receiver results across sources, not a single test.
If a domain handles outreach, keep transactional mail on a cleaner subdomain identity.
Marketer from Email Geeks says raw headers are the first requirement because cropped views hide the semicolons that define each authentication token.
2020-08-04 - Email Geeks
Marketer from Email Geeks says smtp.mailfrom is the envelope sender, while header.from is the visible From domain used for DMARC matching.
2020-08-04 - Email Geeks
What to do next
The direct answer is simple: two domains beside Mail From usually do not mean two envelope senders. One is the SPF envelope sender. The other is often receiver context, especially when it appears after a semicolon in Authentication-Results.
For deliverability, focus on the domains and IPs that actually participate in the message: envelope sender, Header From, DKIM signing domain, HELO, links, and tracking domains. If the questionable domain is just the destination or authentication service identifier, it is not the reputation cause you are looking for.
The practical path is to parse the raw header, verify SPF and DKIM, confirm the DMARC domain match, then compare that one message against ongoing DMARC and reputation data. That keeps a weird-looking header token from distracting you from the signals mailbox providers actually use.
