Bounce handling and the return-path

5 June 2026 · 11 min read

Every message you send has a destiny that no one talks about until it goes wrong: it might bounce. The recipient's mailbox is full, the address never existed, the receiving server is rate-limiting you, or a security gateway rejected the message outright. When that happens, the receiving side needs somewhere to send the failure notice. That somewhere is the return-path, and the address it points to is set by the envelope, not by anything your recipient ever sees. Get the return-path right and three things fall into place at once: your bounces are processed cleanly, your list hygiene stays healthy, and your SPF alignment under DMARC starts passing. Get it wrong and you can have a "valid" SPF pass that still leaves your domain spoofable, plus a stream of bounce messages quietly vanishing into a mailbox no one reads.

This article is specifically about that machinery: how the envelope return-path is set, why a custom return-path on your own domain is the single change that fixes SPF alignment for almost every third-party sending platform, and what actually happens to a bounce once it leaves the receiving server.

Return-path, envelope-from, MAIL FROM: one address, several names

The terminology trips people up because the same address has at least four names depending on which document you are reading:

• MAIL FROM is the SMTP command that carries it.
• Envelope-from is the conceptual name, because it lives on the envelope rather than in the message body.
• RFC5321.MailFrom (or 5321.From) is the formal identifier used in the DMARC and SPF specifications.
• Return-path is the name for the same address once the receiving server records it, often written into a Return-Path: header at delivery time.

They are the same address. It is set during the SMTP conversation, before the message content is ever transmitted:

MAIL FROM:<bounces@send.yourdomain.com>
250 OK
RCPT TO:<customer@example.com>
250 OK
DATA
354 Start mail input
From: Your Company <hello@yourdomain.com>
To: customer@example.com
Subject: Your receipt
...
.
250 OK: queued as 7B2C1

Two different "from" addresses appear here, and that is normal. The MAIL FROM (envelope-from / return-path) is bounces@send.yourdomain.com. The From: header your customer reads is hello@yourdomain.com. The receiving server treats these as separate identities set at separate moments. If you want the full conceptual treatment of those two addresses, the companion article Header-from vs envelope-from walks through the postal analogy in detail. Here we are concerned with the practical consequences for bounces and alignment.

What the return-path is actually for

In normal, successful delivery the return-path does almost nothing. The message is accepted, queued, delivered, and the envelope-from is never contacted. The return-path earns its keep only on failure.

When a receiving server cannot deliver a message after accepting it, or rejects it during the SMTP conversation, it produces one of two things:

• A 5xx permanent rejection during the SMTP session itself. The sending server sees the rejection live and is responsible for generating the bounce. This is called a synchronous or SMTP-time bounce.
• A non-delivery report (NDR) generated after acceptance, sent as a brand-new email back to the return-path address. This is an asynchronous bounce, and the message that arrives is a DSN (Delivery Status Notification) formatted per RFC 3464.

In both cases the destination for the failure information is the envelope-from. That is its entire job: it is the bounce address. This is why the address often looks like bounces@, bounce@, or something machine-oriented rather than a human's name. Nobody is meant to read it by hand; it feeds an automated process.

Why bulk senders never bounce to a human inbox

If you send marketing email, transactional receipts, or any volume of automated mail, you do not want bounces landing in a person's inbox. You want them parsed by software. A typical asynchronous bounce DSN contains the structured detail that software needs:

Content-Type: message/delivery-status

Reporting-MTA: dns; mx.example.com
Final-Recipient: rfc822; customer@example.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 user unknown

The Status: field uses the enhanced status codes from RFC 3463. The leading digit tells you the class:

• 2.x.x success (rare in a bounce, but used in delay/relay notices).
• 4.x.x transient. The address may work later: a full mailbox, a greylist, a temporary block. Do not remove the address; retry.
• 5.x.x permanent. The address is dead or the message was hard-rejected. Suppress the address.

The subfields matter for hygiene decisions. 5.1.1 means the recipient does not exist; suppress immediately. 5.2.2 means the mailbox is full; treat as soft and retry for a while before suppressing. 4.7.x often signals a reputation or policy block, which is a deliverability problem with your sending domain rather than a bad address. Routing all of this to a parsed bounce mailbox lets your platform suppress dead addresses automatically, which protects your sender reputation: mailbox providers watch how often you hit non-existent addresses, and a high invalid-recipient rate is read as a sign of a poorly maintained list.

