| Customer.io | |
|---|---|
| Their stated threshold | Customer.io follows the industry standard of keeping bounce rates under 2% and provides deliverability guidance to customers on shared and dedicated sending. |
| What happens if you cross it | Customer.io monitors account sending health and will contact customers about list quality. Their model is developer-facing, so the conversation tends to be technical rather than a compliance notice. |
| Where the bounce data lives | The Deliverability dashboard for trends, the activity log per person for individual events, and webhooks or the Reporting API for anything you want in your own system. |
| How bounces are classified | Customer.io records bounce events against the person with the SMTP response, and suppresses the address after a hard bounce so no campaign or broadcast sends to it. |
Bringing the rate down
Each step is an action inside Customer.io, in the order worth taking them.
Read the activity log for a bounced person
It shows the SMTP response the receiving server gave, which distinguishes a nonexistent mailbox from a policy rejection. The dashboard aggregate does not.
Check which identify call wrote the address
People arrive through your application's identify calls. A bad address means the application accepted it, and that is where the fix belongs.
Watch continuously-running campaigns closely
Event-triggered campaigns run forever, so a slowly rising bounce rate never appears as a spike in any single report. Set an alert on the trend.
Use the suppression list as evidence
Pull it through the API and group by domain and by signup date. That grouping usually names the source faster than the dashboard does.
Validate before the identify call
A real-time check in your signup flow stops the address being written at all, which is the only place this problem is actually solvable.
The mistake people make here
A bounce report mixes two causes that need opposite responses: addresses that do not exist, and receivers refusing mail they could have delivered. The first is fixed by checking the list. The second is a sending problem and no amount of cleaning will move it.
Questions people ask
Why do bounce problems hide in event-triggered messaging?
Because the sending is continuous. A broken signup path adds a few bad addresses a day, the rate climbs slowly, and nothing looks like an incident until the rate is already high.
Where do I find the actual SMTP response?
In the activity log on the person's record. It carries the receiving server's response text, which is the difference between a diagnosis and a count.
Does Customer.io stop campaigns on a bounce?
It suppresses the address after a hard bounce, so campaigns and broadcasts both skip it.