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

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:

Microsoft uses the same vocabulary. Its DMARC guide 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. Sender names the mailbox that actually sent a message on someone else's behalf. RFC 5322, section 3.6.2 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.

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 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 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 treats Return-Path as a trace field alongside Received headers. Our guide on 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).
• 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 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 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:

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 covers relaxed and strict modes in detail, and 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. Bounces sent to you for mail you never sent are backscatter.

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 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). 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).

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 lays these fields side by side and runs in your browser. For Microsoft 365 mail, the Microsoft 365 Header Analyzer also decodes Microsoft's anti-spam headers. Look-alike tricks in the visible From are covered in 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 on any custom bounce subdomain you create.
• Paste suspicious messages into the free Email Header Analyzer before you reply or click.

Browse our other SPF, DKIM and DMARC guides.