# Return-Path vs From address: what's the difference?

URL: https://iblockspam.com/blog/return-path-vs-from-address
Last updated: 2026-11-03
Published: 2026-11-03
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> The From address is the author you see; the Return-Path is the hidden envelope sender where bounces go. How each is set, what SPF and DMARC check, when to worry.

## Short answer

The From address is the author shown in your mail app (RFC 5322.From). The Return-Path is the envelope sender from the SMTP MAIL FROM command (RFC 5321.MailFrom), where bounces go; the receiving server writes it into the header. SPF checks the Return-Path domain, DMARC checks the From domain, and the two can differ legitimately.

Every email carries two sender addresses. One is the From address your mail app shows. The other, the Return-Path, is usually hidden and often on a completely different domain. Knowing which is which explains why SPF can pass while DMARC fails, why newsletters show odd bounce addresses, and when a mismatch should worry you.

## What is the difference between Return-Path and From?

The From address names the author of a message and is what readers see; the Return-Path is the envelope sender address that mail servers use to return bounces, and it is normally hidden. They are set at different stages of sending and checked by different authentication methods: SPF checks the Return-Path domain, while DMARC protects the From domain.

The two addresses have several names, which is half the confusion:

| | From address | Return-Path |
|---|---|---|
| Other names | Header From, 5322.From, P2 sender, author address | Envelope sender, envelope from, MAIL FROM, 5321.MailFrom, P1 sender, bounce address |
| Defined in | [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322.html) (message format) | [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321.html) (SMTP) |
| Set by | The sender's mail app or platform, in the message header | The sending server, in the SMTP `MAIL FROM` command |
| Shown to readers? | Yes | No, unless they open the headers |
| Used for | Showing who wrote the message; replies if there's no Reply-To | Returning bounces and delivery errors |
| Checked by | DMARC (and DKIM alignment) | SPF |
| Often different domain? | It's your domain | Often the sending platform's bounce domain |

Microsoft uses the same vocabulary. Its [DMARC guide](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure) calls the MAIL FROM address "the email address used in the transmission of the message between SMTP email servers. This address is also known as the 5321.MailFrom address, P1 sender, or envelope sender," and the From address "the email address in the From header field shown as the message sender in email clients," also "known as the 5322.From address or P2 sender."

