The Return-Path header

Return-Path shows the envelope sender: the address the sending server gave in the SMTP MAIL FROM command, which is where bounce messages go. Your receiving server copies it into the header at final delivery. It's often different from the From address you see, and for newsletters, receipts and anything sent through a mail service that difference is normal: the service uses its own bounce address so it can process failures. A mismatch matters only when it comes with failing authentication, or when the Return-Path domain has nothing to do with the claimed sender and nothing else aligns.

Return-Path: <bounces+8812-ab3f-alex=example.com@em123.example.net>
From: Example Store <orders@example.com>

Two "from" addresses, by design

Every email has two sender addresses, set separately:

• The envelope sender (also called MAIL FROM, RFC5321.MailFrom, reverse-path, bounce address or P1 sender). It's part of the SMTP conversation, not the message. RFC 5321 §2.3.1 describes it as the address error reports should go to, and §3.3 shows it as the argument to the MAIL FROM: command.
• The header From (RFC5322.From, P2 sender). It's part of the message itself and is what your mail app displays.

They can legitimately differ, and the SMTP spec says outright that a return path differing from the author's mailbox is common and useful, for example with mailing lists (RFC 5321 §4.4).

How Return-Path gets into the header

Servers along the way don't write Return-Path. When the final server delivers the message into a mailbox, it adds a Return-Path: line recording the envelope sender (RFC 5321 §4.4). The message format spec groups it with Received: as a trace field (RFC 5322 §3.6.7). So:

• The Return-Path you see was written by your own provider, recording what the last SMTP client said in MAIL FROM. That makes it reliable as a record of the envelope, even though the sender chose the value.
• There should be exactly one. Senders aren't supposed to include it when they send, and the delivering server may remove any that were already there before adding its own (RFC 5321 §4.4). If you see several, the extra ones were probably added by a forwarder or are leftovers from a message being re-sent.

Return-Path: <> (empty) is the null sender. It's required for bounce messages and other automatic notifications, so that a failed bounce doesn't trigger another bounce (RFC 5321 §4.5.5). Seeing <> on a delivery failure notice or a read receipt is correct. On a regular marketing or personal message, it's odd.

Why newsletters and services use a different Return-Path

When a company sends through an email service provider, the service needs bounces to come back to its systems so it can mark dead addresses and stop mailing them. So the envelope sender points at the service, often with a domain the service controls or a subdomain the customer delegated to it:

Return-Path: <0100019a2b3c4d5e-6f7a@bounces.example.net>
Return-Path: <bounce-123_HTML-456@bounce.mail.example.com>

Many services also use VERP (variable envelope return path): they encode the recipient, or a message ID, in the local part of the bounce address, as in the bounces+8812-ab3f-alex=example.com@… example above. When a bounce comes back, the address alone says which recipient failed, even if the bounce message itself is unreadable. Long, random-looking Return-Path local parts are usually VERP, not something suspicious.

Mailing lists do the same thing. A list rewrites the envelope sender to its own bounce address, so a dead subscriber address bounces to the list software rather than to the person who posted. See forwarding and mailing lists.

How Return-Path relates to SPF

SPF checks the envelope sender's domain. The receiving server looks up the SPF record of the MAIL FROM domain and asks whether the connecting IP is allowed to send for it (RFC 7208 §2.4). So when you see spf=pass smtp.mailfrom=bounces.example.net in Authentication-Results, that's about the Return-Path domain, not the From domain.

With a null sender (<>), SPF checks postmaster@ the HELO name instead (RFC 7208 §2.4).

This is why SPF alone doesn't stop From-address spoofing. An attacker can send with a Return-Path at their own domain, pass SPF for it, and put anything they like in From. Received-SPF lines show the same check in more detail.

How Return-Path relates to DMARC

DMARC closes that gap with alignment. For SPF to count toward a DMARC pass, the domain SPF authenticated, which is the MAIL FROM domain, must align with the From domain (RFC 9989 §4.4.2). DMARC is now specified in RFC 9989 (May 2026), which replaced the original RFC 7489.

• Relaxed alignment (the default): both domains share the same organizational domain. bounce.mail.example.com aligns with example.com (RFC 9989 §3.2.10).
• Strict alignment: the domains must be identical.

That's why careful senders set up a custom bounce domain such as bounce.example.com with their mail service: it makes SPF align. Plenty of legitimate senders don't, and they rely on an aligned DKIM signature instead. DMARC passes if either SPF or DKIM passes with alignment, so a non-aligned Return-Path is fine as long as DKIM aligns. The DMARC alignment guide goes through the details.

When a mismatch is normal, and when it's a red flag

Normal:

• Newsletters, receipts, password resets and notifications sent through a mail service, with a Return-Path at the service's domain or a subdomain of the brand.
• Mailing list posts, where the Return-Path belongs to the list.
• Forwarded mail, where the forwarder may rewrite the envelope sender (for example with SRS, which produces addresses beginning SRS0=).
• Bounces and receipts with <>.

Worth a closer look:

• The Return-Path is at an unrelated, odd-looking domain, the From claims a well-known organization, and DMARC failed or there's no aligned DKIM signature.
• The Return-Path domain is a look-alike of the From domain, such as examp1e.test beside example.test. Somebody went to the trouble of making the two look related.
• The Return-Path is a free webmail address while the From claims to be a company, and authentication didn't pass for the From domain.

In each case it's the combination that matters. The mismatch by itself isn't evidence, because so much legitimate mail has one.

Tip: The analyser flags a Return-Path whose domain differs from the From domain and, next to it, shows whether SPF and DKIM aligned. If an aligned DKIM signature passed, the mismatch is almost certainly just how the sender's mail service works.