Bounce Intelligence

Every bounce is a reputation event. A healthy cold outreach campaign bounces under 2 percent; above 5 percent the fleet is actively losing inbox placement. Bounce intelligence in NimbusOS classifies each bounce by cause, selects a retry strategy per cause, and updates the affected contact and inbox records so the same bad address is never hit again. This article covers the classification categories, the retry strategies, the auto-suppression rules, and the patterns that should prompt manual intervention.

The Classification Model

A bounce arrives as an SMTP error code plus a message body. Raw SMTP codes are imprecise; the same 550 code can mean "mailbox full" or "spam filter rejection" depending on the receiving server. The classification model reads code and message text together and assigns one of seven categories.

Hard bounce

The address is permanently undeliverable. Mailbox does not exist, domain does not exist, user has been deactivated.

Action:

• Mark the contact verification_status = invalid.
• Add to workspace suppression list with reason hard_bounce.
• Increment the domain bounce counter.
• No retry.

Hard bounces should sit under 1 percent on a verified list. Above that, the verification pass failed or the list aged significantly.

Soft bounce - mailbox temporarily unavailable

Mailbox is full, server is temporarily down, rate limit hit. Usually recoverable.

Action:

• Retry after delay. Delay starts at 1 hour and doubles up to 72 hours.
• After 5 retries, escalate to hard bounce.
• No suppression during retry window.

Soft bounce - content rejected

The receiving filter rejected the content. Subject triggered a spam signal, URL on a blacklist, attachment flagged, template too similar to known spam.

Action:

• Do not retry on this address. The same content will fail the same way.
• Flag the template and subject in SpamForensicReport.
• Alert if multiple content rejections on the same template in a short window.

Soft bounce - reputation

The receiving ISP rejected because of sender reputation. Not the content, not the address; the sending IP or domain is the issue.

Action:

• Do not retry immediately. Retry after 24 hours.
• If reputation bounces exceed 1 percent, flag the inbox for reputation review.
• Alert to deliverability dashboard.

Auto-reply / vacation response

Not a real bounce but often classified as one by naive parsers. The contact replied with an OOO message.

Action:

• Not treated as a bounce.
• Update contact with OOOContact record including return date.
• Reschedule the sequence's next step to after the return date.

Complaint

A spam complaint filed through an ISP feedback loop. Not a bounce in the SMTP sense, but it flows through the same pipeline.

Action:

• Add to global suppression list with reason spam_complaint.
• Mark the contact non-outreachable permanently.
• Increment inbox complaint counter.
• Evaluate auto-pause threshold.

Other

Unclassified bounces. Everything the model cannot categorize falls here. Usually a small residual.

Action:

• Log and flag for human review if the percentage climbs above 5 percent of total bounces.

The BouncePattern Model

BouncePattern is an ML-learned model that maps SMTP code + message fragment to a category with a confidence score. The model is retrained weekly on the platform-wide bounce data.

For example:

• SMTP 550 + "User unknown" -> hard bounce, confidence 0.99
• SMTP 550 + "Message rejected due to high spam score" -> content rejected, confidence 0.96
• SMTP 421 + "Temporarily rate limited" -> soft bounce mailbox unavailable, confidence 0.92

When confidence is below 0.7, the bounce is held for human or rule-based disambiguation. This prevents miscategorizing unknown bounces into a bucket that would trigger the wrong action.

The BounceEvent Model

Every bounce event writes a BounceEvent row with:

• contact_id
• campaign_id
• sequence_step_id
• sending_inbox_id
• smtp_code
• smtp_message
• classification (the category from above)
• retry_strategy
• retry_count
• classified_at
• resolved_at (when the retry succeeded or the bounce was final)

Bounce events are queryable in the deliverability dashboard. The dashboard breaks out the classification distribution over time.

Retry Strategies

Each classification has a default retry strategy. Strategies:

• never - do not retry
• immediate - retry on the next batch cycle
• hourly - retry in 1 hour, then 2 hours, then 4, etc.
• daily - retry in 24 hours, max 3 retries
• weekly - retry in 7 days, max 2 retries

Mapping to classification:

| Classification | Retry strategy | Max retries | | -------------- | -------------- | ----------- | | hard_bounce | never | 0 | | soft_bounce_mailbox | hourly | 5 | | soft_bounce_content | never | 0 | | soft_bounce_reputation | daily | 3 | | auto_reply | never | 0 | | complaint | never | 0 | | other | never until classified | 0 |

