- Return-Path, defined
- The Return-Path is the address where bounce notifications are delivered, written into the message header by the receiving server from the envelope sender it was given.
Sending platforms encode information in it. An address like bounce-4f2a91-list7@mail.yourdomain.com lets the platform match an incoming failure to the exact message and recipient without guessing.
Because SPF validates the envelope sender, this address is also what your SPF record is judged on. A platform using its own bounce domain gets an SPF pass on their domain, not yours.
That is why custom return paths exist as a setup step in every serious platform. Pointing a subdomain at their bounce infrastructure aligns SPF with your From domain and satisfies DMARC.
Bounce processing only works if someone reads the mailbox. A return path pointing at an address nobody monitors means failures accumulate invisibly and suppression never happens.
How ZapBounce reports it
Verification predicts bounces instead of processing them, so we never receive a return-path message on your behalf. The address we declare during a probe is on a domain we control and receives nothing, because the connection closes before a message exists.
One bounce finding its way home
Say you send a newsletter to 20,000 people through a platform, and your custom return path is em.acme.example. The copy going to Dana leaves with an envelope sender like bounce-7c41e9-20417@em.acme.example. That long token is unique to her copy. The technique is called VERP, for variable envelope return path.
Dana's company deleted her mailbox last month, so their server answers 550 5.1.1 User unknown. A bounce report goes to the envelope sender address. Your platform receives it, reads the token, and knows which recipient and which campaign failed without having to parse the wording of the report, which differs from server to server.
You can see the result of all this in any delivered copy. View the raw message and the first lines include Return-Path: <bounce-7c41e9-20417@em.acme.example>, written there by the receiving server.
The empty return path, and why it exists
Some mail is sent with no envelope sender at all, written as MAIL FROM:<>. Bounce reports use it, and so do many automatic replies. The reason is loop prevention: if a bounce can't be delivered, there's nowhere to send a bounce about the bounce, so the chain stops.
That empty value has a side effect on authentication. SPF has no sender domain to check, so RFC 7208 has the receiver fall back to the name your server gave in its HELO or EHLO greeting. If your mail server announces itself with a hostname that has no SPF record, its bounce reports can fail SPF at strict receivers. Publishing a small SPF record for the hostname itself fixes it.
Keep the header names straight as well. From is what the reader sees, Reply-To redirects their reply, and Sender names an agent mailing on someone's behalf. Only the return path is set in the SMTP envelope, and it's the one address in that group the reader's reply never touches.
Return-Path: common questions
Is Return-Path the same as Reply-To?
No. Return-Path receives automated failure notices. Reply-To sets where a human's reply goes when they hit reply.
Why should I set a custom return path?
It aligns SPF with your From domain, which is what DMARC requires. Without it, SPF passes for your platform instead of you.
Who writes the Return-Path header?
The receiving server, from the envelope sender in MAIL FROM. Anything you set in the client is discarded.