VERP: knowing exactly which address bounced

A plain bounces@ address has a weakness. When an asynchronous DSN arrives, the only reliable way to know which original recipient failed is to parse the Final-Recipient field out of the DSN body, and not every receiver formats it the same way. Bulk senders solve this with VERP (Variable Envelope Return Path), where the recipient is encoded into the return-path itself:

MAIL FROM:<bounce+customer=example.com@send.yourdomain.com>

When that bounces, the DSN comes back addressed to bounce+customer=example.com@send.yourdomain.com, and the sending system can read the failed recipient straight from the envelope without parsing anything. This is why you will sometimes see long, encoded return-paths in raw message sources. It is not obfuscation; it is bounce attribution.

You can see the recorded return-path and the full DSN structure of any message by pasting its source into the email header analyzer.

The part that catches everyone: return-path and SPF alignment

Here is where bounce handling stops being an operational nicety and becomes a DMARC problem.

SPF authenticates the envelope-from domain, not the From: header. When a receiving server runs an SPF check, it takes the domain to the right of the @ in MAIL FROM and looks up that domain's SPF record. So if your envelope-from is bounces@send.yourdomain.com, SPF validates send.yourdomain.com.

DMARC then asks a second question that pure SPF never asks: does the SPF-authenticated domain align with the From: header domain? Alignment is what turns a generic SPF pass into something DMARC will accept.

This is the exact failure mode for almost every third-party sending platform. Consider a typical setup where you send through an email service provider:

