relay
Get started free

Return-Path

TL;DR: The Return-Path is the email address that receives bounce messages. It is set by the sending mail server and is separate from the visible From address.

What is Return-Path?

The Return-Path is the email address that receives bounce messages and delivery status notifications.1 It is also called the envelope sender, bounce address, or MAIL FROM address.

The Return-Path is part of the SMTP specification in RFC 5321 and the message format in RFC 5322.

Why Return-Path matters

The Return-Path does two important jobs in email delivery:

Bounce handling

When a message cannot be delivered, the receiving server sends a bounce message (a delivery status notification) to the Return-Path address. Without a valid Return-Path, bounces go nowhere, and the sender never learns about delivery failures.

Bounce messages are important for list hygiene.2 If you send mail to an address that no longer exists, the bounce tells you to stop sending to that address. Sending to invalid addresses repeatedly damages your sender reputation.

SPF alignment

The Return-Path domain is the domain that SPF checks. The DMARC alignment check compares the Return-Path domain with the visible From domain. If they do not match (in relaxed mode, at the organizational domain level), the message fails DMARC alignment for SPF.

How Return-Path works

The envelope vs. the header

The Return-Path shows up in two places. In the SMTP envelope, the MAIL FROM command sets the envelope sender address. The recipient never sees it, but it drives bounce delivery and SPF checks. Separately, the receiving mail server adds a Return-Path header to the accepted message. That header holds the same envelope sender address.

The sender does not set the Return-Path header. The receiving server adds it.3 The sender only sets the envelope sender through the MAIL FROM command.

Example

A message might have these fields:

MAIL FROM: <bounce+019a8c26@bounces.example.com>   (envelope sender)
From: billing@example.com                           (visible header)
Return-Path: bounce+019a8c26@bounces.example.com   (added by receiver)

The recipient sees billing@example.com in the mail client. Bounce messages go to the tagged address. The SPF check uses bounces.example.com.

Bounce address tag verification (BATV)

Some senders use BATV (Bounce Address Tag Verification) to detect bounce forgery. BATV adds a cryptographic tag to the envelope sender address. When a bounce comes back, the sender verifies the tag. If the tag is missing or invalid, the bounce is forged and is discarded.

BATV is defined in IETF draft draft-levine-smtp-batv.4

DNS configuration

The bounce domain needs MX and SPF records. The MX record routes bounce messages back to the mail server. The SPF record authorizes the mail servers.

You do not need a separate DNS record for the Return-Path.

How to set up the Return-Path

  1. Choose a subdomain of your sending domain for the envelope sender, for example bounces.example.com.
  2. Publish an MX record for the subdomain so that bounce messages return to your mail server.
  3. Add the subdomain to your SPF record.
  4. Make sure that the envelope sender domain aligns with the visible From domain for DMARC.

A subdomain of the sending domain aligns under relaxed DMARC. Add a tag such as bounce+<message-id> to the local part to identify the original message from a bounce.

Further reading

  • RFC 5321: Simple Mail Transfer Protocol (Section 4.4: Trace information)
  • RFC 5322: Internet Message Format (Section 3.6.7: Return-Path)
  • RFC 3464: An Extensible Message Format for Delivery Status Notifications
  • SPF: Sender Policy Framework
  • DMARC: Domain-based Message Authentication, Reporting, and Conformance
  • SMTP: Simple Mail Transfer Protocol

  1. The terms “Return-Path”, “envelope sender”, “bounce address”, and “MAIL FROM address” all refer to the same concept in different contexts. “MAIL FROM” is the SMTP command. “Return-Path” is the header added by the receiving server. “Envelope sender” and “bounce address” are operational terms. 

  2. Variable Envelope Return Path (VERP) encodes the recipient address in the envelope sender. For example, a message to alice@example.com gets the envelope sender list-bounce-alice=example.com@sender.com. When a bounce comes back, the sender can identify the exact recipient without parsing the bounce message body. 

  3. Bounce messages themselves use a null envelope sender (MAIL FROM:<>). This empty address prevents bounce loops: a bounce to a bounce would also use <>, and most servers drop messages with a null sender as the recipient. 

  4. BATV is an IETF draft, not a published RFC. It is not a standard, but the technique is widely used by mailing list operators to prevent bounce forgery.