About this walkthrough. A customer's own list-hygiene failure, a "temporary" safety-valve change nobody reverted, and shared-infrastructure contagion compounding into a single throttled pool — a pattern that recurs across high-volume sending programs. This is a real incident that InboxStack Brain diagnosed; the company and other senders on its platform are anonymized to protect confidentiality.
The problem
A high-volume sending ESP runs three IP pools: a shared promotional pool (five mid-size customers), a dedicated pool for its largest account, and a transactional pool under regulatory requirements. Gmail deferrals on the shared pool had climbed for two weeks and were now severe — two IPs had landed on the Spamhaus SBL, and a delisting request had come back denied:
"Listing remains until evidence of remediation of the underlying spam source is provided."
Nobody had a confirmed root cause — that’s the trap. A dashboard would show one thing moving wrong, not why, and not that it was three problems, arriving in the same two weeks, wearing the same symptom.
The evidence
Before InboxStack Brain can diagnose anything, it needs the raw material — the same feeds an experienced consultant would ask for on day one, pulled automatically instead of chased down over email:
Every batch, and whether it cleared manual review
Every send, by customer, IP, receiver, SMTP code
Spam-button reports from Yahoo, Microsoft, Comcast
Google's HIGH/MEDIUM/LOW/BAD per domain, tracking domain, IP
Who's opening and clicking, per customer, per day
Daily lookups against the lists that matter
Every config edit, release, and operator correspondence
What's actually running, not what's documented
Alone, each is close to useless — a spike, a dip, a band change, easy to explain away. The diagnosis lives in lining up all eight against the same calendar.
The investigation
No guessing which cause to chase first: every dated event goes on one timeline, and the timeline does the accusing:
The same story, day by day
Plotted daily: the lending customer’s defer rate breaks first; the other four stay flat two to three days, then converge to nearly the same severity — a pattern no weekly table shows.
Daily Gmail defer rate, Day–8 to Day 21 (Day 0 = campaign start).
The lending customer’s own numbers, week over week
| Week | Gmail defer rate | Gmail bounce rate | FBL complaints | Open rate |
|---|---|---|---|---|
| Week 1 | 1.6% | 0.5% | 2,309 | 12.86% |
| Week 2 | 2.4% | 1.1% | 4,838 | 12.01% |
| Week 3 | 13.9% | 2.4% | 11,019 | 10.28% |
| Week 4 | 39.3% | 3.6% | 19,043 | 8.94% |
That customer’s Postmaster band: HIGH → MEDIUM → LOW → BAD over the same four weeks, spam-rate score climbing in lockstep, while send volume to Gmail nearly doubled. Gmail’s own deferral text confirms both at once:
"Our system has detected an unusual rate of unsolicited mail originating from your IP address… rate limited."
The diagnosis
This wasn’t one bad actor and one bad week — three independent failures, each confirmed against dated, primary-source data, not inferred from each other or assumed just because they shared a window.
An unreviewed list-import campaign wrecked one customer's own Gmail standing
Confidence: HighRoughly 41 batches of ~41,000 records, seven per night for three weeks, each shaped to land just under the manual-review threshold — 100% auto-accepted, zero review. Four signals moved together across the same four weeks: defer rate, bounce rate, complaints, reputation score. Open rate, lowest on the platform, fell every week too.
Caveat: Google's own guidance says it doesn't reliably track opens, so low open rate alone isn't proof here — just corroborating context; the diagnosis stands on the other four signals.
Evidence: list-import log, delivery aggregates, FBL complaints, reputation series, engagement data — six signals moving together.
A "temporary" throttle fix was never reverted
Confidence: HighResponding to a growing deferral backlog from cause one, an engineer quadrupled Gmail concurrency and rate limits and disabled the back-off program, logged as temporary — live three weeks. Before/after, pool-wide:
| Defer rate | Bounce rate | |
|---|---|---|
| Before | 3.36% | 0.79% |
| After | 36.34% | 2.06% |
A documented pattern, not just this incident's numbers: a Gmail "unusual rate" deferral is a warning shot, and senders who push through tend to see mail move broadly to spam within a week — the shape the daily chart shows for the four uninvolved customers. Disabling the back-off program removed the mechanism built to respond to it.
Evidence: platform change log, logged as temporary, still live weeks later.
Two contagion channels spread the damage to customers who did nothing wrong
Confidence: Medium-highThe other four customers' Gmail defer rate breaks about three days after the lending customer's, climbing to 49.0% versus 54.3% by the end of the window (chart above) — while their bounce rate barely moves, pointing at shared-IP throttling, not a content or list problem. The hard damage lands elsewhere: the two SBL-listed IPs hard-bounce traffic at receivers that consult Spamhaus (2.91% pool bounce rate with the lending customer's traffic in the mix, 1.14% without). A second channel: five customers shared one click-tracking domain, whose reputation slipped first — three to six days before the four's own domains moved — so an IP-only fix would have missed it.
Precision matters: the Spamhaus listing and Gmail's throttling aren't the same mechanism. Gmail doesn't consult the SBL — its deferrals come from its own reputation and rate-anomaly scoring (cause 2); the SBL listing is a parallel symptom of the same collapse, hitting receivers that do consult it. The shared tracking domain is what reaches Gmail directly, scored the same way a sending domain is.
Evidence: daily telemetry, blocklist logs, bounce leave-one-out analysis, and reputation series for the shared vs. each customer's own domain.
What didn’t corroborate the story
A tidy narrative is a red flag, not a reward — RCA has to show its work on evidence that doesn't fit, not just evidence that does:
- Third-party seed-list data didn't show a dramatic collapse for the lending customer — seed panels are small, curated, opt-in sets, a different population than the bulk recipients above. Weighted lower, not discarded.
- A brief, unrelated blocklist listing on a different IP resolved days before the campaign's effects began — flagged as noise, not folded in to make the story tidier than the data supports.
The action plan
Diagnosis is half the job — here’s what changes, in what order, and what it costs someone.
Day 0 of response
- Revert the throttle relaxation — original concurrency, rate limits, and back-off program restored. This configuration already worked for three weeks; it isn’t a new guess.
- Move the offending customer off the shared tracking domain today; stagger the other four onto their own domains over two weeks. The domain was the earliest-moving signal (Day 7, before the throttle change) and reaches Gmail’s domain-level reputation directly. Flipping all five at once is its own mistake — new identities appearing simultaneously is exactly the pattern anti-abuse systems catch. Use a subdomain of the customer’s own (
mail.brightcart.io→links.brightcart.io), not a fresh generic one. - Quarantine the lending customer onto a single clean IP, capped at its recent clean throughput — not pre-incident volume, too much for one IP on day one. A real revenue cut (see below).
- Suppress the imported segment, not the whole customer — mail only the pre-campaign, engaged base; new, unreviewed contacts get zero volume until verified. Targets who’s actually being mailed, the cheapest lever for protecting revenue without reopening the risk.
- Freeze that customer’s list-import pipeline until verification, hard-bounce suppression, and opt-in confirmed.
- Leave the two unaffected pools untouched, including the one carrying regulated notices, confirmed clean by direct query, not assumed safe.
Balancing hygiene against revenue.
- Implied platform rate: ~$3.88 per 1,000 messages (backed out from revenue vs. volume).
- Single-IP cap → run-rate falls to ~9% of pre-incident level, a ~91% cut.
- Restoring the pre-campaign baseline (~1.1M/day) would preserve ~69% — but needs more warmed IP capacity than one quarantine IP has, capacity that belongs to the four customers already recovering.
- Default: accept the ~90% cut for 2–3 weeks — a relationship call, not an engineering one.
Days 1–3
Throttle, don’t zero, the two listed IPs — a live recovery signal. Hold off re-filing delisting: these blocks take one to two weeks to clear even after the behavior stops, and this plan’s own model runs 45 days. Wait a full clean week, ideally two.
Days 4–9
The platform’s largest customer has an unrelated, contractual 3x launch on its own dedicated, unaffected pool — proceeding on schedule, ramped over three days and held one day longer than scoped to avoid a step-change flag.
The ramp narrows risk; it doesn't clear it.
- Best-supported safe growth rate: ~10%/day — anomalous jumps flagged regardless of authentication quality.
- At that rate, 3x takes ~12 days, not the 3–4 here; the faster cadence is only validated at trivial cold-warmup volumes.
- An engaged base, not a cold list, lowers risk but isn't a documented exception: 3–4 days buys the date at real risk; ~12 days is safe but misses the window. This plan accepts that deliberately.
Days 6–14, extending into weeks 3–4
Reassess the quarantined customer daily: verification, hard-bounce suppression, opt-in confirmed. Five clean days isn’t enough — a list-quality collapse treated elsewhere as a 21-day process, and the same Postmaster band took two weeks to fall from HIGH to BAD. Hold two to three weeks, then ramp at 20%/week, under the ~10%/day ceiling that made the flagship launch risky. Ramp the engaged segment only, folding in the spare IP’s own seasoning history. Re-attempt delisting once the two IPs show a full clean week.
Resolution runs closer to four weeks than the two originally scoped, not a fabricated 14-day finish line. Separately: does that customer belong on a shared pool?
After the fix ships
A recommendation nobody checks on is just an opinion with better formatting — so every cause carries a confidence level tracked against before/after metrics on a window matched to how fast that problem resolves: a throttle fix shows in days, a reputation rebuild takes a month. Scoring both on one clock would count a correct diagnosis as failed for being checked too early.
All three causes share the same scoring rates. “Delivery rate” (delivered ÷ sent) counts a deferral like a bounce — “recovers” means the defer rate falling, inverted. “Spam rate” is the same Postmaster signal behind the HIGH/MEDIUM/LOW/BAD bands. The Spamhaus listing itself, and raw send volume, deliberately aren’t part of this model.
| Cause | Evaluation window | Metric & required improvement | Weight in the verdict |
|---|---|---|---|
| Throttle relaxation reverted | 10 days | Delivery rate ↑ 5%+ Bounce rate ↓ 10%+ | 75% 25% |
| List-import hygiene enforced | 21 days | Bounce rate ↓ 20%+ Delivery rate ↑ 5%+ Spam rate ↓ 10%+ | 55% 30% 15% |
| Shared-IP / tracking-domain contagion isolated | 45 days | Spam rate ↓ 30%+ Delivery rate ↑ 10%+ Bounce rate ↓ 15%+ | 55% 30% 15% |
Improvement is how much a metric must move against its baseline; weight is how much say it gets in the pass/fail call — delivery decides 75% of the throttle-fix verdict. A fix needs 0.55, not 1.0, to count as working.
Outcomes feed back into the confidence InboxStack Brain assigns each pattern — a success nudges it up, a miss down, shrinking over time. The causes it leads with next time aren’t hand-tuned; they’re the ones that have held up.
Over to you
Every real trade-off here was left as a named decision, not a resolved one — three are genuinely arguable, and we’d rather hear where you land than pretend there’s one clean answer:
- The revenue call. Hold the customer that caused the incident at roughly 9% of its run-rate for two to three weeks while it earns its way back — or pull an already-warmed IP from the four customers who did nothing wrong, to get its revenue back faster at their expense?
- The ramp. Compress the flagship customer's contractual launch into a 3–4 day ramp that the evidence says still carries real step-change risk — or tell a customer representing a huge share of platform revenue that their launch date has to move?
- The blast radius, going forward. This plan now moves all five pool customers onto their own tracking domains, not just the one that caused the incident — staggered over two weeks, not all at once, since flipping everyone simultaneously pattern-matches automated abuse detection. Is staggered full isolation the right permanent default for every future customer on a shared pool, even before there's ever a problem — or is that overkill outside an active incident, with reactive isolation once a tenant demonstrates risk good enough?
We think the framework holds up: correlate everything, name every trade-off, let the people who own the relationships decide. Tell us where you’d call it differently.
The layer InboxStack Brain runs automatically.
Dashboards tell you Gmail is unhappy. Finding out why — which cause to fix first, and what each fix costs — is the correlation work this walkthrough did by hand.
The InboxStack Brief
Stay ahead of every inbox change
Weekly digest — authentication shifts, blacklist actions, provider policy updates. Free.