Why was this prospect skipped — bounce

What this page covers

If a prospect on your campaign shows status "Bounced — see Inbox" in more than one of your mailboxes — even though you only sent to them from one mailbox originally — this guide explains the platform behavior called bounce-fanout: a structural safeguard that automatically skips a bounced prospect in your other mailboxes within the same workspace, to protect your sending domain reputation from a single bad address cascading into a multi-mailbox spam-trap signal.

WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. Bounce-fanout is part of the Cold Emailing pillar's deliverability-safety layer, but it applies equally to multichannel campaigns when email is one of the steps.

What bounce-fanout means (plain language)

Suppose your workspace has five mailboxes ([email protected], [email protected], [email protected], [email protected], [email protected]), and a campaign with 1,000 prospects is round-robin distributing across all five. You send the first email of the sequence from sales1@ to a particular prospect, Bob — and Bob's mailbox hard-bounces (it doesn't exist, the address is closed, the domain is dead).

Without bounce-fanout, when the campaign reaches the next step (say, a 3-day follow-up), it would round-robin Bob to a different mailbox — sales2@ — and try again. Then sales3@. Then sales4@. The bounce repeats five times, once per mailbox. Each repeated bounce signals to email providers ("Gmail, Outlook, Yahoo") that all five of your mailboxes are sending to addresses that don't exist — which is the exact pattern spam-trap operators look for. Your domain's sender reputation degrades on all five mailboxes simultaneously.

Bounce-fanout fixes this. When sales1@ records a confirmed hard-bounce on Bob, the platform immediately marks Bob as 'Bounced — see Inbox' in all of your other mailboxes' campaign queues (sales2@, sales3@, sales4@, sales5@). Bob never gets emailed again from any of them. The bounce hits once, is recorded once, your domain reputation absorbs one hit — not five.

Sender-side safety — we only fan out on confirmed recipient bounces

This is the structural part most operators get wrong, so we built three layers of protection before any cross-mailbox skip fires. The platform fans out a bounce only when the bounce is a confirmed recipient-side rejection. We do not fan out on:

The combined effect: a real bounce — Bob's mailbox returns 550 5.1.1 "User unknown" — fans out across your workspace's mailboxes immediately. A misclassified bounce — your DNS hiccupped for 30 seconds and the outbound host could not be reached — does not fan out and does not mark Bob bounced. Account safety wins in both directions: we protect your reputation from real bounces, and we protect your list from false-positive skips.

What you'll see in the campaign view

When a bounce fans out, every affected prospect-mailbox combination flips to status 'Bounced — see Inbox: <reason>'. The reason string is the truncated SMTP bounce code (e.g., "550 5.1.1 The email account that you tried to reach does not exist") for the originating mailbox; the other mailboxes show "Bounced — see Inbox: bounced in {originating-mailbox}" so the audit trail is intact and you can trace where the original bounce came from.

The prospect's row in the campaign Prospects tab shows the new status. Filtering by status="Bounced" gives you the full list of fanned-out skips. The dashboard Sent counter is not affected (the original send already counted); the Bounced counter increments by one for the originating mailbox, and the other mailboxes' Bounced counters are not incremented — the original was the only real failure, and we don't want to inflate platform-wide bounce metrics with structurally-determined skips.

The prospect is permanently excluded from this campaign in your workspace. They will not be retried by any of your mailboxes on any future step. The campaign engine respects the exclusion across all sequence branches, including condition-based steps and follow-ups gated on prior responses.

How to un-skip a prospect after fixing the underlying issue

