Sudden bounce surge = list contamination after import. Cap sends until investigated.
At a glance
Triggers when the trailing 24-hour bounce rate exceeds the 30-day baseline by more than 2 standard deviations. The fastest detection of list contamination, a freshly-imported address list of dead emails will burn sender reputation within hours; the alert intercepts before reputation damage compounds. Pause the affected campaign / programme until investigated.
| What it counts | (bounce_count_last_24h ÷ delivered_count_last_24h) compared to a 30-day rolling baseline mean and standard deviation. Fires when the 24h rate exceeds mean + 2σ. |
| Definition of “sent” | Delivered + bounced sends, i.e. attempted deliveries. Queued-but-not-yet-attempted is excluded from both numerator and denominator. |
| Open rate basis | n/a, this is a bounce-spike alert. |
| Bounce handling | Hard + soft bounces combined. Hard bounces (permanent, the address doesn’t exist or the domain is dead) are the strongest signal; soft bounces (mailbox full, temporary issue) contribute but don’t usually drive 2σ alerts on their own. The card surfaces both because a soft-only spike often becomes a hard spike on the next retry. |
| Spam-trap hits | Counted as bounces by Dotdigital’s rules. Spam-trap hits are the most reputation-damaging category and the most actionable signal in this card’s firing pattern. |
| Attribution model | n/a, this is an operational alert, not an attribution metric. |
| Currency | n/a. |
| Channel coverage | Email only. SMS bounces are tracked separately and do not feed this alert. |
| Baseline computation | 30-day rolling baseline excludes the most recent 24 hours (so the alert isn’t comparing the spike against itself). |
| Time window | 24H for the spike detection; 30D for the baseline. |
| Alert trigger | >2σ vs 30D baseline, i.e. ~95th percentile of normal variation. Roughly 5% false-positive rate is expected; tune to >3σ for noise reduction at the cost of slower detection. |
| Roles | owner, marketing, engineering |
Calculation
Calculated automatically from your Dotdigital data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK DTC homewares brand on BigCommerce + Dotdigital. The marketing team imported a list of 24,200 contacts purchased from a “lifestyle brand event partnership” on the morning of 09 Apr 26 and added them to the Spring promotion send. Hour-by-hour bounce rate on the Spring promotion send vs the 30D baseline:| Hour | Sends | Bounces | Bounce rate | 30D baseline | σ from baseline |
|---|---|---|---|---|---|
| 09:00 | 14,200 | 168 | 1.18% | 0.42% | +1.2σ |
| 10:00 | 18,400 | 412 | 2.24% | 0.42% | +3.4σ ALERT FIRED |
| 11:00 | 22,800 | 1,624 | 7.12% | 0.42% | +13.6σ ESCALATED |
| 12:00 | (paused by alert response) |
- The alert fired at 10:00 on a 3.4σ deviation. The 09:00 hour was elevated but within the 2σ noise band; the 10:00 reading triggered it cleanly. The alert beat the merchant’s own dashboard observation by roughly 90 minutes, which on a list-contamination event is the difference between “minor reputation hit” and “domain reputation crash that takes 4 to 6 weeks to recover”.
- The 11:00 reading at 7.12% is catastrophic. A bounce rate above 5% triggers ISP-side throttling (Gmail and Microsoft both throttle at this threshold); above 10% domains start getting blacklisted by major spam filters. The 11:00 hour saw 1,624 bounces; even one more hour at this rate would have permanently damaged the brand’s sending domain reputation.
- The cause was a contaminated import list. Of the 24,200 purchased contacts, post-incident analysis showed 18% (~4,400) were spam-trap addresses (purpose-built honeypot accounts that mailing-list vendors leak into resold lists). Spam traps are the worst-case bounce because they hit reputation algorithms at multiple ISPs simultaneously.
- The alert response is a 4-step playbook: (a) immediately pause the campaign / programme; (b) suspend further sends to any contact added in the previous 7 days; (c) run a list-validation tool (e.g. Dotdigital’s built-in validator, or NeverBounce / Kickbox) on the suspect import; (d) only resume sending after 24 to 48 hours of low-volume warm-up to rebuild reputation.
- The merchant’s recovery window was 9 days. Open rates on the same brand domain dropped 40% on Day 1 post-incident (Gmail throttling) and recovered linearly back to baseline by Day 9. Without the alert intercepting at 10:00, the recovery would likely have stretched to 4 to 6 weeks because bounces would have continued through the full send.
Sibling cards merchants should reference together
| Card | Why pair it with Bounce Spike |
|---|---|
| Bounce Rate | The trend view. Bounce Spike is the alert layer; Bounce Rate is the dashboard layer. Use the spike for “act now”; use the rate for “trend over weeks”. |
| Spam Rate | The companion alert. Bounce spikes and spam complaints often co-move during reputation incidents; if both fire, the issue is severe. |
| Sender Reputation Alert | The downstream impact. A bounce spike sustained over 24 to 48 hours produces a sender-reputation drop; this alert detects the cause, the reputation alert detects the effect. |
| Programme Status | Operational. Programmes typically auto-pause on extreme bounce rates; verify status after a spike fires. |
| Suppressed Contacts | The recovery view. Post-incident, the suppression list grows by the bounce count; verify the bounced addresses were correctly suppressed before resuming sends. |
| Subscriber Growth | The supply-side context. A sudden subscriber surge often precedes a bounce spike (imported list, viral acquisition burst). Pair to detect contamination patterns. |
| Klaviyo Bounce Spike | Klaviyo equivalent. Same definition, same playbook. |
| Mailchimp Bounce Spike | Mailchimp equivalent. |
Reconciling against the vendor’s own dashboard
Where to look in Dotdigital: Dotdigital does not expose a “bounce spike” alert natively, but the underlying inputs are visible in:- r1-app.dotdigital.com → Insights → Email Insights for the per-day bounce trend.
- r1-app.dotdigital.com → Campaigns → individual campaign report for per-campaign bounce counts and reasons (hard / soft / spam-trap).
- r1-app.dotdigital.com → Contacts → Suppressions to verify bounced addresses were suppressed.
| Reason | Direction | Why |
|---|---|---|
| Real-time vs reported. Vortex IQ reads bounce events as they arrive at Dotdigital; some Dotdigital reports lag by 30 to 90 minutes. | Vortex IQ leads | This is the point, the alert beats the reporting view. |
| Hour bucketing. Vortex IQ uses rolling 24-hour windows; Dotdigital reports use calendar-day buckets. | Boundary effects | The 2σ alert is robust to bucketing differences. |
| Hard vs soft separation. This card pools both; Dotdigital reports often split. | None on rate; differs in attribution | A spike driven by hard bounces requires more aggressive response than one driven by soft bounces. |
| Time-zone. Dotdigital reports run on account locale; Vortex IQ on UTC. | Boundary days off | Doesn’t affect the spike-detection logic. |
Threshold tuning. The default >2σ produces ~5% false-positive rate. | Sensitive | Tune to >3σ for noise reduction; tune to >1.5σ for early detection. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
klaviyo.klv_alert_bounce_spike | Same definition, same alert playbook | Klaviyo and Dotdigital use different ISP-side delivery infrastructure; the same merchant’s bounce events on each platform are independent populations and won’t co-fire unless both share the contaminated list. |
bigcommerce.bc_email_capture_rate | Inverse leading indicator | A surge in email capture (rapid import) often precedes a bounce spike by 24 to 72 hours. If both move together, the new captures are likely contaminated. |
Known limitations / merchant FAQs
The alert fired. What’s the playbook? Four steps in order, total time roughly 30 minutes. (1) Immediately pause the affected campaign / programme via Dotdigital. (2) Identify the source population: was a list imported in the last 24 to 72 hours? Was a programme entry trigger recently changed? Was an integration’s contact-sync misconfigured? (3) Validate the suspect list using a list-validation tool (Dotdigital built-in, or NeverBounce / Kickbox externally). Expect 8 to 25% of contaminated lists to fail validation. (4) Resume sending only after a 24 to 48 hour low-volume warm-up to small high-engagement segments first; rebuild reputation before broad sends. False positives, what causes them? Three common patterns. (a) A fresh campaign to a recently-imported audience that’s legitimate but new, the merchant doesn’t have engagement history, so a normal-by-industry bounce rate of 3 to 5% looks like a 3σ deviation against the merchant’s typical 0.4%. (b) A small overnight send where 3 of 50 sends bounce, statistically a 6% rate, which trips the alert despite being only 3 absolute bounces. (c) A holiday or peak send to a list that hasn’t been mailed in 30+ days, dormant addresses bounce at higher rates. The card surfaces the absolute count alongside the rate to help triage; small absolute counts are usually safe to ignore. Should I auto-pause programmes when this fires? Yes for high-volume programmes; no for small lifecycle programmes. Auto-pause logic should consider absolute bounce count (>200 in an hour) AND the rate threshold, not just the rate. Pause-and-investigate is the safer default; the cost of a 1-hour false-positive pause is small. My alert keeps firing on the same campaign every Monday morning. Is it broken? Probably not. Monday-morning campaigns to weekly-engagement audiences often see slightly elevated bounces because overnight mailbox cleanup at major ISPs purges dormant addresses, the bounces show up the first time you send post-cleanup. If the spike is consistent and never escalates beyond 3σ, raise the alert threshold to>3σ for that specific campaign. The pattern is real but not actionable.
The alert fired but my campaign doesn’t look broken. What do I do?
Check three things in sequence. (a) Authentication: are SPF, DKIM, and DMARC configured correctly for the sending domain? An expired DKIM key produces silent authentication failures that ISPs treat as soft bounces. (b) Domain reputation: check Google Postmaster Tools and Microsoft SNDS for any sudden reputation drop on the sending domain. A reputation issue elsewhere can cause bounces on this campaign too. (c) List health: even if no recent import, sleeper-trap addresses on a long-stable list can suddenly activate. The fix is a periodic list-cleanse cycle (every 6 to 12 months) using Dotdigital’s built-in re-engagement programme to suppress non-engagers.
What’s a “spam trap” and why is it so dangerous?
A spam trap is an email address created by ISPs and anti-abuse organisations specifically to catch senders using bad-quality lists. Hitting one tells the ISP “this sender is mailing addresses they shouldn’t have”; the punishment is rapid reputation degradation across the entire sending domain. Spam traps appear in: (a) purchased lists (the most common source), (b) lists scraped from public web sources, (c) very old un-cleansed lists. The card pools spam-trap hits with bounces; if the bounce surge has spam-trap signatures (Dotdigital flags these in the bounce reason), the response should be more aggressive (suspend the entire suspect import, run full list validation, consider rotating the sending IP).
My open rate dropped 30% the day after a bounce spike. Will it recover?
Yes, typically over 7 to 14 days, though severity depends on which ISPs throttled. Gmail throttling clears within 5 to 10 days of low-bounce sending; Microsoft (Outlook / Hotmail) takes 7 to 21 days; Apple iCloud is fastest at 3 to 7 days. The recovery is linear, send to high-engagement segments only, build engagement signals (opens, clicks), and avoid further sends to any contact added in the contamination window.
Why is the threshold >2σ and not just a fixed bounce rate?
A fixed threshold (e.g. “alert if bounce rate >2%”) fails for two reasons. (a) Different merchants have different baselines: a B2B SaaS sender might run at 0.1% normally; a consumer fashion brand at 0.6%. (b) Different campaigns have different baselines: re-engagement sends always bounce more than transactional. A standard-deviation threshold adapts to each merchant’s and each campaign’s normal pattern, alerting only on meaningful deviations. Tune to your tolerance for false-positives vs detection latency.