The Return-Path header is not an address you type in a composer. The receiving server writes it from the SMTP envelope MAIL FROM, also called the reverse-path, when it accepts the message. Bounces and other delivery status notifications go to that address, not to the visible From. A different Return-Path is normal. An empty Return-Path, written as <>, is the normal mark of a bounce message, not a broken sender.
Why the bounce is not in the From inbox
A founder watches [email protected] because that is the address customers see. The receipt can still leave with a MAIL FROM on a bounce subdomain. The mailbox provider then writes Return-Path to that envelope sender. Non-delivery reports follow Return-Path. If nobody reads that mailbox, the failure is silent.
This page is the diagnosis for where the notice is addressed. What to do with a bounce, a complaint, or a delay is in bounce vs complaint vs delay. The three-header definition is in From, Reply-To, and Return-Path. Alignment rules stay in why DMARC alignment is the whole game.
How we analyzed the header
Checked on 8 October 2026 against RFC 5321 (reverse-path), RFC 5322 (Return-Path as a trace field), the Arawa Mail sending guide, and the outgoing webhooks guide. Constraints:
- RFC 5321 names the MAIL FROM value the reverse-path. A null reverse-path is used so a delivery status notification does not itself bounce.
- RFC 5322 defines Return-Path as a trace field added by the final delivery system. The sender does not author it. Intermediate servers are not supposed to add it.
- SPF evaluates the envelope sender domain. A Return-Path domain that differs from From does not by itself fail SPF. DMARC then asks whether the SPF-authenticated domain or the DKIM domain aligns with From.
- Arawa Mail sending activation configures a custom MAIL FROM domain and adds its MX and SPF records through Cloudflare, after receiving is active. The docs do not name the exact hostname, do not offer a Return-Path field in the mailbox composer, and do not document a user-set envelope sender.
- Outgoing webhooks fire when mail arrives in a mailbox. They are not delivery, bounce, or complaint event webhooks. A bounce is visible in Arawa only if it is delivered to a mailbox you can read.
How to read the header the receiver wrote
Open the original message, not the rendered view. You should see three different jobs:
From: Billing <[email protected]> Reply-To: [email protected] Return-Path: <[email protected]>
- From is the author address recipients and DMARC see.
- Reply-To, when present, is where a human reply should go. It does not receive bounces.
- Return-Path is the delivered copy of MAIL FROM. That is the bounce address.
If Return-Path is on a subdomain, read that mailbox or the provider's bounce route for the failure. Do not keep refreshing the From inbox. Providers use a subdomain so SPF can pass on the bounce domain while DKIM aligns the visible From domain. That split is expected. See SPF, DKIM, and DMARC explained for the three checks, not for a rule that the headers must match.
What Return-Path: <> means
A delivery status notification is itself an email. Its envelope sender is empty so a failure to deliver the notice does not create another notice. The receiving system records that as Return-Path: <>. Treat the empty path as the signature of a DSN, then read the status code inside it. It is not a missing sender and not a reason to rewrite the original From.
When a different Return-Path is not the failure
SPF can pass on the MAIL FROM domain while DMARC still fails, because neither SPF nor DKIM aligns with From. That is an alignment problem, not proof that Return-Path was wrong. Do not force Return-Path to equal From to chase a DMARC pass. Alignment, including relaxed versus strict, is the separate article linked above.
SES, Postmark, and similar relays also use a custom MAIL FROM or return-path domain. Those hostnames are not Arawa settings. Do not copy them into Cloudflare for an Arawa domain.
Where Arawa Mail sends bounces
On Activate Sending, Arawa Mail configures a custom MAIL FROM domain and publishes its MX and SPF records in Cloudflare. That MAIL FROM domain is the documented bounce-domain path. The product docs do not expose a Return-Path composer field, so you cannot set the header from the mailbox. You also cannot assume an automatic suppression list.
A bounce shows up in Arawa if it is delivered to a mailbox on the domain. Outgoing webhooks then POST that incoming message, including a bounce that landed in a mailbox, to your notify URL. They do not report that an outbound API send bounced. The published transactional email webhooks article is about that incoming-mail hook, not an SES-style event stream. Mailbox access is in the mailbox guide.
FAQ
Who writes the Return-Path header?
The final receiving system, from the SMTP reverse-path. You do not set it in the compose window.
Why do bounces not arrive at the From address?
Bounces follow MAIL FROM. From is the visible author. They are allowed to differ.
What does Return-Path: <> mean?
A null reverse-path. It is how a DSN avoids bounce loops. Read the status inside the notice.
Does a different Return-Path fail SPF or DMARC by itself?
No. SPF checks the envelope sender domain. DMARC checks alignment with From. A mismatch alone is not a failure.
Can I set Return-Path in Arawa Mail?
No composer field is documented. Sending activation configures a custom MAIL FROM domain and its MX and SPF records through Cloudflare. The exact hostname is not published as a fixed string.
How is Return-Path different from Reply-To?
Reply-To is where a person should reply. Return-Path is where the receiving server sends the bounce.