On this page
What bounce handling means
A bounce is a message a receiving server refuses or can’t deliver. Hard bounces are permanent: the address doesn’t exist, the domain has no mail server, or the recipient has been disabled. Soft bounces are temporary: a full mailbox, a server that is briefly unavailable, or a provider asking you to slow down.
Bounce handling is the automatic process of capturing those responses, classifying them and acting on them: suppressing hard bounces straight away, retrying soft bounces a sensible number of times, and suppressing addresses that keep failing. Sending repeatedly to addresses that don’t exist is one of the clearest signals of a poorly maintained list, and it damages reputation quickly.
Signs your bounce handling isn’t working
- Your platform reports zero bounces, which on a real list usually means they aren’t being read.
- The same invalid addresses appear in every campaign’s failure report.
- Your sending provider has warned you about your bounce rate.
- Soft bounces are treated as permanent, so good subscribers are removed after one full mailbox.
- Bounces are recorded in the platform but not in your CRM or application, so they come back on the next import.
How bounce information reaches you
| Source | How it works | Typical platform |
|---|---|---|
| SMTP response | Receiver rejects during delivery; MTA logs the code | Postfix, PowerMTA, Postal |
| Bounce message (DSN) | A delayed failure is mailed back to the return-path | Bounce mailbox read by the platform |
| Event notification | Provider sends a bounce event by webhook or notification | Amazon SES, Postal |
| Accounting logs | Per-message outcome written to log files | PowerMTA |
Each platform needs at least one of these wired correctly. MailWizz, for instance, needs a bounce server configured and its bounce cron running; SES needs its bounce notifications subscribed and consumed.
What’s included
- A return-path or bounce domain that receives delayed bounce messages.
- Bounce processing configured in your platform, whether mailbox, webhook or log based.
- Classification rules separating hard, soft and policy-related rejections.
- Immediate suppression of hard bounces across every list you hold.
- Retry limits for soft bounces, with suppression after repeated failure.
- Synchronisation of suppressions to your CRM or application where needed.
- Reporting that shows bounce reasons by category and by receiving domain.
How we deliver it
- Review current bounce data, or confirm there isn’t any.
- Set up the capture method suited to your platform.
- Test with deliberate hard and soft bounces, including the provider’s simulator where available.
- Tune classification so policy rejections and reputation blocks are recognised separately from invalid addresses.
- Apply historical bounces to your suppression list before your next send.
- Document where bounces go and how to review them.
Where your CRM or application holds its own copy of contacts, we make sure suppressions flow back to it, so a list exported next month doesn’t reintroduce addresses that bounced this month.
What bounce reasons tell you
Categorising bounces separates two very different problems. Many “user unknown” bounces point to list quality: old data or poor sign-up validation. Rejections mentioning policy, reputation or blocklists point to your sending reputation, which needs deliverability work or blacklist troubleshooting. Treating both the same way hides the real issue.
What affects timeline and cost
- Number of platforms and sending sources.
- Whether bounces must sync to other systems.
- Volume of historical data to process.
- Custom classification needs for your receivers.
Common mistakes
Relying on a bounce mailbox nobody configured the platform to read. Removing subscribers after a single soft bounce. Never removing them after dozens. Re-importing a list from a CRM that never received the suppressions. Counting every policy rejection as an invalid address.
Related: complaint handling, all email infrastructure services, the guide, and contact.
Frequently asked questions
What is a normal bounce rate?
It varies by list and mail type, but a well-maintained opt-in list should see few hard bounces. A rising rate is a signal to investigate, whatever the starting point.
Should soft bounces be removed?
Not after one failure. We retry within limits and suppress addresses that keep failing across several sends.
Why do my platform and my provider report different bounce rates?
They count differently. A platform may record policy rejections and soft bounces that the provider reports separately. We reconcile both.
Can we validate addresses before sending?
Yes, and it helps at sign-up. Validation doesn’t replace consent, and it doesn’t replace bounce handling after sending.
Where do bounces go for mail sent from our own server?
Immediate rejections are recorded in the server logs, and delayed bounces arrive at the return-path address. We make sure both are captured and processed.
Talk to us about bounce handling
Hard and soft bounces processed automatically to protect your sender score.