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. relay configures the Return-Path for you.

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 serves two critical functions 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 exists in two places:

  1. The SMTP envelope: The MAIL FROM command sets the envelope sender address. This address is not visible to the recipient. It is used for bounce delivery and SPF checks.
  2. The Return-Path header: The receiving mail server adds a Return-Path header to the message when it accepts the message. The header contains the envelope sender address from the MAIL FROM command.

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@mail.relay.example.com>   (envelope sender)
From: billing@example.com                             (visible header)
Return-Path: bounce+019a8c26@mail.relay.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 mail.relay.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 sender domain has MX and SPF records. The MX record routes bounce messages to relay. The SPF record authorizes the sending servers.

The built-in nameserver serves these records. You do not need a separate Return-Path domain or DNS record.

How relay uses Return-Path

relay sets the envelope sender (the MAIL FROM address) to a subdomain of your sender domain. The format is:

bounce+<message-id>@mail.relay.<your-domain>

The tag after bounce+ contains the outgoing message ID. The sender domain routes bounce messages to the relay MX service.

The Return-Path domain is part of the SPF setup. The envelope sender domain must align with the visible From domain for DMARC. relay uses a subdomain, which aligns under relaxed DMARC.

Further reading

  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.