From: hello@yourdomain.com           (what the recipient sees)
MAIL FROM: bounce@bounces.esp-domain.net   (the platform's default return-path)

The platform's shared bounce domain has a valid SPF record, so SPF passes. But it passes for bounces.esp-domain.net, which has nothing to do with yourdomain.com. Under DMARC's relaxed SPF alignment, the organisational domains must match: esp-domain.net is not yourdomain.com, so SPF does not align. The message has to lean entirely on DKIM to satisfy DMARC. If DKIM also has a problem, the message fails DMARC despite a perfectly green SPF result.

You can reproduce exactly this on a live message: run your sending domain through the SPF checker and your published policy through the DMARC checker, then compare what SPF authenticated against your From: domain. If they differ, you have an alignment gap that no amount of editing the SPF record will close, because the problem is the return-path, not the record.

For a deeper read on the relaxed-versus-strict mechanics, see Relaxed vs strict DMARC alignment.

The fix: a custom return-path on your own domain

The solution is to make the return-path live under your domain so that the SPF-authenticated domain aligns with your From: header. Sending platforms support this through a feature usually called a custom return-path, custom MAIL FROM, or custom bounce domain. The setup is always the same shape:

1. You pick a subdomain to act as the bounce domain, for example send.yourdomain.com or bounce.yourdomain.com. A subdomain is used so the bounce traffic and its SPF record are isolated from your main domain.
2. You point that subdomain at the platform with the DNS records they specify. This almost always means a CNAME (so the platform controls the underlying SPF and routing) plus, frequently, an MX record so asynchronous DSNs are routed back to the platform's bounce processor.
3. The platform then issues MAIL FROM: bounce@send.yourdomain.com for your mail.

A representative custom return-path configuration looks like this:

; bounce subdomain delegated to the sending platform
send.yourdomain.com.    IN CNAME  bounces.esp-domain.net.

; route asynchronous bounce DSNs back to the platform
send.yourdomain.com.    IN MX 10  feedback-smtp.esp-domain.net.

; the subdomain's own SPF record authorising the platform
send.yourdomain.com.    IN TXT    "v=spf1 include:esp-domain.net ~all"

Some platforms have you publish the CNAME and let it resolve to their SPF; others want an explicit TXT record on the subdomain. The detail varies, but the outcome is identical: when a receiver runs SPF, it now authenticates send.yourdomain.com, whose organisational domain is yourdomain.com, which matches your From: header. SPF now aligns, and your DMARC pass no longer depends solely on DKIM.

A crucial subtlety: the return-path subdomain needs its own SPF policy, but it must not carry its own DMARC enforcement in a way that breaks the bounce platform's own mail. In practice you publish DMARC at the organisational level and let the subdomain inherit it; you do not put a separate restrictive policy on the bounce subdomain unless you genuinely understand what mail flows from it. For how subdomains inherit policy, see Subdomain DMARC record.

Belt and braces: why you still want DKIM aligned too

Fixing the return-path gives you SPF alignment, and that is genuinely valuable, but it is not the whole job. SPF breaks the moment a message is forwarded, because the forwarding server becomes the new envelope sender and the original SPF check no longer applies to your domain. DKIM survives forwarding because the signature travels inside the message. So the resilient configuration is both: a custom return-path so SPF aligns on direct delivery, and a properly aligned DKIM signature so authentication survives forwarding and mailing lists. Verify your signature with the DKIM checker. DMARC only needs one of the two to pass and align, but having both means a single broken mechanism never costs you a DMARC pass. This is exactly the scenario explored in DMARC fails but SPF and DKIM pass: a mechanism can pass without aligning, and alignment is the part that counts.

What actually happens to a bounce, end to end

Putting the whole flow together for a single failed message:

1. Your platform sends with MAIL FROM: bounce@send.yourdomain.com and From: hello@yourdomain.com.
2. The receiving server checks SPF against send.yourdomain.com. With the custom return-path configured, this passes and aligns.
3. The recipient's mailbox does not exist. The receiving server either rejects with 550 5.1.1 during the SMTP session (synchronous) or accepts and later emits a DSN (asynchronous).
4. A synchronous rejection is seen live by your platform's sending MTA, which records the failure immediately. An asynchronous DSN is emailed to bounce@send.yourdomain.com, routed by your bounce subdomain's MX record back to the platform's feedback handler.
5. The platform parses the enhanced status code. A 5.x.x permanent failure adds the address to your suppression list so it is never sent to again. A 4.x.x transient failure schedules retries.
6. Suppression keeps your invalid-recipient rate low, which protects your reputation at the mailbox providers, which keeps your future mail landing in inboxes rather than spam folders.

Every step in that chain depends on the return-path pointing somewhere a machine can read and act on. A custom return-path on your own domain makes step 2 align for DMARC and keeps steps 4 through 6 inside the platform that knows how to process them.

Common return-path mistakes

A few failure patterns show up again and again:

• Leaving the platform's default shared bounce domain in place. SPF passes, never aligns, and the team assumes "SPF is fine" because the checker is green. The fix is the custom return-path, not editing the SPF record.
• Configuring the custom return-path but forgetting the MX record. Synchronous bounces still work, but asynchronous DSNs cannot be routed back, so list hygiene silently degrades and dead addresses pile up.
• Pointing the return-path at a real human inbox for automated mail. Thousands of DSNs arrive, nobody parses them, and addresses are never suppressed.
• Publishing a too-strict SPF record on the bounce subdomain. If the bounce subdomain's SPF does not authorise the platform's actual sending or feedback infrastructure, you can cause the bounce processing itself to fail authentication. Validate the subdomain specifically, not just the apex, with the SPF checker.
• Treating soft bounces as hard. Suppressing an address on a single 4.x.x transient failure throws away deliverable contacts. Honour the status class.

Reading bounce patterns in your DMARC reports

Aggregate DMARC reports will not show you individual bounces, but they will show you alignment, which is the upstream cause of the problem this article fixes. If your reports show a source where SPF passes but does not align while DKIM carries the pass, that source is almost certainly sending with the platform's default return-path. Switching it to a custom return-path will flip SPF to aligned in subsequent reports. Drop your reports into the DMARC report analyzer and look at the SPF alignment column per source; the unaligned-SPF sources are your custom return-path to-do list. For background on interpreting those reports at all, see Reading your first DMARC report.

The practical takeaway

The return-path is the envelope-from under another name, and it does two jobs that feel unrelated until you see how they connect. It is the address bounces come back to, which is why it should point at automated processing rather than a person, ideally with VERP so every failure is attributable. And it is the domain SPF authenticates, which is why a custom return-path on your own subdomain is the change that turns a hollow "SPF pass" into genuine SPF alignment under DMARC. Configure both halves, the CNAME/MX for bounce routing and the subdomain SPF for alignment, and you fix deliverability and authentication in one move.

If you want to see exactly where your sending sources stand today, run your domain through the SPF checker and DMARC checker, then look for any source whose SPF passes but does not align. If you would rather not manage bounce subdomains, custom return-paths and alignment across a fleet of sending platforms yourself, our done-for-you DMARC service sets up and monitors all of it, and our monitoring tells you the moment a return-path or SPF record changes underneath you.