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.
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:
What’s interesting:
- 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
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.
Cross-connector reconciliation:
Domain-level cross-check:
Within Dotdigital, confirm the bounce spike is concentrated on one campaign / programme / list (programme-specific) vs spread across all sends (domain-wide). Programme-specific spikes are usually a contaminated import; domain-wide spikes are usually an authentication issue (DMARC / DKIM / SPF misconfiguration) or an ISP-side reputation drop.
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.