Custom return path (MAIL FROM)
The return path, also called MAIL FROM or the envelope sender, is the address bounces come back to. It is set during the delivery conversation between servers and is usually invisible to readers, who see the From header instead. Putting the return path on a subdomain you control is what lets SPF align with the domain your mail claims to be from.
At a glance
- Category
- Domain authentication
- Also called
- MAIL FROM, envelope sender, bounce address
- Set during
- The SMTP conversation, before the message body
- Seen by readers
- No — readers see the From header
- Checked by
- SPF, and by DMARC when it tests SPF alignment
- Defined in
- RFC 5321
How it works
Before any of the message is transmitted, the sending server announces the envelope sender in a MAIL FROM command. That address is where the receiving server sends a failure notice, and it is the address SPF is checked against — not the From header a reader sees. A sending service that lets you set a custom return path publishes the necessary records under a subdomain of your own domain, so the SPF check consults your DNS rather than the provider's shared one.
Why it matters
DMARC does not only ask whether SPF passed; it asks whether the domain SPF passed for is the same organisational domain as the one in the From header. With a shared provider return path, SPF passes but aligns with the provider, so the message relies on DKIM alone to satisfy DMARC. A custom return path makes SPF align too, which gives you two independent ways to pass rather than one, and keeps bounce handling inside your own namespace.
Example
Mail from hello@example.com is sent with an envelope sender at send.example.com. The domain publishes an SPF record and the provider's bounce host under that subdomain. A receiving server checks SPF against send.example.com, which passes, and DMARC sees that send.example.com and example.com share an organisational domain, so SPF alignment passes as well. Bounce notices arrive at the subdomain and are turned into events on the original message.
Common mistakes
- 01Leaving the return path on the provider's shared domain and then wondering why DMARC reports show SPF unaligned.
- 02Publishing the subdomain records but sending from a different domain, so the alignment you set up never applies.
- 03Pointing the return path at a mailbox somebody reads, which turns automated failure notices into an inbox nobody triages.
- 04Changing the return path subdomain without republishing its records first, so every message sent in the gap fails the SPF check outright.
In Rasket
Every sending domain gets a return path on a subdomain of itself, at the send label by default, and you can choose another label. Domains
Related terms
Frequently asked questions
Will readers see the return path?
Almost never. Mail clients display the From header, and the envelope sender lives in the transport conversation. Some clients expose it in a headers view if you go looking.
Why a subdomain rather than the root domain?
A subdomain keeps the bounce namespace separate from the mail you actually send, and it lets the SPF record for sending list only what the provider needs. DMARC still treats the two as aligned because they share an organisational domain.
Do I still need DKIM if SPF aligns?
Yes. SPF breaks on forwarding because the forwarding server is not on your list, while a DKIM signature survives it. Having both is what keeps a message passing DMARC through a redirect.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.