Retry strategies are configurable per workspace.

Auto-Suppression Logic

Two events add a contact to the workspace suppression list automatically.

Hard bounce. Immediate suppression with reason hard_bounce. The contact cannot be re-enrolled in any campaign without manual removal.

Spam complaint. Immediate suppression with reason spam_complaint. Global scope applies: the address is suppressed across every workspace on the platform.

Soft bounces do not trigger suppression. They only halt retries after the max retry count.

The Auto-Pause Threshold

A campaign auto-pauses if:

• Bounce rate exceeds 2 percent in a 24 hour window (cold outreach).
• Spam complaint rate exceeds 0.1 percent in a 24 hour window.
• Rapid bounce acceleration: more than 20 bounces in 1 hour from a single inbox.

Auto-pause is aggressive and is intended. A 5 percent bounce rate over a weekend produces real and lasting reputation damage.

Reading the Bounce Dashboard

The Bounce Intelligence page at /bounce-intelligence shows:

• Bounce rate trend over the last 30 days
• Classification distribution (stacked area chart by category)
• Top bouncing domains (recipient domains with above-average bounce rates)
• Top bouncing sending inboxes
• Recent bounce events table with full SMTP detail

The top bouncing domains view is the single most useful operational view. If one recipient domain is responsible for 40 percent of bounces, the list has a quality issue concentrated in that domain.

Manual Intervention Patterns

Five patterns that should prompt a human.

Hard bounce rate over 2 percent on a fresh list

The list quality is bad. Pause, run email verification, resume only the verified subset.

Content rejection rate over 0.5 percent

The template is triggering filters. Rewrite the subject or remove the URL that is on a blacklist.

Reputation bounces concentrated on a single inbox

That inbox has a reputation problem. Pull it from rotation, let it warm back up, investigate whether its domain is on a DNSBL.

Reputation bounces spread across many inboxes

The domain or IP range has a reputation problem, not individual inboxes. Check domain blacklist status. Rotate to a backup domain if needed.

Complaint rate jumping overnight

Usually a single complaint post that amplified. Check the Alerts tab for the specific complaint source. If the complaint is from a legitimate recipient, review the sequence and the target segment.

Integration with the Deliverability Brain

Bounce intelligence feeds the NimbusDeliverabilityScore via the list_hygiene_score component. A spike in any bounce category drops NDS within 24 hours.

The brain cross-references bounce patterns with ISP reputation signals. A reputation bounce that correlates with a Gmail Postmaster reputation drop is a high-confidence signal for domain rotation.

Troubleshooting

"Bounce showing as hard bounce but I think the address is valid"

The SMTP response may have been misclassified. Open the BounceEvent detail and check the raw SMTP message. If the classification looks wrong, submit a reclassification request; the ML model improves from human-confirmed corrections.

"Contact was suppressed after one bounce but I want to re-try"

Remove from suppression list with a comment noting why. The platform logs the override. Re-trying a hard bounce usually produces another hard bounce, but there are edge cases (typo domains that get fixed, temporary provider outages) where the retry succeeds.

"Retry never fires even though I can see the BounceEvent"

Check the retry strategy on the classification. soft_bounce_content has strategy never. No retry will fire. Either reclassify or disable the retry strategy override.

"Campaign paused but I do not see a high bounce rate"

The auto-pause can trigger on complaint rate or rapid acceleration, not just aggregate bounce rate. Check the full alert detail on the campaign.

Frequently Asked Questions

Are bounce classifications available in the analytics export?

Yes. The campaign export includes per-bounce classification. Also available via the BounceEvent API.

How fast does classification run?

Within seconds of the bounce arriving. The platform queues the classification task on the SMTP feedback event and writes the BounceEvent inline.

Does classification work across sending platforms?

Yes. ReachInbox, Smartlead, Instantly, Lemlist, and native SMTP all feed bounces into the same classification pipeline. The SMTP codes and messages are the authoritative input.

Can I configure a webhook for bounce events?

Yes. Add a webhook endpoint in Integrations with event types bounce.hard, bounce.soft, complaint.spam. You will receive a POST with the full BounceEvent payload when each occurs.

What to Read Next

Useful next pages after this one: Spam Forensics for the content-side analysis that complements bounce intelligence, Deliverability Overview for how bounces feed NDS, and Email Verification for preventing bounces at the source.