An email seems to have one sender, but a message actually carries several addresses that look similar and do very different jobs. There is the address that appears in the "From" line in your mail client. There is another address, often invisible, that the sending server gave to the receiving server in the SMTP conversation, and that ends up in a header called Return-Path. There is the address that is used when you click "Reply", which may be a third one. And there are less common ones, such as Sender. Mixing them up produces a long list of everyday problems: bounces that disappear into a mailbox nobody reads, SPF passing while DMARC fails, "via" labels in Gmail, rejected mail with a message about the sender not being allowed, contact forms that cannot be authenticated. This guide explains each address, shows where you can see them, says which one each authentication method checks and gives concrete advice on how to set them in applications and sending services.
The envelope and the letter
The postal analogy fits well. An SMTP transaction has an envelope: the sender given in the MAIL FROM command and the recipients given in RCPT TO. The envelope is used by mail servers to route the message and to report problems, and it is not shown to the reader. Inside the envelope is the letter: the message headers and body, including the From, To and Subject lines that the reader sees. The two sets of addresses are independent. The envelope recipient may differ from the To header (this is how Bcc works), and the envelope sender may differ from the From header (this is how sending services and mailing lists work). When delivery finishes, the receiving server writes the envelope sender into the message as the Return-Path header, so you can see it afterward.
The addresses compared
| Address | Where it is set | Who sees it | What uses it |
|---|---|---|---|
| Envelope sender (MAIL FROM, bounce address) | SMTP command from the sending server | Receiving servers; saved as Return-Path | Bounces and delivery status notifications; SPF evaluation |
| Return-Path | Added by the final receiving server from the envelope sender | Visible in full headers | Shows the bounce address; SPF alignment for DMARC |
| From (header) | Message header written by the sending application | The reader, in the mail client | DMARC (the domain is the identity protected); user recognition |
| Reply-To | Message header | Used by the client when the reader replies | Directs replies; not checked by SPF, DKIM or DMARC |
| Sender | Message header, optional | Some clients show "on behalf of" | Identifies the agent who sent it when different from From |
| Resent-From and similar | Added when a message is resent | Full headers | Records a resend and who did it |
| DKIM d= domain | In the DKIM-Signature header | Full headers; clients may show "signed by" | DKIM verification; DMARC alignment |
Where bounces go
When a message cannot be delivered, the receiving system or a server along the way sends a delivery status notification to the envelope sender, not to the From address. If your application uses its own address as the envelope sender, the bounces arrive in that mailbox. If you use a sending service, the envelope sender is normally an address at the service's domain or at a bounce subdomain you configured, so the service can read the bounces, classify them and remove bad addresses from your list. That is why you can send from [email protected] and never see a bounce in the mailbox. Reading and handling these automatically is covered in suppression list management and hard and soft bounces. An envelope sender that is empty (MAIL FROM:<>) is used for bounces themselves, so that bounces of bounces cannot loop.
Which address does each authentication method check?
| Method | What it checks | Aligned with From for DMARC when |
|---|---|---|
| SPF | The domain of the envelope sender (and the HELO name if the envelope sender is empty), against the IP that connected | The envelope sender domain matches the From domain (relaxed: same organisational domain) |
| DKIM | The signature in the message, identified by the d= domain | The d= domain matches the From domain (relaxed: same organisational domain) |
| DMARC | Whether SPF or DKIM passed and aligned with the domain in the From header | At least one of them does |
This is the key point. SPF looks at the envelope, DMARC cares about the From header, and the two are compared by alignment. A sending service that uses its own domain as the envelope sender will pass SPF (for its domain) but not SPF alignment for your From domain. DMARC will then depend on DKIM alignment. Setting up a custom return path on your own domain, where the service gives you a bounce subdomain such as bounce.yourdomain.com to publish, makes SPF align as well. See custom return path and tracking domains and DMARC alignment explained.
Reading them in a real message
Open the full headers of any received message. Look for Return-Path: near the top (added last, so it appears first), then From:, Reply-To: and, if present, Sender:. In the authentication results, look at smtp.mailfrom= (the envelope sender domain, used by SPF) and header.from= (the From domain, used by DMARC), and header.d= (the DKIM signing domain).
Return-Path: <[email protected]>
From: Example Store <[email protected]>
Reply-To: [email protected]
Authentication-Results: mx.recipient.net;
spf=pass smtp.mailfrom=bounce.example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comHere the bounce address is on a subdomain of the From domain. SPF passes for bounce.example.com, which aligns with example.com under relaxed alignment, and DKIM passes with example.com. DMARC passes twice over. Our guide on reading email headers shows where to find these lines in each mail client.
Reply-To: useful, and harmless to authentication
The Reply-To header says where replies should go. It has no effect on SPF, DKIM or DMARC, which makes it the right place for an address that differs from the sender. A support team can send from a notification address and set Reply-To: [email protected]. A contact form can send from an address on your own domain, which is authenticated, and put the visitor's address in Reply-To, so that you can reply to them directly. The common mistake is to do the opposite and put the visitor's address in From. The message then claims to come from a domain you do not control, your server is not authorised to send for it, SPF and DKIM do not align and DMARC fails. If the visitor's domain publishes a reject policy, the message is refused. Use a fixed From on your own authenticated domain and Reply-To for the visitor. Some servers also reject the other approach outright with a "sender not owned by user" reply; see SMTP error 553.
The Sender header and the "via" label
RFC 5322 defines a Sender header for the case where the agent who sends the message differs from the author named in From, for example a secretary sending on behalf of a manager. Some clients show this as "on behalf of". Mailbox providers also display a "via" or "mailed-by" label when the domain that authenticated the message differs from the From domain, which is the usual sign of a service that has not been fully set up for your domain. The label disappears when SPF or DKIM aligns with the From domain. The full explanation is in what "via" means in Gmail.
Setting the addresses correctly
| Goal | Do this |
|---|---|
| Mail that passes DMARC | Use a From address on a domain you control; sign with DKIM using that domain; set up a custom return path on a subdomain of it |
| Bounces handled automatically | Use the bounce address provided by your sending service as the envelope sender; do not override it with a mailbox you read by hand |
| Replies to a person or team | Set Reply-To to that address; leave From as the authenticated sender |
| A contact or lead form | Fixed From on your domain; the visitor in Reply-To; never the visitor in From |
| Sending on behalf of a client | Prefer a From on your client's authenticated domain with their DKIM; avoid spoofing; use Reply-To for their address |
| A mailing list or forwarder | Keep the original From where possible; ARC helps downstream receivers; see ARC explained |
| Domains that never send | Publish an SPF and DMARC reject policy; see parked and non-sending domains |
How to set them in code
Most libraries distinguish the three values. In PHPMailer, setFrom($address) sets the From header and, by default, the envelope sender, and Sender overrides the envelope sender separately; addReplyTo() sets Reply-To. In Python, smtplib.sendmail(from_addr, to_addrs, msg) takes the envelope sender as the first argument, while the headers in msg define the From and Reply-To. In Nodemailer, the envelope option sets the envelope separately from the from and replyTo options. In sending services, the envelope sender is chosen by the service. See the language guides: PHP, Python, Node.js and Django. Whatever the language, test by sending to a mailbox where you can read the headers and confirm which address appears in each place.
Common problems and their cause
| Symptom | Cause | Fix |
|---|---|---|
| SPF passes but DMARC fails | Envelope sender domain is the service's, not aligned with From | Set up DKIM on your domain and a custom return path |
| No bounces ever arrive | Bounces go to the service or to an unread mailbox | Use the service's reports or webhooks |
| Replies go to the wrong person | Reply-To is missing or points to the wrong address | Set Reply-To explicitly |
| Gmail shows "via" another domain | Authentication aligns with the service domain only | Complete domain authentication |
| Server says sender not allowed | From does not belong to the authenticated account | Use a verified From; see verifying your domain |
| Mail from a form is rejected | Visitor address used as From | Use a fixed From and Reply-To |
Set up your sender identity once Verify your domain, get aligned DKIM and a custom return path, and send from any address on it.
References and further reading
Frequently asked questions
What is the difference between Return-Path and From?
Return-Path is the envelope sender, where bounces go and what SPF checks. From is the address the reader sees and the identity that DMARC protects.
Does Reply-To affect SPF, DKIM or DMARC?
No. Reply-To only controls where replies go, which makes it the safe place for a different address.
Why do bounces not come to my From address?
They go to the envelope sender. A sending service uses its own or a bounce subdomain address so it can process bounces automatically.
Which address does SPF check?
The domain of the envelope sender (MAIL FROM), or the HELO name if the envelope sender is empty.
Should a contact form use the visitor email as From?
No. Use a fixed From on your authenticated domain and put the visitor in Reply-To, otherwise authentication and DMARC fail.