If you believe the bounce was a false positive (most often: the recipient's mailbox was temporarily over-quota, or their email server had a transient issue, or your own sender-side classifier was tripped by a third-party SMTP host outage), follow this 4-step recovery flow:

  1. Confirm the address really works. Use the WarmySender email verifier (Settings → Email Verifier → "Verify single email") or any external verifier (NeverBounce, MillionVerifier, Hunter). If the address verifies as deliverable, proceed. If it verifies as undeliverable, leave the skip in place — the platform was correct.
  2. Manually re-import the prospect. Open the campaign editor → Prospects → Add prospect (or upload a CSV with just this row). The platform creates a fresh enrollment row for the prospect, treating them as a new prospect. The old fanned-out skip rows remain in the audit log; the new enrollment proceeds independently.
  3. Manually-imported prospects are not retroactively skipped. The fanout only applies forward from the moment of the original bounce. Adding the same prospect via a fresh import bypasses the historical skip rows (no auto-merge by email; each enrollment is a separate database row).
  4. Watch the first send carefully. If the address bounces again on the fresh enrollment, the fanout fires again — this time with high confidence that the recipient really is undeliverable, since two independent campaigns have now seen the same bounce. Consider removing the address from your prospect list entirely.

There is intentionally no "un-skip" button in the campaign UI. The friction of manual re-import is a deliberate guardrail — making it too easy to un-skip a bounced prospect would re-introduce the cascading-bounce risk the fanout was built to prevent. If you have a workflow that genuinely requires bulk un-skip (e.g., you reimport your prospect database monthly with re-verified emails), use the CSV bulk-import path, which we treat as "you have explicitly re-verified these addresses."

Anti-phishing guarantee — we never email you about mailbox reconnection

Because the platform's bounce-fanout system flips many prospect statuses at once when a real bounce hits, it's a natural place for phishing attackers to target — sending an email pretending to be from WarmySender asking you to "reconnect your bounced mailbox to restore delivery."

WarmySender will NEVER email you asking to reconnect a mailbox. All mailbox-reconnection surfaces are in-app only: a badge on the affected mailbox row in Mailboxes → Reconnect Required, plus a top-of-dashboard banner if any of your mailboxes need reconnection. We do not email you with a "click here to reconnect" CTA. We do not embed a reconnect link in a transactional email. Any email asking you to click a reconnect link is not from us — report it as phishing and do not click.

The only emails WarmySender sends about mailboxes are: (1) billing receipts and invoices from Stripe, (2) trial expiration reminders 7 days and 1 day before end, (3) explicit weekly reports that you opted into (Settings → Notifications). All three of these are informational and contain zero "click to reconnect" CTAs.

Common questions

Why was the prospect skipped in 4 mailboxes after bouncing on 1?

That's bounce-fanout working as designed. When mailbox A reports a confirmed recipient-side hard-bounce on prospect P, the platform immediately marks P as 'Bounced — see Inbox' in your other mailboxes (B, C, D, E) within the same workspace. The goal is to prevent the bounce from repeating across all five mailboxes, which would signal to Gmail/Outlook/Yahoo that your entire sending domain is targeting non-existent recipients — degrading the reputation of every mailbox at once. The fanout is restricted to your workspace (not cross-customer); your team's mailboxes are protected together. See What bounce-fanout means.

Does this affect my warmup?

No. Warmup runs on a separate scheduler with its own peer-to-peer message routing — bounce-fanout only affects campaign sends and campaign-prospect status, not warmup messages. Your mailboxes continue receiving and sending warmup messages on their normal schedule. The bounce-classification pipeline that feeds bounce-fanout is a sibling of the warmup-bounce pipeline, but they operate on different message streams: campaign sends feed into the recipient-bounce handler and trigger bounce-fanout; warmup sends feed into the warmup-mailbox-pause path. The same sender-side safety guards protect both.

How do I un-skip a prospect?

There's no "un-skip" button by design (deliberate guardrail). To re-add a prospect that you believe was incorrectly skipped, manually verify their email externally (NeverBounce, Hunter, etc.), then re-import them as a new prospect via the campaign editor → Prospects → Add prospect, or via a fresh CSV import. The platform treats the re-import as a new enrollment, independent of the historical skip rows. See How to un-skip a prospect for the 4-step recovery flow.

Will this hide the bounce from my reporting?

No. The originating bounce is recorded in full (Bounced counter increments, dashboard reflects the bounce, the prospect's row shows the SMTP bounce code). What's hidden from your reporting is the cascade — we don't show 5 bounces in the dashboard when only 1 real bounce happened. The other 4 mailboxes' prospect rows show "Bounced — see Inbox: bounced in {originating-mailbox}" as a status string, but their Bounced counters do not increment. This keeps platform-wide bounce metrics honest — the bounce rate you see is the true unique-recipient bounce rate, not inflated by structural fanout.

What's a sender-side bounce vs. a recipient bounce?

A recipient bounce is when the recipient's mail server rejects the message because the recipient's mailbox doesn't exist, is full, or is closed (SMTP codes like 550 5.1.1, 553, 552). The bounce is about the recipient. A sender-side bounce is when something on the sender's path failed — your outbound mail host could not be reached because DNS hiccupped, your domain's SPF/DKIM/DMARC failed alignment, your IP was temporarily on a transient blocklist. The bounce looks like a bounce, but the recipient mailbox is fine; another sender with proper configuration would land. The bounce-fanout system only fires on confirmed recipient bounces. Sender-side bounces are short-circuited by the sender-side classifier. See Sender-side safety.

Will WarmySender ever email me asking me to reconnect a mailbox?

No. Per the anti-phishing guarantee, WarmySender NEVER sends emails asking you to reconnect a mailbox. All mailbox-status surfaces are in-app only: badges on the Mailboxes page row, dashboard banners, in-app modals. Any email asking you to click a "Reconnect mailbox" link is not from us — it's phishing. Report it and don't click. The only emails we send about mailboxes are billing receipts (from Stripe), trial-expiration reminders, and explicit weekly reports you opted into. See Anti-phishing guarantee for the full policy.

Still have questions? Email [email protected] with your campaign name and the affected prospect's email, and we'll trace the bounce path.