Warmup Bounce Classification — how WarmySender protects mailboxes from cascade-pauses
WarmySender protects your mailboxes from being unfairly paused due to misclassified bounces (NDRs). A bounce — also called a non-delivery report (NDR) — is a message a mail server sends back when delivery to a recipient fails. Some bounces are real (the address doesn't exist, the mailbox is full), and some are misleading (a retry-in-progress notice, a sender-side problem misreported as a recipient problem, a transient delay). The platform applies a 4-layer defense so that a single misclassified bounce cannot poison the global blocklist or cascade-pause warmup across many customer mailboxes that share the same recipient domain in their peer pool.
Why this exists — the bounce-cascade bug class
Before the 4-layer defense landed in May 2026, a single misclassified bounce reported by one sender mailbox could trigger this chain: (1) the inbox scanner sees a mailer-daemon NDR and routes it to the bounce classifier, (2) the classifier defaults the unrecognized severity to soft, (3) the soft-bounce tracker eventually promotes the recipient domain to the global blocklist, (4) every warmup mailbox at WarmySender that has the bouncing recipient domain in its peer pool is auto-paused, with 'recipient domain bouncing' shown as the reason. A retry-warning email (e.g. "warning: message X delayed 24 hours, still being retried") that should have been ignored could thus pause dozens of paying-customer mailboxes overnight. On May 15, 2026 we found 96 paying-customer mailboxes across 26 workspaces silently paused over 14 days from exactly this fingerprint. The 4-layer defense closes the bug class structurally.
Layer 1 — Sender-side error classifier
A send-time guard that runs before any bounce is attributed to the recipient's domain. It asks one question: is this error actually about the recipient, or is it about the sender's own setup? Sender-side problems — an unverified sending domain, a missing DKIM signature, a lookup failure on the sender's own mail host, or the sender's own provider throttling them — are classified as sender-side and are NEVER added to the recipient-domain blocklist. The check lives in one place, so no other part of the platform can accidentally bypass it.
Layer 2 — Retry-warning skip in the inbox scanner
Bounces are detected by reading the delivery notices that land in the sender's own inbox. Before any such notice is treated as a bounce, we scan its subject and opening text for retry-warning language: 'delayed N hours', 'still being retried', 'warning: message… delayed', 'delivery delayed', 'still trying to deliver'. If any of those match, the notice is skipped entirely — it never reaches the classifier, never increments the bounce counter, and can never lead to a blocklist entry. Retry warnings are transient delays that almost always succeed on the next attempt; they are not real bounces.
Layer 3 — N≥2 distinct-sender corroboration before any blocklist add
The structural evergreen fix. Even when a bounce IS terminal — the recipient's mail server genuinely rejected the message as undeliverable — the platform now requires at least two different sender mailboxes to report a bounce for the same recipient domain within a 60-minute window before any global blocklist entry is added. A single-sender bounce is tracked (so a second sender's bounce can corroborate it later) but is never acted on alone. This means one misclassified bounce, whatever its error pattern or severity, structurally cannot add a recipient domain to the global blocklist. Both the number of corroborating senders and the length of the window are configurable, and the tracking survives restarts; stale entries are pruned every 15 minutes so old reports can't corroborate a new one.
Layer 4 — Cascade-pause sentinel firing within 5 minutes
Every 5 minutes we count how many mailboxes have just been paused for a bouncing recipient domain. If more than five have been paused in that window, an internal alert is raised. The alert is throttled to once every 30 minutes so a legitimate large cleanup doesn't flood us. It is observation only — it never re-enables mailboxes on your behalf; turning warmup back on is always your decision. This guarantees that even if all three preceding layers somehow fail and a cascade of pauses begins, we see it within 5 minutes and can step in.
What this means for you
- If your warmup is paused because a recipient domain was bouncing, that domain reached the global blocklist only after at least two separate senders corroborated it — it is a real, multi-sender-corroborated bounce signal, not a misclassification. Open Mailboxes → click the affected row to see the specific recipient domain. To re-enable: toggle warmup back on; the system will retry the recipient and re-add the domain to the blocklist if the bounce is still happening.
- If you suspect a misclassification (e.g. a known-good recipient domain like google.com or microsoft.com appearing in your pause reason), email [email protected] with the mailbox ID and the recipient domain — we will check the corroboration trail and either confirm the bounce or remove the blocklist entry. The blocklist is per-platform (global), not per-customer; removing an entry helps all customers.
- Pause reasons are surfaced in two places: the mailbox row on the Mailboxes page, and — during a wave of pauses — the Reconnect Required banner. A safety rule in our database rejects any pause that arrives without a reason, so you should never see a paused mailbox without one.
Companion docs
- /documentation#mailbox-reconnection — the related Reconnect Required badge and banner explainer (for sign-in related pauses).
- /documentation#bounce-shield — the optional workspace-wide bounce-rate protection on outbound campaign sends (separate from the warmup peer-pool blocklist described above).