> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Bounce Spike, Dotdigital > Sudden bounce surge = list contamination after import. Cap sends until investigated. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Email Marketing](/nerve-centre/connectors#connectors-by-type) > 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) | | | | | What's interesting: 1. **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". 2. **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. 3. **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. 4. **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. 5. **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. **The actionable read**: when this alert fires, the answer is always "pause first, investigate second". The cost of a false-positive pause is one campaign delayed by an hour; the cost of a missed true-positive is a month of degraded deliverability. ## Sibling cards merchants should reference together | Card | Why pair it with Bounce Spike | | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Bounce Rate](/nerve-centre/kpi-cards/dotdigital/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](/nerve-centre/kpi-cards/dotdigital/spam-complaint-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](/nerve-centre/kpi-cards/dotdigital/sender-reputation-risk) | 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](/nerve-centre/kpi-cards/dotdigital/programme-status) | Operational. Programmes typically auto-pause on extreme bounce rates; verify status after a spike fires. | | [Suppressed Contacts](/nerve-centre/kpi-cards/dotdigital/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](/nerve-centre/kpi-cards/dotdigital/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](/nerve-centre/kpi-cards/klaviyo/bounce-spike) | Klaviyo equivalent. Same definition, same playbook. | | [Mailchimp Bounce Spike](/nerve-centre/kpi-cards/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](https://r1-app.dotdigital.com/insights/email) for the per-day bounce trend. * [r1-app.dotdigital.com → Campaigns → individual campaign report](https://r1-app.dotdigital.com/campaigns) for per-campaign bounce counts and reasons (hard / soft / spam-trap). * [r1-app.dotdigital.com → Contacts → Suppressions](https://r1-app.dotdigital.com/contacts/suppressions) to verify bounced addresses were suppressed. For ISP-side reputation visibility, check [Google Postmaster Tools](https://postmaster.google.com) for the sending domain. A bounce spike that triggers Google's filters shows up there within 24 to 72 hours. **Why our number may legitimately differ from Dotdigital's reports:** | 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. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | -------------------------------------------------------------------------------------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`klaviyo.klv_alert_bounce_spike`](/nerve-centre/kpi-cards/klaviyo/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`](/nerve-centre/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. | **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. *** ### Tracked live in Vortex IQ Nerve Centre *Bounce Spike* is one of hundreds of KPI pulses Vortex IQ tracks across Dotdigital and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.