Return-Path

The Return-Path is the envelope sender of an email — the address supplied in the SMTP MAIL FROM command as the reverse-path, defined in RFC 5321 §3.3. Per RFC 5321, "the <reverse-path> portion of the first or only argument contains the source mailbox … which can be used to report errors." In other words, it is the address a receiving server sends a bounce (Delivery Status Notification) back to when a message cannot be delivered. It is also commonly called the envelope-from, bounce address, or RFC5321.MailFrom.

A message therefore carries two distinct "from" identities: the envelope sender (Return-Path / MAIL FROM), used by mail servers for routing and error reporting, and the header From:, defined in RFC 5322 §3.6.2, which is what the recipient sees in their mail client. The two can legitimately differ, and for bulk email they usually do.

The name "Return-Path" applies to both a protocol value and a header, and it helps to keep them separate:

• The envelope value is transient — it lives only in the MAIL FROM exchange during the SMTP session and is not part of the message body.
• The Return-Path header is persisted at the very end of the journey. Per RFC 5321 §4.4 (Trace Information), when the delivery SMTP server makes the final delivery of a message, it prepends a Return-Path: line to the top of the message, copying in the reverse-path from the MAIL FROM command. This is a trace field in the RFC 5322 §3.6.7 sense.

A practical consequence: a sending system sets the envelope, but the receiving system writes the header. Setting a Return-Path: header yourself before sending is incorrect — the receiver strips and rewrites it — which is a frequent source of confusion.

Because the envelope sender is where non-delivery reports go, it is the anchor of all bounce handling. A relay that cannot deliver a message "MUST construct an 'undeliverable mail' notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)" (RFC 5321 §3.6.3).

The bounce notification itself is sent with an empty reverse-path — the null reverse-path, written MAIL FROM:<> — precisely so that a bounce of a bounce cannot create an infinite loop (RFC 5321 §3.6.3). If you ever see MAIL FROM:<> in a log, it is almost always a DSN or an auto-reply, not spam.

Bulk senders often encode the original recipient into the envelope sender using VERP (Variable Envelope Return Path), e.g. [email protected], so an incoming bounce can be attributed to the exact address that failed without parsing the body.

SPF does not authenticate the visible From: header — it authenticates the envelope sender domain (the MAIL FROM / Return-Path domain, RFC5321.MailFrom). This is why a message can show From: [email protected] yet pass SPF against an ESP's own bounce domain: the receiver is checking the envelope, not the header.

DMARC then closes the gap the two identities open up. DMARC requires alignment: the SPF-authenticated RFC5321.MailFrom domain (or a DKIM-signed domain) must match the visible RFC5322.From domain, at either the organisational level (relaxed) or exactly (strict), per RFC 7489 §3.1. A common deliverability failure is SPF passing on the ESP's Return-Path domain while failing DMARC alignment because that domain does not match the brand's From-domain — which is why senders configure a custom Return-Path (a subdomain of their own From-domain) at the ESP.

AcelleMail can set a custom envelope sender per sending server so that bounces route to an inbox it polls. The capability is gated by a marker interface, app/SendingServers/Capabilities/SupportsCustomReturnPath.php — "vendor accepts a custom Return-Path / VERP envelope sender (used by bounce-handler IMAP polling)." Only drivers that implement it (currently the generic SMTP and sendmail drivers) receive a custom Return-Path; vendor-API drivers that manage their own bounce feedback do not.

At send time, app/Library/Traits/HasEmailTemplate.php checks the driver and, if it supports a custom Return-Path, calls SendingServer::getVerp($subscriber->email) and applies it via the Symfony Mailer Email::returnPath() setter. The getVerp() method (app/Model/SendingServer.php) derives the envelope address from the server's configured bounce-handler mailbox. Incoming DSNs to that mailbox are parsed by BounceHandler, classified as hard or soft, and recorded — closing the loop from envelope sender to blacklist decision.