KoltrixFrom, Reply-To, envelope sender, Return-Path: what each is for
One email carries several sender addresses. Learn which one people see, which one bounces use and which ones SPF, DKIM and DMARC actually check.
On this page(10 sections)
An email message does not have one sender. It has several, and they can all be different addresses without anything being wrong.
That is why a message can show "From: [email protected]" while bounces go to an address you have never seen, why a reply can land in someone else's inbox, and why SPF can pass while DMARC fails. Once you know what each address is for, those puzzles stop being puzzles.
This guide walks through the four you will meet most often, then shows how authentication checks use them.
The postal analogy
Think of a letter. The envelope has a return address that the post office uses if the letter cannot be delivered. The letterhead at the top of the page says who the letter is from, for the reader. And a line in the letter can say "please reply to my assistant at this address".
Email works the same way, with names you can look up in the headers.
1. The header From
This is the address people see in their mail client. It lives in the message headers as From:, and it is the identity the recipient trusts or does not trust.
- It can include a display name:
"Sam at Acme" <[email protected]>. - DMARC is anchored here. It asks whether SPF or DKIM passed for a domain that matches this one.
- Mailbox providers watch this domain for reputation, and phishers forge it because it is what a person reads.
If you only control one address carefully, make it this one: use a domain you own, authenticated.
2. The envelope sender (MAIL FROM)
Before a message's headers are sent, the sending server tells the receiving server who the message is from, in the SMTP conversation itself. This is the envelope sender, also called MAIL FROM or the bounce address.
- It is not part of the message headers you see by default.
- Its main job is to say where delivery failure notices go.
- SPF checks the domain in this address, not the header From.
Because it is separate, the envelope sender can be a different domain from the header From. Many email services use their own domain here so they can process bounces for you.
3. The Return-Path header
When the receiving server accepts the message, it usually records the envelope sender in a header called Return-Path: and puts it at the top. That is the copy you can read in "Show original" or "View source".
So Return-Path and the envelope sender are the same address at two moments: one in the conversation, one saved in the message. If you see Return-Path: <[email protected]>, that is where a bounce for this message would be sent.
An empty Return-Path (<>) is normal for bounce messages themselves. It stops two automated systems from bouncing messages back and forth forever.
4. Reply-To
Reply-To: says where a reply should go when the person clicks Reply. If it is absent, replies go to the header From.
Good reasons to set it:
- Your messages come from an address that is not monitored by a person, but a team inbox should receive the answers.
- A tool sends on behalf of someone and replies belong to that person.
Reply-To is not an identity. It does not take part in SPF, DKIM or DMARC. Use it to route replies, and avoid pointing it at a different company's domain without a clear reason, because filters treat a mismatch as a mild warning sign. This is one more reason to avoid a noreply address: a real address in From or Reply-To gives people a way to answer.
Which check looks at which address
| Check | Looks at | What it proves |
|---|---|---|
| SPF | The envelope sender domain (and the HELO name) | The sending server is allowed to send for that domain |
| DKIM | The d= domain in the signature |
That domain vouched for the message and it was not changed |
| DMARC | The header From domain | Either SPF or DKIM passed for a domain that aligns with the From |
DMARC is the one that connects the others to what people see. For the details of matching, see relaxed and strict alignment. If you want the three checks explained from scratch, start with SPF, DKIM and DMARC in plain English.
Why SPF can pass and DMARC can still fail
Suppose an email service sends your message with the envelope sender [email protected] and the header From [email protected].
- SPF passes for
service.net, because the service is allowed to send for its own domain. - But
service.netdoes not align withyourcompany.com, so SPF does not help DMARC. - If the service also signs with a DKIM key for
yourcompany.com, DKIM aligns and DMARC passes.
That is why a good sending service asks you to publish a DKIM record for your own domain, and sometimes a custom return-path domain too. See DKIM for third-party senders.
How to see them on a real message
- Open a message you sent to yourself.
- Choose "Show original" (Gmail) or "View source" (most clients).
- Find these lines:
From:,Reply-To:,Return-Path:, and theAuthentication-Results:header. - Compare the domains. Note which are yours and which belong to your sending service.
The Authentication-Results header post shows how to read the verdicts, and tracing delivery with Received headers helps when the path itself looks odd.
Common mistakes
- Using a free-mail address in From for business mail. Providers apply strict policies to some of those domains, and a message sent through another service will fail DMARC.
- Pointing Reply-To at a domain you do not control. It looks like a redirect attack.
- Ignoring bounces. If the bounce address goes nowhere, you never learn which recipients are invalid. See hard and soft bounces.
- Assuming a pass means safe. Passing SPF for any domain is not the same as the From being trustworthy.
Key takeaways
- The header From is what people see and what DMARC anchors to.
- The envelope sender (saved as Return-Path) is where bounces go and what SPF checks.
- Reply-To only decides where replies are sent; it proves nothing about identity.
- DKIM names a signing domain; DMARC passes when SPF or DKIM passes for a domain that aligns with the From.
- When something fails, compare the four addresses first.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
