Email reputation recovery is one of the most technically complex and commercially urgent deliverability challenges a programme can face. The path from a domain reputation event (Gmail spam rate above 0.10%, domain reputation at Low or Bad) to restored High reputation is not a switch that can be flipped — it requires sustained clean sending over weeks or months while the ISP's reputation model recalibrates on the improved signal stream. This guide documents three real-world reputation recovery scenarios with the specific actions taken, the timeline of recovery, and the outcome metrics — providing concrete reference points for programmes navigating their own recovery situations.
Case Study 1: E-commerce Complaint Spike Recovery (6 weeks)
Situation: An e-commerce programme (approximately 800,000 active subscribers, €40K/month email-attributed revenue) ran a Black Friday pre-sale campaign in early November to its full list including 180,000 contacts who had not engaged in 120+ days. The campaign generated a Gmail spam rate of 0.21% on the campaign day — well above the 0.10% threshold — and held above 0.10% for the following 3 days as the campaign continued to be opened by stragglers. Postmaster Tools domain reputation dropped from High to Medium on day 4 and was trending toward Low by day 7 when the team identified the problem.
Immediate actions (Days 1-3 of recovery): Cancelled all remaining scheduled campaigns pending investigation. Queried the accounting log for per-segment complaint rates from the Black Friday pre-sale campaign — identified that 94% of the complaint volume came from the 180,000 120-day-inactive contacts. Added all 120-day-inactive contacts to a suppression hold (not permanent suppression — a temporary hold pending requalification). Reduced planned November campaign frequency from 3x per week to 1x per week.
Recovery sending protocol (Weeks 1-4): Resumed sending after 3-day pause, limited to contacts who had opened or clicked in the past 30 days only (approximately 210,000 contacts — 26% of the active list). Campaign content was editorially focused (programme updates, useful content) rather than promotional. Complaint rate for recovery sends: 0.018% — well within target. Postmaster Tools spam rate: 0.012% on recovery campaign days. Domain reputation: stabilised at Medium, no further decline.
Expansion protocol (Weeks 5-6): Expanded to contacts who had engaged in the past 60 days (approximately 380,000 contacts). Continued monitoring complaint rate per send. By week 6, Postmaster Tools domain reputation returned to High. Resumed normal campaign cadence and full-list sends (excluding the 180,000 suppression-hold contacts) at the end of week 6.
Outcome: Domain reputation fully restored to High in 42 days. Revenue impact of the recovery period: approximately 35% reduction in email-attributed revenue for 6 weeks as reduced sending volume and audience limiting affected campaign reach. Total revenue impact: approximately €52,500 in foregone revenue versus the expected €40K/month run rate. Lesson: the 180,000 lapsed contacts should have been suppressed in September during pre-Q4 list cleaning (as recommended in the holiday deliverability guide) — the revenue cost of the cleanup done reactively after the incident was approximately 3x what the pre-Q4 cleanup would have cost in list size reduction.
Case Study 2: Spamhaus SBL Listing Recovery (3 weeks)
Situation: A B2B marketing programme (approximately 120,000 contacts, primarily corporate email addresses) received an automated MXToolbox blacklist alert on a Tuesday morning. A dedicated sending IP was listed on the Spamhaus SBL. Investigation revealed the listing was caused by a purchased lead list from a data vendor that contained a Spamhaus spam trap address — specifically, a recycled email address that Spamhaus had reclaimed and designated as a spam trap after its previous legitimate owner abandoned it. The programme's list cleaning process had not identified this address as risky because it appeared valid in commercial verification services (not listed as invalid in NeverBounce).
Immediate actions (Day 1): Removed the listed IP from the active sending pool. Routed all queued messages and new sends to the programme's other IPs. Submitted a Spamhaus SBL delisting request at spamhaus.org/sbl with documentation: identification of the spam trap hit as the cause, confirmation that the purchased lead vendor list had been completely removed from the active programme, and commitment to implement additional trap-detection measures. Simultaneously, suspended the purchased lead vendor's data from all future campaigns pending a full quality audit.
Spamhaus delisting (Days 2-4): Spamhaus reviewed the delisting request and removed the SBL listing on day 3. Delivery tests confirmed the IP was cleared from the blocklist. Postmaster Tools data for the period showed no significant domain reputation change — the Spamhaus listing affected SMTP connection acceptance at corporate gateways but did not generate enough Gmail spam feedback to affect domain reputation (the volume of B2B email to Gmail-hosted addresses was relatively small).
Root cause remediation (Days 1-14): Removed the full purchased lead vendor list (approximately 8,500 contacts) from the active list. Implemented a higher-sensitivity spam trap detection pre-screening (querying Validity TrustScore for all future list imports from any data vendor). Established a policy: no list from any external data vendor to be added to the active list without (1) independent email verification, (2) spam trap screening, and (3) 10-day quarantine observation of a 5% test cohort before full deployment.
Outcome: Full recovery in 21 days. The IP was returned to the active pool after the 3-day delisting period. No significant domain reputation impact. Revenue impact: minimal — the B2B programme had sufficient IP redundancy to maintain delivery on other IPs during the 3-day period of the affected IP being removed from rotation. Key lesson: the spam trap hit from a purchased vendor list was entirely preventable. Spam trap screening (Validity TrustScore or equivalent) would have identified the trap address before it was ever injected into the programme. The cost of the screening service ($50-200/month for a programme this size) is trivially small relative to the operational cost of managing a Spamhaus SBL listing and its delivery impact.
Case Study 3: Domain Reputation Collapse (12 weeks)
Situation: A media newsletter publisher (approximately 450,000 subscribers, primarily consumer Gmail and Yahoo addresses) experienced a prolonged domain reputation decline that reached the Bad tier at Gmail — the lowest possible reputation designation — over a 6-week period. The root cause was a multi-factor confluence: (1) the programme had been sending with the newsletter ESP's shared DKIM domain (d=esp.com) without custom domain DKIM for the past 14 months, meaning domain reputation was building on the ESP's shared domain and the programme's own domain had no reputation history; (2) a content quality shift in the newsletter (transitioning from editorial content to more advertiser-driven sponsored content) generated a gradual complaint rate increase from 0.02% to 0.11% over 3 months; (3) the programme was not monitoring Postmaster Tools during this period and did not detect the complaint rate increase until the domain reputation had already collapsed to Bad.
Discovery and initial assessment: The programme discovered the Bad domain reputation when engagement rates dropped precipitously — open rates fell from 28% to 11% over a 2-week period. Postmaster Tools investigation revealed Bad domain reputation for the newsletter sending domain (which turned out to be the ESP's shared domain, d=newsletteresp.com, not the publisher's own domain). Gmail spam rate on Postmaster Tools showed 0.31% — more than 3x the 0.10% threshold. The situation was compounded by 14 months of reputation having been built on the wrong domain.
Recovery plan (developed in consultation with deliverability specialist): Phase 1 (weeks 1-4): Set up custom domain DKIM on the existing ESP (d=newsletter.publisher.com). Register the new domain in Gmail Postmaster Tools. Send only to the highest-engagement segment (opened last 2 issues, approximately 45,000 contacts) with 2-3 emails per week — editorial content only, no sponsored content. Daily Postmaster Tools monitoring. Phase 2 (weeks 5-8): If spam rate below 0.04% and reputation tier improving, expand to 90,000 contacts (engaged in last 8 issues). Continue editorial focus. Phase 3 (weeks 9-12): Expand to full active engaged list (approximately 200,000 contacts with engagement in past 6 months) as reputation stabilises. Suppressed approximately 250,000 lapsed contacts permanently.
Recovery outcome: Domain reputation progressed from Bad to Low to Medium over the first 6 weeks. By week 8, reputation reached High for the new custom domain (newsletter.publisher.com). The old ESP shared domain (d=newsletteresp.com) never recovered and was abandoned — all sending moved to the custom domain. Full engagement rate recovery was not achieved by week 12 — the 250,000 permanently suppressed contacts were lost, reducing the effective programme size by 55%. A rebuilt programme of 200,000 highly engaged contacts replaced the previously nominal 450,000 mixed-quality list. Revenue impact: significant — 6 months of below-normal performance during partial recovery. Total recovery cost (including deliverability consultant fees, ESP dual-configuration costs, and revenue impact) estimated at 3x the annual cost of having configured custom DKIM correctly 14 months earlier.
This case study illustrates the compounding cost of multiple avoided investments: custom domain DKIM setup, Postmaster Tools monitoring, content quality management. Each individual investment is modest; the compounded cost of avoiding all three is severe.
The Universal Reputation Recovery Playbook
Drawing from the patterns in these and similar recovery cases, the universal reputation recovery protocol:
▶ Reputation Recovery Protocol
Recovery Timeline Benchmarks
| Scenario | Expected recovery time | Key variable |
|---|---|---|
| Single campaign complaint spike (spam rate 0.10-0.20%, Medium reputation) | 3-6 weeks | Quality of recovery sends; root cause fixed promptly |
| Sustained complaint elevation (spam rate 0.10%+ for 2+ weeks, Low reputation) | 6-10 weeks | Whether custom DKIM is in place; engagement quality of recovery audience |
| Domain reputation at Bad (spam rate 0.20%+ for 4+ weeks) | 10-16 weeks | Often requires new sending subdomain; full list rebuild required |
| Spamhaus SBL listing (with prompt delisting request) | 1-3 weeks | Delisting approval speed; whether root cause is fixed |
| Shared ESP pool contamination (co-tenant event) | 2-4 weeks | Whether moved to dedicated IPs or different shared pool |
Preventing Recurrence After Recovery
The recovery period is the highest-value opportunity to implement the practices that would have prevented the event in the first place. The systematic changes that should be implemented during or immediately following recovery — not deferred until the programme returns to normal: daily Postmaster Tools monitoring (with automated alerts), custom domain DKIM if not already in place, engagement-based suppression triggers in the campaign platform, and list verification on a semi-annual schedule. The programme that emerges from a reputation event with these practices implemented is significantly more resilient than the one that experienced the event — because the practices that enable early detection and root cause identification are now active rather than absent.
When to Start Fresh vs Recover
In some cases, reputation recovery on the existing domain and IP configuration is not the right strategy. The indicators that suggest starting fresh is preferable to recovery: (1) The domain reputation has been at Bad for 90+ days despite correct recovery sends — the ISP's reputation model has accumulated too much negative history for recovery sends to overcome in a reasonable timeline. (2) The root cause of the reputation event is not fixable (for example, the programme's fundamental list acquisition model generates complaint rates that exceed acceptable thresholds regardless of list cleaning). (3) The existing domain has accumulated a negative reputation signal history that associates it with spam in ISP reputation databases beyond just Gmail — Spamhaus DBL listing, Cisco Talos Poor reputation, multiple blocklist listings. Starting fresh with a new sending subdomain (newsletter2.brand.com vs the previously used newsletter.brand.com) can provide a clean reputation slate while retaining the parent domain's authentication and organisational reputation signals.
Reputation recovery is the most expensive deliverability programme any team will run — expensive in revenue lost during recovery, in operational resources devoted to monitoring and management, and in the customer relationship damage from weeks of degraded inbox placement. The best reputation recovery programme is the one that never needs to be run — and the monitoring infrastructure and list management practices documented throughout this site are the investment that keeps programmes out of reputation events in the first place. When recovery is necessary, the playbook works. Apply it systematically; monitor daily; and reputation will rebuild toward the High tier that commercial email performance requires.