Reducing your bounce rate in Iterable

Written for growth teams running cross-channel lifecycle messaging.

Iterable
Their stated thresholdIterable's guidance follows industry practice of keeping bounce rates under 2%, and their deliverability team works with customers on sender reputation directly.
What happens if you cross itIterable assigns deliverability support to enterprise accounts and manages IP reputation actively. Enforcement looks like a conversation with your deliverability contact rather than an automated suspension.
Where the bounce data livesThe Deliverability dashboard for trends, and per-user event history on the profile for individual failures. Everything is also available through the API and the data export.
How bounces are classifiedIterable records bounce events on the user profile with the type and the SMTP response, and marks the user as unsubscribed from email on a hard bounce so no campaign or journey sends to them.

Bringing the rate down

Each step is an action inside Iterable, in the order worth taking them.

  1. Trace the address back to its data source

    Iterable users arrive from your product, your warehouse or an API call. The bounce is a symptom; the pipeline that wrote the address is the cause.

  2. Check journeys as well as campaigns

    A journey can send to a user months after they entered it. A bad cohort keeps generating bounces long after the campaign that revealed them.

  3. Validate in the ingestion pipeline

    The right place for a check is where user records are created. That stops the address entering Iterable rather than cleaning it afterwards.

  4. Use your deliverability contact

    Enterprise accounts have one. They can see IP-level reputation data you cannot, and they will tell you whether the problem is your list or your warm-up.

  5. Segment out unresolved addresses before a large journey

    Store the verdict as a user field and exclude unresolved addresses from the first touch of a new journey.

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

Where do bounces come from in an API-driven platform?

From whatever writes user records: your product's signup, a warehouse sync, or an integration. The bounce shows up in Iterable and the cause is always upstream of it.

Does Iterable stop journeys on a bounce?

A hard bounce marks the user as unsubscribed from email, which stops both campaigns and journeys sending to them.

How do I see bounce trends rather than individual failures?

The Deliverability dashboard shows the trend by domain and by sending IP, which is where a reputation problem separates itself from a list quality one.

Check the list before the next send

100 free checks a month, no card, and the addresses nobody can resolve come back labeled rather than guessed at.