InboxRatio
Check your domain

Glossary term

Return-path: the address the envelope carries

What the return-path is

The return-path is the envelope sender of an email: the address announced in the MAIL FROM command of the SMTP transaction, before any message content is transmitted. RFC 5321 calls it the reverse-path and gives it one canonical job — it is where delivery failure reports go. When the receiving server accepts the message for final delivery, it stamps the value into a Return-Path: header, which is where you can read it afterward.

Two more jobs have since attached themselves to the same address, and they are why the return-path matters far beyond bounce handling. It is the domain SPF validates under RFC 7208, and it is one of the two identifiers DMARC can align with the visible sender under RFC 7489. One envelope field, three roles: bounce destination, SPF identity, alignment candidate.

The vocabulary around it is a pile of synonyms worth flattening once: return-path, envelope-from, envelope sender, MAIL FROM, RFC5321.MailFrom, reverse-path and bounce domain (for its domain part) all name the same thing. Documentation switches between them freely; the mechanism underneath never changes.

How the return-path differs from the From header

An email carries two sender addresses because it operates on two layers.

The header From (RFC5322.From) lives inside the message content. It is what mailbox interfaces display, what recipients reply to by default, and what your brand identity attaches to. Nothing in SMTP validates it; it is content, like the subject line.

The return-path (RFC5321.MailFrom) lives in the transmission envelope, outside the content. Servers negotiate it, bounce processing consumes it, and SPF is evaluated against it. Recipients never see it unless they open raw headers.

The two frequently differ by design. Mail sent through an ESP typically shows your brand in the From header while carrying the provider's (or your delegated subdomain's) address in the envelope, so that bounces flow into automated processing instead of a human mailbox. Mailing lists do the same: the list rewrites the return-path to itself so it, not the original author, receives the failures.

This split is also the security gap DMARC exists to close. Since SPF only ever vouches for the envelope domain, a message can pass SPF cleanly while displaying any From address at all. SPF alignment is DMARC's demand that the passing envelope domain and the visible From domain match before the pass counts.

How the return-path works

The envelope exchange happens in the opening seconds of delivery:

MAIL FROM:<bounce-7f3k9@b.yourbrand.com>
RCPT TO:<reader@example.com>
DATA

Everything after DATA is content, including the From: header. The receiving server evaluates SPF at the MAIL FROM step, against the domain b.yourbrand.com in this example, and on acceptance writes Return-Path: <bounce-7f3k9@b.yourbrand.com> onto the delivered message.

If delivery later fails, the failure report travels to that address. Sending platforms exploit this with VERP, variable envelope return paths: each recipient gets a unique local part, so the returning hard bounce or soft bounce identifies the failed address mechanically, without parsing whatever format the remote server used for its report.

One special value is load-bearing: the null return-path, written MAIL FROM:<>. RFC 5321 requires bounce messages themselves (and similar automated notifications) to use it, precisely so that a bounce which itself bounces cannot start an infinite loop of failure reports answering failure reports. A server that refuses null-sender mail outright rejects legitimate bounces and breaks the feedback that list hygiene runs on.

Reading your own return-path takes one delivered message: open the raw source and find the Return-Path: header, or let the email header analyzer parse it alongside the Authentication-Results that show whom SPF passed for.

The return-path and your deliverability

The return-path decides whose SPF record your mail is judged against, which makes it the hinge of the SPF half of DMARC. The Gmail bulk-sender requirements demand that the From domain align with the SPF or DKIM domain, and Yahoo's requirements state DMARC must pass outright. A return-path on your provider's default domain produces SPF passes that satisfy neither, leaving DKIM as your only aligned mechanism. The fix is the custom return-path, a CNAME that puts the envelope on your own subdomain — covered in detail under bounce domain.

The return-path domain also accrues history. Receivers see it on every message and fold it into domain reputation; an envelope domain you own concentrates that history on your identity instead of a shared provider domain.

And the bounce-routing role feeds the metric loop. Bounces returning to a processed return-path become suppression entries; bounces returning to an unmonitored address become repeat sends to dead mailboxes, which receivers read as a sender who is not listening. The envelope is where that listening physically happens.

Limitations and failure modes

Judging authentication by the From header. The evergreen confusion: teams check SPF for the domain in the From header, see a valid record, and conclude all is well while the envelope carries a different domain entirely. Every SPF question starts with "what is the return-path?" — asked of a real delivered message, not of assumptions.

The provider-default envelope. SPF passes for years, for the ESP, and the gap surfaces only when DMARC enforcement makes alignment material. One Return-Path: header read today is cheaper than the incident later; the DMARC checker covers the record side.

Forwarding rewrites the envelope. Forwarders implementing SRS (Sender Rewriting Scheme) replace your return-path with their own so that SPF can pass at the next hop and bounces route back through them. Consequence: on forwarded mail your SPF identity is simply gone, and alignment with it. This is by design and unfixable from your side — aligned DKIM is the mechanism that survives the trip.

Blocking the null sender. Anti-spam configurations that reject MAIL FROM:<> also reject the bounce reports your own hygiene depends on, and violate the RFC in the process. The null return-path is infrastructure, not a spam tell.

Reply-To confusion. The return-path is not where replies go; human replies follow Reply-To: or the From header. Configuring a return-path address as if customers would write to it, or monitoring it by hand, misunderstands the layer — that mailbox belongs to machines.

One envelope for everything. Routing marketing, transactional and corporate mail through a single return-path domain entangles their bounce streams and their SPF identity. Separate subdomains per stream keep failures diagnosable and reputations independent.

Related terms

Bounce domain, SPF record, SPF alignment, DMARC, SMTP, hard bounce, soft bounce, DKIM selector, domain reputation.

Frequently asked questions

Is the return-path the same as the bounce domain? The return-path is the full envelope address; the bounce domain is its domain part, and in practice the terms are used interchangeably. Both name the identity SPF checks and the destination bounces return to.

Where do I see the return-path of an email? In the raw source of a delivered message, as the Return-Path: header the receiving server stamped at delivery — or parsed for you by the email header analyzer. It is not shown in normal mailbox interfaces.

Why is my return-path different from my From address? Almost certainly because a sending platform routes your bounces through its processing infrastructure. That is normal and useful; the question that matters is whether the return-path domain is a delegated subdomain of yours (aligned) or the provider's own (unaligned).

Does the return-path affect SPF? It does not just affect SPF — it defines it. RFC 7208 evaluates the connecting IP against the SPF record of the return-path domain. The From header plays no part in SPF; it only re-enters through DMARC's alignment comparison.

What is a null return-path and is it spam? MAIL FROM:<> is the RFC-mandated envelope for bounces and automated notifications, chosen so failure reports cannot loop. Legitimate infrastructure mail uses it constantly; treating it as inherently suspicious breaks bounce handling.

Can I set the return-path myself? Through most platforms, yes, under the name "custom return-path", "bounce domain" or "SPF domain": you publish a CNAME on a subdomain and the platform uses it as your envelope. Senders running their own MTAs set it directly in the MTA configuration.

Pull the raw source of the last campaign you sent and read two lines: Return-Path: and Authentication-Results. Together they tell you whose identity your SPF runs on — and if the answer is not your domain, the SPF checker and one provider setting will change it.

Sources