Reputation and IP warming series. This is the tactical guide to recovering an IP that lost its reputation. For related guides on IP warmup, domain reputation, and the warmup calculator, see the reputation and warming hub →
Quick recovery reference
A cold IP in recovery is not the same as a cold new IP. This is an IP that used to send but crashed: blocked, throttled, or thoroughly spam-foldered. Recovery is not warmup with different vocabulary; it requires diagnosis of what broke, remediation of the trigger, then a slower and more careful ramp than a first-time warmup. Rushing recovery causes second crashes that are harder to recover from than the first.
| Recovery vs warmup | Recovery starts from a negative baseline; new warmup starts from neutral |
| Timing | 2-4 weeks for mild damage; 6-8 weeks for severe; sometimes never |
| Prerequisite | Root cause identified and fixed |
| Diagnostic tools | Postmaster Tools, SNDS, Sender Score, blocklist queries, DMARC reports |
| Volume start | 10-20 percent of pre-crash baseline, engaged segments only |
| Abandonment threshold | No metric improvement after 8-12 weeks of disciplined recovery |
Who this guide is for
- Deliverability team facing a crash right now
- Emergency responder debugging a delivery drop
- Ops lead planning rebuild after a reputation incident
What you’ll learn
- Diagnostic checklist (Postmaster, SNDS, blocklists, DMARC)
- Root cause categorization and the recovery playbook
- Timing per severity and when to abandon the IP
The reputation and warming series (4 guides)
1. IP warmup schedule
The day-by-day ramp for new IPs
2. Domain vs IP reputation
Which score matters where in 2026
3. Warmup calculator
Formulas, Python and tables per target
4. Cold IP recovery
READINGWhen reputation crashed and you rebuild
Reputation crashes are one of the most stressful events in email operations. Yesterday your delivery rate was 98 percent; today it is 62 percent, and your team is trying to figure out what happened. The instinct is to send less and pray. The correct response is more structured: diagnose first, fix the root cause, then rebuild via a specific playbook. This guide covers the diagnostic phase, the recovery playbook, the timing you should expect, and the point at which you accept that the IP is gone and start fresh.
Recognizing a crashed IP
Symptoms, in order of severity:
- Delivery rate drop. From 95-98 percent to 60-80 percent over 1-3 days.
- Provider-specific throttling. One receiver (usually Microsoft or a spam filter) starts rejecting connections with 421 or 450 codes.
- Postmaster Tools reputation drops. Domain or IP reputation moves from High/Medium to Low or Bad.
- SNDS turns Yellow or Red. Microsoft’s IP reputation signal.
- Sender Score drop. Below 70 is warning; below 50 is crisis.
- Blocklist listing. Spamhaus, Barracuda, or SORBS lists the IP.
- Complete block. All connections from the IP get rejected.
The first three often appear together and signal an early crash. The last three indicate mature or acute damage. Recovery difficulty scales with severity: mild cases recover in 2 weeks, severe cases need 8 or more.
Real-world crashes: which recovery path fits your situation
Shared IP on SendGrid, delivery dropped to 65 percent
MILDContact SendGrid deliverability support. Pool degradation is not your recovery to run alone; they may move you to a different pool or throttle a bad neighbor. Meanwhile, cut your volume to top 30 percent engaged only.
Timing: 3-7 days · Frequency: normal cadence, reduced volume · Blocklist check: not needed initially
Self-hosted Postfix, Spamhaus SBL listing appeared overnight
MODERATEIdentify the spamtrap source in your recent imports, purge affected addresses, request Spamhaus delisting via their form. Do not resume sending until delisted. Then rebuild at 15 percent of pre-crash volume, engaged-only.
Timing: 4-6 weeks · Frequency: M/W/F only for first 2 weeks · Blocklist check: daily until delisted
Dedicated IP compromised, mass complaint spike from unknown sends
SEVERERotate all credentials and API keys immediately. Audit access logs for the last 30 days. Verify no rogue sends since detection. Full 72-hour pause, then engaged-only rebuild. Consider abandoning the IP if no metric recovery after 8 weeks.
Timing: 8-16 weeks or migrate · Frequency: paused 72h then daily engaged-only · Blocklist check: weekly across all major DNSBLs
Phase 1: Diagnosis (before any recovery attempt)
Do not send anything until you have identified the root cause. Sending during an undiagnosed crash makes it worse.
Check every reputation signal
| Tool | What it tells you |
|---|---|
| Google Postmaster Tools | Gmail-specific reputation for domain and IP |
| Microsoft SNDS | Per-IP reputation at Microsoft |
| Sender Score | Cross-network aggregate score |
| Blocklist checker tools | Whether Spamhaus, Barracuda, SORBS, and 40+ others list the IP |
| DMARC aggregate reports | Auth failures across all receivers |
| Your outbound log | Which receivers reject, at what rate, with what SMTP codes |
Categorize the trigger
Almost every crash falls into one of these categories:
List quality issue
Symptoms: bounce rate spike (5%+), high 5.1.1 codes, low engagement. Cause: an import contained dead addresses, purchased addresses, or spamtraps. Fix: identify the import, remove or verify affected addresses, cross-check all subsequent imports.
Content or targeting issue
Symptoms: complaint rate spike (0.3%+), engagement drop but no bounce increase. Cause: a specific campaign or template triggered mass complaints. Fix: identify the campaign, remove it from rotation, audit similar templates.
Authentication broken
Symptoms: high 5.7.x rejections, Authentication-Results showing dkim=fail or dmarc=fail. Cause: DKIM selector rotated incorrectly, SPF record hit lookup limit, DNS misconfiguration. Fix: audit auth setup; see our SPF, DKIM, and DMARC guides.
Blocklist listing
Symptoms: sudden 100 percent rejection at multiple receivers, all with 5.7.1 policy codes. Cause: reported spam, spamtrap hits, or /24 block reputation issue. Fix: request delisting per blocklist procedure; do not resume sending until delisted.
Volume anomaly
Symptoms: throttling begins hours after a large campaign, spam folder placement rises. Cause: sudden volume spike (2x+ from baseline) triggered receiver alerting. Fix: reduce to previous baseline volume immediately.
Compromised account or credential leak
Symptoms: unexpected mail going out, unfamiliar recipient lists, sudden complaint spike from unknown sources. Cause: sending credentials leaked; someone else is sending as you. Fix: rotate all credentials, invalidate API keys, audit access logs.
Phase 2: Recovery playbook
Once the root cause is identified and fixed, execute the recovery playbook. This is more careful than a fresh warmup.
Step 1: Pause completely (24-72 hours)
Stop all sending from the affected IP for at least 24 hours after fixing the trigger. If the crash was severe (blocklist listing, Bad reputation), pause for 72 hours. This lets receiver reputation systems observe the absence of bad behavior and start decaying the negative signal.
Step 2: Verify the trigger is truly fixed
Before resuming, confirm the root cause is addressed:
- List quality: run all imports through email validation.
- Content: remove the offending campaign from rotation, audit similar templates.
- Auth: verify SPF, DKIM, DMARC pass on a test send.
- Blocklist: confirm delisting via blocklist checker tools.
- Volume: set send-rate caps in your infrastructure to prevent recurrence.
Step 3: Resume at 10-20 percent of pre-crash baseline
Not zero, but very low. If pre-crash daily volume was 100,000, restart at 10,000-20,000. Send only to your most engaged segment: 7-day openers, top 5-10 percent by engagement score.
Step 4: Ramp on the same 30/60/90 pattern, but slower
Use the 30/60/90 schedule methodology, but with a lower growth rate. Where a fresh warmup uses 40 percent daily growth, recovery uses 25-30 percent. The IP has negative history to overcome; slower is safer.
Step 5: KPI checkpoints at half the tolerance
During recovery, be twice as sensitive to KPI drift:
- Bounce rate ceiling: 1 percent (vs 2 percent in fresh warmup).
- Complaint rate ceiling: 0.05 percent (vs 0.1 percent).
- Any single Bad-scoring day: hold for 5 days, not 3.
Step 6: Sustain at target for 2 weeks before declaring done
Reaching your pre-crash volume is not the end. Send at target for 2 weeks with tight KPI monitoring before considering the recovery complete. Re-crash risk is highest in the first 2 weeks at full volume.
Expected timing
| Severity | Diagnostic phase | Recovery ramp | Sustain | Total |
|---|---|---|---|---|
| Mild (delivery rate 80-95%) | 1-3 days | 10-14 days | 7-14 days | 2-4 weeks |
| Moderate (Postmaster Low, some blocking) | 2-5 days | 21-35 days | 14 days | 5-8 weeks |
| Severe (Postmaster Bad, blocklist listing) | 3-7 days | 35-56 days | 21 days | 8-12 weeks |
| Critical (compromise, mass blocklists) | 1-2 weeks | 56+ days | 28 days | 12-16 weeks or abandon |
These are typical durations for disciplined recovery. Faster is possible with luck but not reliable. Slower is likely if the underlying issue is not fully resolved.
When to abandon the IP
Not every crash is recoverable. Abandon and start fresh on a new IP if:
- No metric improvement after 8-12 weeks of disciplined recovery. The IP is permanently marked.
- Multiple concurrent blocklist listings that cannot be delisted. Some blocklists (Spamhaus SBL for specific patterns) will not delist even after remediation.
- Historical /24 block reputation problem. The IP is in a bad neighborhood; the block’s aggregate reputation drags any individual IP down.
- Compromised account with unrecoverable trust loss. If the crash was caused by attacker use of your IP, receivers may permanently distrust it.
Migrating to a new IP is not a defeat; it is the correct answer when recovery math does not work. The new IP starts fresh; your domain reputation (see domain vs IP reputation) carries over. Warmup the new IP using the standard 30/60/90 schedule.
Prevention: reducing crash probability
List hygiene
Verify every import before sending. A single bad import causes most crashes; catching it before send prevents 80 percent of the risk.
Volume ceilings
Set hard caps in your sending infrastructure at 120 percent of steady-state volume. This prevents accidental volume spikes (buggy scheduler, template misfire, imported list of unexpected size).
KPI monitoring with alerts
Automate daily reputation checks (Postmaster, SNDS, blocklists). Alert on any threshold breach. Waiting until Monday to notice a Friday problem gives receivers 3 days to bake in the bad reputation.
Segmentation by risk
Route your riskier sends (cold outreach, re-engagement to lapsed users) through a separate IP or subdomain. If they cause a crash, the damage stays isolated.
Slow rollout of changes
Never change auth, sending domain, ESP, or major template on your primary sending path without staged rollout. Small segments first, full volume last.
Documented incident response
Write the recovery playbook down before you need it. When a crash happens at 11 PM on a Friday, no one wants to invent the response from scratch.
10 common cold IP recovery mistakes
- Sending during the diagnostic phase. Continuing to send while diagnosing extends the damage. Pause first.
- Skipping root cause identification. Recovery without fixing the trigger causes immediate re-crash.
- Restarting at pre-crash volume. Reputation systems remember; you need to restart low and rebuild.
- Using engaged segments for the first send but reverting to full list quickly. The ramp needs full 2-4 weeks of engaged-only sending; not just the first day.
- Ignoring blocklist delisting. A blocklisted IP cannot recover; delisting is a prerequisite, not an optional step.
- Applying fresh-warmup growth rates. Recovery is slower than fresh warmup; use 25-30 percent, not 40-50 percent.
- Declaring recovery complete when volume is reached. Sustain at target for 2+ weeks before declaring done.
- Fighting for a doomed IP. Some crashes are unrecoverable. Recognize the 8-12 week no-improvement signal and migrate.
- Not updating documentation post-recovery. Every recovery teaches you something; document it for the next incident.
- Recovering the IP but not fixing the underlying operational gap that caused the crash. If the crash was caused by no volume monitoring, recovery without adding monitoring guarantees repeat.
Cold IP recovery FAQ
Can I recover a blocklisted IP or should I abandon it?
Depends on the blocklist and the reason. Spamhaus SBL for spamtrap hits is delistable via their process, but the underlying reason must be fixed first (identify the source of spamtraps, purge affected addresses). Barracuda listings are usually delistable via their form. SORBS is delistable but slow. Some blocklists (Spamhaus DBL for domain-level spam patterns) are much harder. If two or more major blocklists list the IP concurrently, abandonment is usually faster than recovery.
How do I tell if the crash is IP or domain reputation?
Check Postmaster Tools: it shows separate scores for domain and IP. If domain is High but IP is Low, the problem is IP-specific (migrate). If domain is Low, the problem is broader and cannot be escaped by IP migration alone; you need domain recovery (see domain vs IP reputation). If both are Low, you have compounding problems and need to address both.
Should I use warmup services during recovery?
Cautiously, and only after the root cause is fixed. Warmup services simulate positive engagement, which can help early recovery, but they cannot compensate for continued bad behavior (still sending to bad addresses, still triggering complaints). Use them as a supplement in weeks 1-2 of recovery. Do not rely on them to substitute for real remediation.
Can I recover an IP without knowing the exact root cause?
Very difficult. Blind recovery (pause, resume at low volume, hope) sometimes works for mild cases but has a high re-crash rate. Diagnosis is not optional; the reputation systems have observed specific bad patterns, and if you cannot identify what those patterns were, you cannot reliably prevent them from recurring. Invest in diagnosis before recovery attempts; a week of investigation is faster than three months of failed recovery.
Is recovery different for shared vs dedicated IPs?
Yes. For dedicated IPs, recovery is fully your responsibility and follows this playbook. For shared IPs, the ESP owns the pool’s reputation; contact your ESP’s deliverability team. If the pool has degraded because of another sender in the pool, your ESP may move you to a different pool. If your own sending is contributing to pool degradation, your ESP may throttle your account until you fix. Communication with your ESP is the first step.
How long should I try to recover before migrating?
8-12 weeks of disciplined effort is the typical horizon. If Postmaster Tools shows no improvement in domain or IP reputation after 8 weeks, and blocklists remain listed, and delivery rates stay well below your pre-crash baseline, migration is the pragmatic answer. Migration is not a defeat; it is a business decision. Some IPs are permanently marked and no amount of effort will recover them; recognizing that early saves months of frustration.
Final words
Recovery is the discipline of unlearning bad reputation. It requires more patience than warmup because you are working against negative history rather than building neutral history from scratch. Some crashes recover in 2 weeks; some take 12; some do not recover and migration is the answer. The right response comes from disciplined diagnosis, disciplined remediation, and disciplined ramping, always in that order.
The mental model to keep: the receivers are asking, day after day, “has this IP changed?” Every good sending day answers “yes.” Every bad day answers “no, they are still doing the thing that got flagged.” Recovery is a conversation, not a broadcast; every day you send determines whether the reputation model updates positively or negatively. Rushing accelerates the negative answers.
This closes the reputation and IP warming series. For the full picture, see the earlier articles: the 30/60/90 warmup schedule, domain vs IP reputation, and the warmup calculator.
For related content, see the best warmup tools review, the foundational warm-up guide, Sender Score, Google Postmaster Tools, blocklist monitors, the Google and Yahoo bulk sender rules, and the Deliverability hub.
List quality is the prevention side of recovery.
SMTPing catches invalid addresses, disposables, catch-all traps, role accounts and dead mailboxes at collection. Most crashes start with a bad import; verifying every list is the cheapest crash prevention available. 13 validation types, 25 free daily.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