Two more addresses often appear alongside them. **Reply-To** is where a reply goes, and attackers abuse it; see [Reply-To mismatch phishing](https://iblockspam.com/blog/reply-to-header-mismatch-phishing). **Sender** names the mailbox that actually sent a message on someone else's behalf. [RFC 5322, section 3.6.2](https://www.rfc-editor.org/rfc/rfc5322.html) gives the example of a secretary sending a message for another person: the secretary's mailbox goes in the Sender field and the author's in the From field.

## What is the email envelope?

The email envelope is the set of addresses exchanged in the SMTP conversation before the message itself is sent: the envelope sender (`MAIL FROM`) and the recipients (`RCPT TO`). Like a paper letter, the envelope is what the postal system reads; the letter inside, with its own letterhead and signature, is what the reader sees. The two don't have to match. You can watch a real envelope being exchanged by [testing an SMTP server with telnet or OpenSSL](https://iblockspam.com/blog/test-smtp-server-telnet-openssl).

Here is an illustrative SMTP session for a newsletter. The envelope sender is on the platform's bounce domain; the From header inside the message is on the company's domain:

```
S: 220 mx.recipient.example ESMTP
C: EHLO out12.mailplatform.example
C: MAIL FROM:<b-7f3a9c@bounce.mailplatform.example>
C: RCPT TO:<alex@recipient.example>
C: DATA
C: From: "Example Store" <news@example.com>
C: To: alex@recipient.example
C: Subject: Your November offers
C: ...
```

[RFC 5321, section 3.3](https://www.rfc-editor.org/rfc/rfc5321.html) says the reverse-path in `MAIL FROM` "contains the source mailbox ... which can be used to report errors." If the message can't be delivered later, a relay must "send it to the originator of the undeliverable mail (as indicated by the reverse-path)," not to the From address.

## Who sets the Return-Path header?

The Return-Path header is written by the receiving server that makes final delivery, which copies the envelope sender from the `MAIL FROM` command into the top of the message. The sender doesn't write it. [RFC 5321, section 4.4](https://www.rfc-editor.org/rfc/rfc5321.html) says the delivery server "inserts a return-path line at the beginning of the mail data", and that "a message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field."

So when you open the headers of a message you received, the `Return-Path:` line shows the envelope sender as your own server saw it on the last hop:

```
Return-Path: <b-7f3a9c@bounce.mailplatform.example>
```

That makes the Return-Path more trustworthy than most headers, but only as a record of the last hop. RFC 5321 also allows that "any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed," so a forwarded message may show the forwarder's bounce address. [RFC 5322, section 3.6.7](https://www.rfc-editor.org/rfc/rfc5322.html) treats Return-Path as a trace field alongside Received headers. Our guide on [how to read email headers](https://iblockspam.com/blog/how-to-read-email-headers) shows where it sits among the others.

## Why is the Return-Path different from the From address?

The Return-Path is usually different from the From address because the bounce address has a different job: it must reach a system that processes bounces automatically, not a person. Email platforms set the envelope sender to their own bounce domain so they can catch failures, mark dead addresses and stop mailing them.

Common reasons you'll see a difference:

- **Email service providers.** Amazon SES says messages "automatically use a subdomain of amazonses.com as the default MAIL FROM domain" unless you configure your own ([Amazon SES](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html)).
- **Per-message bounce addresses.** Many platforms encode a recipient or message ID into the Return-Path, as in `b-7f3a9c@...` above, so a bounce identifies exactly which address failed. This is called VERP (variable envelope return path).
- **A custom bounce subdomain.** Platforms let you replace their bounce domain with your own subdomain, such as `bounce.example.com`, while From stays `news@example.com`.
- **Mailing lists and forwarding.** RFC 5321 section 3.9.2 notes that for mailing lists, "error messages generated by the final deliveries will be returned to a list administrator", so lists rewrite the envelope sender to their own address.

None of these are suspicious in themselves. A different Return-Path is the normal state for most bulk and automated mail.

## How does the Return-Path affect SPF and DMARC?

SPF authenticates the Return-Path domain, and DMARC passes on SPF only if that Return-Path domain aligns with the From domain. That is why a message can show `spf=pass` and still fail DMARC.

[RFC 7208, section 1.1.3](https://www.rfc-editor.org/rfc/rfc7208.html) defines the SPF "MAIL FROM" identity as "the RFC5321.MailFrom (reverse-path) identity." The receiver looks up the SPF record of the domain in the envelope sender, not the From address. For DMARC, [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) says "DMARC relies solely on SPF validation of the MAIL FROM identity," and defines the domain it protects, the Author Domain, as the one "extracted from the RFC5322.From header field." It then requires identifier alignment: the authenticated domain must match the From domain, either exactly (strict) or at the organizational-domain level (relaxed, the default).

Here's how common combinations work out under relaxed alignment:

| From | Return-Path domain | SPF result | SPF aligned for DMARC? |
|---|---|---|---|
| `news@example.com` | `example.com` | pass | Yes |
| `news@example.com` | `bounce.example.com` | pass | Yes (same organizational domain) |
| `news@example.com` | `bounce.mailplatform.example` | pass | No: DMARC needs aligned DKIM instead |
| `news@example.com` | `example.com`, sent from a server not in SPF | fail | No |
| `ceo@example.com` (spoofed) | `attacker.example` | pass for the attacker's domain | No: DMARC fails unless DKIM aligns |

The last row is the reason DMARC exists. An attacker can easily pass SPF for a domain they own while putting your domain in the From address. Microsoft's troubleshooting example shows the legitimate version of the same pattern, with `smtp.mailfrom=bounces.adatum.com` and `header.from=contoso.com` producing `dmarc=fail` because neither SPF nor DKIM aligned. The [DMARC alignment guide](https://iblockspam.com/blog/dmarc-alignment-relaxed-vs-strict) covers relaxed and strict modes in detail, and [why DMARC fails](https://iblockspam.com/blog/why-dmarc-fails) lists the other causes.

You don't need SPF alignment if DKIM aligns. DMARC passes when either one passes and aligns, and DKIM survives forwarding better than SPF.

### What happens when the Return-Path is empty?

An empty Return-Path, `<>`, is how bounces and other delivery status notifications are sent. RFC 5321 section 4.5.5 says they are "required by existing and proposed Standards to be sent with a null reverse-path," and section 6.1 says a server "MUST NOT send a notification" about a message whose return address is null, which prevents bounce loops. For SPF, RFC 7208 section 2.4 then uses the mailbox made of the local-part `postmaster` and the HELO identity. The HELO name itself is explained in [HELO and EHLO host names](https://iblockspam.com/blog/helo-ehlo-hostname-explained). Bounces sent to you for mail you never sent are [backscatter](https://iblockspam.com/blog/backscatter-spam-bounce-messages).

## How do I set up a custom Return-Path domain?

You set up a custom Return-Path domain by choosing a subdomain of your domain in your sending platform's settings and publishing the DNS records the platform gives you, usually an MX record for bounces and an SPF record or a CNAME. This makes SPF align with your From domain.

Amazon SES is a well-documented example, at the time of writing (November 2026):

1. **Pick a dedicated subdomain**, such as `bounce.example.com`. Amazon says it "shouldn't be a subdomain that you also use to send email from" or "to receive email."
2. **Enter it in the platform.** In SES this is the **Custom MAIL FROM domain** pane of the verified identity.
3. **Publish the MX record** the platform shows, for SES `10 feedback-smtp.<region>.amazonses.com`. Amazon requires "exactly one MX record" on that subdomain.
4. **Publish the SPF record** for the subdomain, for SES `"v=spf1 include:amazonses.com ~all"`.
5. **Wait for verification.** Amazon says detection can take "up to 72 hours".
6. **Confirm** by sending a test message and checking that the Return-Path now uses your subdomain and that SPF passes and aligns.

Other platforms use different records for the same job. SendGrid's domain authentication, for example, creates a CNAME for a subdomain that "handle[s] bounce and unsubscribe notices." Follow your platform's own documentation, and add the subdomain to your inventory so you can remove it if you leave. [Authenticating third-party senders](https://iblockspam.com/blog/authenticate-third-party-senders-spf-dkim-dmarc) covers the full SPF, DKIM and DMARC setup for outside services.

## Is a Return-Path mismatch a sign of phishing?

A Return-Path that differs from the From domain is not a sign of phishing by itself, because most legitimate bulk mail has one. It becomes meaningful only alongside other evidence: a DMARC failure, no DKIM signature or one from an unrelated domain, a look-alike From domain, or a Reply-To that sends your answer somewhere else.

Gmail surfaces part of this for you. Google says it shows "via" and a website name next to a sender's name when "the domain it was sent from doesn't match the domain in the 'From:' address" ([Gmail Help](https://support.google.com/mail/answer/1311182)). On a computer, the Down arrow below the sender's name shows a "Mailed by" domain and a "Signed by" domain when the message is authenticated ([Gmail Help](https://support.google.com/mail/answer/180707)).

When you're checking a suspicious message, look at all the identities together:

1. **Open the full headers** (in classic Outlook for Windows, open the message, then **File** > **Properties**; in Gmail, **More** > **Show original**).
2. **Read Return-Path and From.** Note both domains.
3. **Read Authentication-Results.** Find `smtp.mailfrom=` (the Return-Path domain SPF checked), `header.d=` (the DKIM signing domain) and `header.from=`.
4. **Check `dmarc=`.** A pass means at least one of SPF or DKIM aligned with the From domain. A fail on a message claiming to be from a known company is a strong warning.
5. **Check Reply-To.** If it points to a free mailbox or unrelated domain, treat the request as suspect.
6. **Verify by another channel** before acting on any payment or credential request.

The [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) lays these fields side by side and runs in your browser. For Microsoft 365 mail, the [Microsoft 365 Header Analyzer](https://iblockspam.com/tools/microsoft-365-header-analyzer) also decodes Microsoft's anti-spam headers. Look-alike tricks in the visible From are covered in [display name spoofing](https://iblockspam.com/blog/display-name-spoofing).

## Next steps

- Check what your own mail looks like: send a message from each service you use to an outside mailbox and compare Return-Path, From and the `smtp.mailfrom` domain.
- For each platform whose bounce domain isn't yours, set up DKIM signing with your domain, and a custom Return-Path where the platform supports it.
- Run the [SPF Checker](https://iblockspam.com/tools/spf-checker) on any custom bounce subdomain you create.
- Paste suspicious messages into the free [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer) before you reply or click.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### Should the Return-Path match the From address?

It doesn't have to match exactly, but its domain should share your organizational domain if you want SPF to count toward DMARC. bounce.example.com aligns with example.com under relaxed alignment. If your platform's bounce domain is its own, DMARC can still pass through aligned DKIM, so set up DKIM signing with your domain first.

### Can I see the Return-Path without opening the full headers?

Not in most mail apps, which show only the From and sometimes Reply-To. On a computer, Gmail's message details show a Mailed by domain and a Signed by domain on authenticated mail. For the exact Return-Path address, open the original message or full headers and look for the Return-Path line at the top.

### Is a different Return-Path domain a sign of phishing?

Not on its own. Newsletters, invoices and notifications sent through email platforms routinely use the platform's bounce domain. Treat it as a warning only together with other signs: DMARC fails, DKIM is missing or signed by an unrelated domain, or the From domain is a look-alike of a brand you know.

### What does Return-Path: <> mean?

An empty Return-Path means the message was sent with a null reverse-path, as RFC 5321 requires for bounce messages and other delivery status notifications. It stops bounces from bouncing back in a loop. SPF then checks the HELO host name instead, using postmaster at that host as the identity.

### Why does my email say sent via another domain in Gmail?

Gmail adds via and a website name when the domain the message was sent from doesn't match the domain in the From address, for example mail sent through a marketing platform. Google tells senders to publish SPF for the sending service, sign with DKIM associated with their domain, and make sure the From domain matches the domain used to authenticate.

## Sources

- [RFC 5321: Simple Mail Transfer Protocol, sections 3.3, 4.4, 4.5.5 and 6.1](https://www.rfc-editor.org/rfc/rfc5321.html)
- [RFC 5322: Internet Message Format, sections 3.6.2 and 3.6.7](https://www.rfc-editor.org/rfc/rfc5322.html)
- [RFC 7208: Sender Policy Framework (SPF), sections 1.1.3 and 2.4](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 9989: DMARC, sections 3.2.2, 3.2.4 and 4.4.2](https://www.rfc-editor.org/rfc/rfc9989.html)
- [Microsoft Learn: Set up DMARC to validate email in Microsoft 365](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure)
- [Amazon SES Developer Guide: Using a custom MAIL FROM domain](https://docs.aws.amazon.com/ses/latest/dg/mail-from.html)
- [Gmail Help: Extra info next to sender's name](https://support.google.com/mail/answer/1311182)
- [Gmail Help: Check if your Gmail message is authenticated](https://support.google.com/mail/answer/180707)

## Free tools for this guide

- [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer): Trace hops and authentication results — runs entirely in your browser.
- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [Microsoft 365 Spam Header Decoder](https://iblockspam.com/tools/microsoft-365-header-analyzer): Paste Microsoft 365 headers to decode SFV, CAT, SCL, BCL and compauth reason codes in plain English — runs in your browser.

---

Source: iBlockSpam, https://iblockspam.com/blog/return-path-vs-from-address (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt