What Is a Return-Path and How Do Bounces Find Their Way Back?

The Return-Path is a header added by the receiving mail server that records the envelope sender of a message, so that any bounce or delivery failure can be sent back to that address. It is copied from the SMTP MAIL FROM command at the moment of delivery. When a message cannot be delivered, the bounce goes to the Return-Path, not to the From address the reader sees.

Quick summary

• Your server sends MAIL FROM:<bounces@yourdomain.com> and the message.
• The recipient server accepts it and stamps Return-Path: <bounces@yourdomain.com> on the stored copy.
• Later, delivery to the final mailbox fails: the mailbox is full, the user does not exist, or a filter rejects it.
• The recipient server composes a delivery status notification (DSN) with an empty envelope sender, MAIL FROM:<>, so bounces never bounce.
• That DSN is delivered to bounces@yourdomain.com, where your provider parses the diagnostic code and updates the delivery log.

How a bounce travels

1. Your server sends MAIL FROM:<bounces@yourdomain.com> and the message.
2. The recipient server accepts it and stamps Return-Path: <bounces@yourdomain.com> on the stored copy.
3. Later, delivery to the final mailbox fails: the mailbox is full, the user does not exist, or a filter rejects it.
4. The recipient server composes a delivery status notification (DSN) with an empty envelope sender, MAIL FROM:<>, so bounces never bounce.
5. That DSN is delivered to bounces@yourdomain.com, where your provider parses the diagnostic code and updates the delivery log.

Example Return-Path headers

Return-Path: <sales@yourdomain.com>
   simplest case: same as From, bounces land in the sales mailbox

Return-Path: <bounce+a1b2c3@yourdomain.com>
   VERP style: the unique tag lets the sending system match the bounce to one message

Return-Path: <>
   the empty sender used by bounce messages themselves

Why senders use a dedicated Return-Path

• Automation: bounces to a machine-read address are parsed and the bad recipient is flagged without a human reading it.
• Cleanliness: your real inbox is not filled with delivery failure notices.
• SPF: the Return-Path domain is what SPF evaluates, so it must be a domain whose SPF authorises the sending server.
• DMARC: with relaxed alignment, a Return-Path on a subdomain such as bounce.yourdomain.com still aligns with a From on yourdomain.com.

How to check the Return-Path of a message

In Gmail, open Show original and look at the first few lines; Return-Path appears near the top because it is added last, at final delivery. In Outlook desktop, File, Properties, Internet headers. In Apple Mail, View, Message, All Headers. If you are the sender, the OquMail per-message delivery log shows the remote response without needing to inspect any bounce mail.

Common Return-Path problems

• A Return-Path domain with no SPF record. Receivers see SPF none and DMARC can only pass through DKIM.
• A Return-Path address that does not exist. Bounces are rejected and you lose the only signal that an address is dead.
• A vendor Return-Path on a marketing tool without a custom bounce domain, so SPF passes for the vendor and never aligns with you.
• Forwarding without SRS, where the original Return-Path is kept and the forwarder fails SPF at the destination.

Return-Path and OquMail

OquMail sets the envelope sender on your verified domain for both mailbox sends and API sends, so the Return-Path is covered by the SPF record the dashboard asked you to publish. Bounces come back to OquMail, which records the diagnostic in the delivery log for that message. You do not need to create a special bounce mailbox; the free plan mailboxes and the API share the same handling.

Reading a bounce that comes back

A delivery status notification carries a machine-readable part with Action: failed, a Status code such as 5.1.1, and a Diagnostic-Code line quoting the remote server. That diagnostic is the same text OquMail records in the delivery log. Codes beginning with 5 are permanent, so remove the address; codes beginning with 4 are temporary, so a retry is reasonable after a few hours.

Common questions

Can I set the Return-Path myself in a mail app?

Normal mail apps use your address as the envelope sender automatically. Only sending systems and APIs let you choose a different one, and it must stay on a domain you control.

Why is Return-Path empty on some messages?

Bounce messages and some automatic notifications use an empty envelope sender by design, so they cannot generate further bounces.

Does Return-Path affect where replies go?

No. Human replies go to Reply-To if present, otherwise From. Return-Path is only for automated failure notices.