Delayed Bounces and Return-Path Guide
Understand SMTP acceptance, delayed DSNs, Return-Path domains, and how Postscale turns bounce mail into webhook events.
TL;DR
A successful SMTP handoff does not guarantee final delivery. Some receivers accept a message, fail later, and send a DSN to the Return-Path. Configure Return-Path routing so Postscale can correlate delayed bounces and emit accurate webhook events.
What you will learn
- Distinguish immediate SMTP rejects from delayed bounces
- Understand why Return-Path routing matters
- Troubleshoot missing or unexpected bounce webhooks
Immediate reject versus delayed bounce
Email delivery has multiple stages.
An immediate reject happens during SMTP handoff:
550 5.1.1 user unknown
A delayed bounce happens after a receiver accepts the message and later determines it cannot deliver. The receiver sends a delivery status notification back to the Return-Path address.
Why Return-Path matters
The visible From address is for users. Return-Path is for delivery systems.
Postscale uses Return-Path routing to:
- Receive delayed DSNs.
- Parse the bounce reason.
- Correlate the DSN with the original message.
- Update message status.
- Emit a bounce webhook.
Without Return-Path routing, delayed bounces can disappear into a mailbox or another provider.
Configure bounce routing
Add the CNAME Postscale provides:
ps-bounces.example.com. CNAME bounces.postscale.io.
Then send a test message to a controlled invalid recipient and confirm a bounce event appears.
Common troubleshooting cases
| Symptom | Likely cause |
|---|---|
| No delayed bounce webhook | Return-Path CNAME missing or not propagated |
| Bounce arrives in a user mailbox | Envelope sender points at the wrong host |
| SPF passes but DMARC fails | Return-Path domain does not align and DKIM is failing |
| Duplicate bounce handling | Webhook handler is not idempotent |
Always inspect the raw event and the original message metadata before suppressing a recipient manually.
Build reliable handlers
Your bounce handler should:
- Store the event id.
- Check whether the event was already processed.
- Mark the recipient suppressed for hard bounces.
- Keep temporary failures separate from permanent bounces.
- Preserve the provider response for support.
Delayed bounces are normal. Missing correlation is the problem to fix.
Frequently asked questions
- Why did the API accept an email that later bounced?
- The receiving server may have accepted the SMTP handoff and then failed delivery later. That later failure is reported as a DSN.
- Can I use my visible From address as Return-Path?
- Do not do that. Return-Path is an envelope address used for bounce processing and should route to the bounce handler.
Put the guide into production
Postscale brings sending, inbound processing, DMARC reporting, and masked addresses behind one API so the operational pieces stay connected.