# The Sending-Domain Recovery Runbook: Blocklist Hit to Restored Inbox

*You will diagnose the exact blocklist and cause, run the recovery sequence in order, decide whether to repair or retire the domain, and declare recovery against real thresholds.*

- Canonical URL: https://www.refolk.ai/guides/sending-domain-recovery-runbook
- Pillar: Process, data, and compliance
- Format: Playbook
- Published: 2026-10-10
- Last reviewed: 2026-10-10
- Reading time: 17 min
- Keywords: recover blacklisted email domain, sender reputation recovery, delist from spamhaus, sending domain blocklist recovery, fix domain reputation cold email

## Key takeaways

- Gmail restores mitigation eligibility only after your user-reported spam rate stays below 0.3% for 7 consecutive days, so one clean day is not recovery.
- A single rough campaign at three complaints per thousand delivered messages can tip a compliant domain over the 0.3% cliff in a single day.
- Domain reputation follows the domain across ESPs and IP changes, so switching providers to escape damage is a false escape that returns the same collapse.
- Severity sets the clock: a minor dip clears in 2 to 4 weeks, one listing in 4 to 8 weeks, and a burned domain can take 8 to 16 weeks or 6+ months.
- In Refolk's index just 455 US and 72 UK professionals carry an email-deliverability skill, a 6.3x gap, and the expertise clusters inside ESPs like Klaviyo and ActiveCampaign.
- Delisting before the triggering behavior is fixed gets denied or re-lists within days, because operators and providers key removal to a genuine permanent fix.

Your outbound replies collapsed overnight, a sending domain is sitting on a blocklist, and your sourced contacts have gone dark. This runbook is for the operations owner answerable for the sending program - RevOps, recruiting ops, or whoever signs off on how mail leaves the building. It gives you an ordered recovery sequence with named-blocklist diagnosis, explicit recovery thresholds, and a repair-versus-retire decision gate, so you can restore the inbox without burning the domain further.

Most deliverability guides cover proactive warm-up, per-address send verdicts, or suppression scrubs. None of those help when the fire is live. This is the reactive emergency runbook: what to do, in what order, and what a good result looks like at each stage.

## What this emergency actually is

A sending-domain blocklisting is a reputation event: one or more mailbox providers or blocklist operators have decided your mail is untrusted, and they stop accepting it at scale. The first job is to confirm that is what happened, because the symptom - replies collapsing overnight - has cheaper causes.

A single broken DKIM record, an MX outage, or a routing fault mimics a blocklisting exactly. If you misread one of those as a reputation event, you start a weeks-long re-warm when a DNS fix would have restored flow in an hour. So before anything else, pull the actual SMTP rejection text and run a blocklist lookup. If there is no positive listing, you do not have this emergency.

If there is a listing, understand what you are fighting. Reputation is a rolling trust window, not a switch. The recovery clock does not start when you notice the problem; it starts when mailbox providers begin seeing consistently good mail again. That single fact reshapes the whole response: days of paused sending with nothing flowing add zero positive signal, so pausing alone prolongs the outage. You pause to stop the bleeding, then you have to re-earn trust.

> **Note:** The clock starts when good mail resumes
>
> Reputation is a rolling window. Paused sending stops damage but adds no positive signal, so recovery only begins once you are sending clean, engaged volume again.

## The thresholds that define recovered

Recovery is not a feeling; it is a set of numbers you hold for a fixed window. Google's published rule for bulk senders - those sending 5,000 or more messages a day to personal Gmail - is to keep the user-reported spam rate below 0.1% and never reach 0.3%. Rates at or above 0.3% carry an even greater negative impact on delivery.

The recovery gate is explicit. Bulk senders become eligible for mitigation only when their spam rate stays below 0.3% for 7 consecutive days. Spam rate and compliance status are calculated and updated daily in Postmaster Tools, so you get a fresh reading every day rather than waiting a month. Yahoo sets the same 0.3% complaint line.

Treat 0.3% as a cliff, not a slope. At that rate, three complaints per thousand delivered messages tips you over, and one rough campaign can do that in a single day. That is why one practitioner source argues the real safe operating target is tighter: 0.08%, fewer than one complaint per 1,250 emails sent. Aim there, not at the ceiling.

**0.3% - Spam-rate ceiling you must stay under for 7 straight days**

Gmail restores mitigation eligibility only after the full 7-day window; a single clean day is not recovery.

Two more numbers complete the picture. The commonly cited hard-bounce ceiling is 5% - never let your bounce rate exceed it. And note a recent change in signals: Google retired its old domain reputation score in late 2025, so the Bad/Low/Medium/High domain label is being deprecated as a daily signal. Spam rate and compliance status are now the main Gmail signals. Do not anchor your recovery to a label that is going away.

| Threshold | Target | Hard line | Source basis |
| --- | --- | --- | --- |
| Spam rate (operating) | Below 0.1% | - | Google bulk-sender rule |
| Spam rate (tighter target) | 0.08% | - | Practitioner guidance |
| Spam rate (recovery gate) | Below 0.3% for 7 days | 0.3% | Google mitigation eligibility |
| Hard-bounce rate | As low as possible | 5% | Commonly cited ceiling |

## How long recovery takes, by severity

Timelines converge on three severity tiers, and your tier tells you both the schedule and whether repair is even the right call. A minor soft dip with no blocklisting takes 2 to 4 weeks of clean sending. Moderate damage - one listing plus a complaint spike - takes 4 to 8 weeks after delisting and a root-cause fix. Severe damage - multiple listings, sustained high complaints, a Gmail Bad reputation - needs 8 to 16 weeks and sometimes 6 months or more, even with perfect sending.

| Severity | Signals | Typical timeline |
| --- | --- | --- |
| Minor dip | No blocklist listing, low complaint volume, clean auth | 2 to 4 weeks |
| Moderate block | Spam-folder placement, elevated complaints, one listing | 4 to 8 weeks |
| Severe/burned | Multiple listings, sustained complaints, Bad reputation | 8 to 16 weeks to 6+ months |

Read the tier before you commit effort. A domain with stolen credentials, repeated deferrals, or multiple blocklist listings usually needs 8 to 12 weeks or longer, and that is where the repair-versus-retire question gets serious.

#### Recovery effort by severity

| Stage | Figure | Note |
| --- | --- | --- |
| Minor dip | 2 to 4 weeks | no listing, clean auth |
| Moderate block | 4 to 8 weeks | one listing, complaint spike |
| Severe/burned | 8 to 16 weeks+ | multiple listings, Bad reputation |

*The more listings and sustained complaints, the longer the clean-sending window before placement returns.*

## The recovery sequence, in order

The documented sequence is: confirm it is reputation, pause sending, read the exact listing, fix the root cause, confirm authentication, request delisting, re-warm to engaged recipients, then verify and declare recovery. Order matters more than speed. The most common fatal mistake is requesting delisting before the cause is fixed - operators deny requests submitted before the problem is genuinely resolved, and re-listing is just as quick if the behavior returns.

One honest disagreement in the sources: some guides clean the list before confirming authentication, others confirm auth first. The resolution is to do both inside the same root-cause stage rather than argue about which goes first.

#### Blocklist-hit recovery sequence

1. **Confirm it is reputation, not a fault** - Rule out a broken DNS record, routing issue, or provider outage. Pull the raw SMTP rejection text or a positive blocklist lookup before declaring a listing.
2. **Pause all sending immediately** - Stop every campaign on the listed domain. Continuing to send while blacklisted makes the problem worse and delays removal. Done when zero cold volume is leaving.
3. **Identify the exact list and asset** - Run the Spamhaus checker and MXToolbox and record the list name and reason string. Done when you can name SBL, XBL, PBL, DBL, or CSS and why.
4. **Find and fix the root cause** - Clean bad data, rotate credentials, close relays, or isolate a risky sender. Done when the triggering behavior has demonstrably stopped and is documented.
5. **Confirm authentication** - Verify SPF, DKIM, and DMARC are configured and aligned. Done when alignment passes on a test message.
6. **Request delisting through the correct path** - Self-service for PBL, XBL, and CSS; route SBL through the network owner. Submit a clear explanation of the permanent fix. Done when removal confirms on re-lookup.
7. **Re-warm to engaged recipients** - Restart at 10 to 20% of prior volume to 30 to 60 day engagers, growing 20 to 25% per week while metrics hold. Done when volume is near baseline with metrics intact.
8. **Verify and declare recovery** - Hold spam rate below 0.3%, targeting below 0.1%, for 7 consecutive days and run placement tests. Done when placement is clean and the 7-day gate is met.

> **Rule:** Never request delisting before the cause is fixed
>
> Operators deny requests submitted before the problem is genuinely resolved, and re-listing is just as quick if the behavior returns. Fix and document the cause first, then request removal with a clear explanation of the permanent fix.

## Reading the exact listing and getting delisted

Name the list before you touch anything. The authoritative lookup is the official Spamhaus IP and Domain Reputation Checker, which shows whether an IP or domain appears on SBL, CSS, XBL, PBL, or DBL, then displays the listing context and removal route. Spamhaus replaced its former Removal Center with this checker in 2021. Run MXToolbox alongside it for a multi-blocklist scan, and check Google Postmaster Tools for Gmail-specific spam-rate and compliance signals.

The delisting route depends entirely on which list you hit. Self-service lists clear fast; SBL requires the network owner to act. Spamhaus delisting is free, and no third party can expedite it - ignore any vendor who claims otherwise.

| List | Who requests | Process | Typical time |
| --- | --- | --- | --- |
| PBL | Sender (self) | Self-service form | Minutes to 1 hour |
| XBL/CBL | Sender (self) | Automated, instant if clean | Immediate to 24 hrs |
| SBL | ISP/network owner | Manual review | 24 to 72 hrs+ |
| DBL (domain) | Domain owner | Manual review | 2 to 5 business days |

A DBL listing is the one that matters most for a sourcing operation, because it targets the domain itself rather than an IP, and the domain carries your identity. CSS self-service removal typically propagates in about 30 minutes to a few hours once the cause is cleared.

**Spamhaus delisting request (permanent-fix statement)**

```
Subject: Delisting request - [listed domain or IP] - cause resolved

We identified a listing for [listed asset] on [list name, e.g. CSS/DBL].

Root cause: [e.g. a stale imported segment that hit recycled spam traps].
Permanent fix applied on [date]: removed all hard bounces, unsubscribes, and contacts not engaged in 90+ days; verified SPF, DKIM, and DMARC alignment; and added pre-send list verification so the behavior cannot recur.

Sending has been paused since discovery. We will resume at 20% of prior volume to engaged recipients only. Please confirm removal.
```

*Replace the bracket-free details with your own specifics before sending. Keep it factual and short.*

## Finding the root cause before you ask for removal

No source publishes a rigorous percentage split across causes, so I will not claim one. What is established is the qualitative consensus: list hygiene dominates. You land on a blocklist by hitting spam traps, generating high complaint rates, sending to many invalid addresses, or pushing sudden volume spikes, and most of these triggers trace back to poor list hygiene rather than malicious intent.

Confirmation differs by cause, and this distinction decides your fix. A normal sender problem shows complaints, unsubscribes, and bounces climbing after campaigns. A security problem shows unexpected volume, strange recipients, or mail sent outside normal hours. If you see the second pattern, a hygiene scrub will not save you - you have an infrastructure compromise, and you need to rotate credentials and close relays.

#### Hygiene problem or compromised infrastructure

Horizontal axis runs from Volume you sent to Volume you did not send. Vertical axis runs from Normal recipients and timing to Strange recipients or off-hours mail.

| Quadrant | What it means |
| --- | --- |
| Clean operation | No action beyond monitoring |
| Infrastructure compromise | Rotate credentials, close relays, isolate the sender |
| Hygiene failure | Scrub bounces, unsubscribes, and stale data |
| Compromise plus bad data | Secure systems first, then clean the list |

*The signal pattern tells you whether to scrub the list or secure the systems.*

The practical reason hygiene dominates is that purchased or scraped and stale lists carry pristine and recycled spam traps that fire on first contact. That means the single most effective prevention is pre-send verification - cleaning a list before it ever sends, not after it has triggered the listing this runbook exists to clean up.

> **Watch out:** A hygiene fix will not stop infrastructure abuse
>
> If the signal shows volume, recipients, or send times you did not generate, cleaning the list changes nothing. Secure the systems first, or you will re-list within days of removal.

## The repair-versus-retire decision

At some point you have to decide whether this domain is worth saving. Recovery is real, but a truly burned domain is sometimes cheaper to replace than to repair. The decision gate is about the domain, not the ESP - and this is where most operators go wrong.

Switching providers is a false escape. Domain reputation follows you across ESPs and IP changes, so you generally cannot outrun damage by simply switching providers. Providers key reputation to the sending identity, not just the IP, so a new ESP gives brief relief and then the same collapse. If you are tempted to "just move to a new sending platform," understand you are moving the damage with you.

Use severity as the gate. A minor or moderate case repairs on a 2-to-8-week clean-sending window and is almost always worth repairing. A severe case - multiple listings, sustained complaints, a Bad reputation that has been observed taking 6 or more months to recover even with perfect sending - is where you weigh the cost of waiting months against standing up a fresh, correctly warmed replacement domain.

If you retire, remember a replacement domain is not a shortcut around warm-up. New domains and mailboxes need 3 to 4 weeks of gradual ramp: start at 5 to 10 emails per day per mailbox, increase by 20 to 30% at a time, cap around 40 to 50 per day per mailbox, and hold on any bad signal.

> Switching ESPs moves the damage with you; the domain, not the provider, carries the history.

## Re-warming without re-triggering the hit

Once the root cause is fixed and the listing is cleared, restart small and only to people who already want your mail. Begin at 10 to 20% of normal volume and send only to recipients who opened or clicked in the last 30 to 60 days. Then scale gradually, adding roughly 20 to 25% more volume each week as long as metrics hold. If they dip, stay flat another week before increasing again.

A tighter variant works well for a domain that was badly hit: remove all hard bounces, unsubscribes, and contacts not engaged in 90 or more days, then resume at 20% of normal volume targeting your most engaged contacts first. The logic is the same either way - you are rebuilding the rolling trust window with the recipients least likely to complain.

Deliverability expertise to run this well is scarce and concentrated, and the ops owner answerable for recovery often has to source it externally. In Refolk's index of professional profiles, just 455 US professionals and 72 in the UK carry an email-deliverability skill - a 6.3x gap - and the skill clusters inside ESPs rather than in-house teams.

**455 - US professionals with an email-deliverability skill in Refolk's index**

Only 72 carry the same skill in the UK, a 6.3x gap, and the expertise concentrates inside ESPs.

| Segment | Count | Share of US pool |
| --- | --- | --- |
| US, deliverability skill | 455 | 100% |
| UK, deliverability skill | 72 | 15.8% (6.3x fewer) |
| US, Director level | 61 | 13.4% |
| US, Senior level | 67 | 14.7% |

Within the US pool, 61 sit at Director level and 67 at Senior level, with named employers including Loops, Klaviyo, ActiveCampaign, Sinch Mailgun, Bloomreach, and SendPost. If you need to bring in someone who has actually run a Spamhaus delisting and a re-warm, that is the pool to pull from.

I ran this search: `Email deliverability specialists in the United States who have worked at an ESP like Klaviyo, ActiveCampaign, or Sinch Mailgun.` - [see the full result list](https://www.refolk.ai/s/0xbqthsx2e).

*Returns deliverability-skilled operators from inside the ESPs where the recovery expertise actually lives, ranked and contactable.*

Because that expertise lives inside ESPs, sourcing it in plain language rather than guessing at title strings saves real time. [Refolk](/) lets you ask for the people you want and get them back across LinkedIn, GitHub, and the open web, so you can name the skill and the employer and skip the Boolean. When the brief is "someone who has run a delisting and a re-warm," asking directly beats scanning job titles.

## How this goes wrong

The failure modes here cost more than the original listing, because each one either prolongs the outage or re-triggers it. Work through them deliberately.

- **Misdiagnosis as reputation.** A single broken DKIM record or MX outage mimics a blocklisting. The false positive: you start a weeks-long re-warm when a DNS fix would have restored flow in an hour. Check: pull the raw SMTP rejection and run the Spamhaus checker before acting.
- **Delisting before fixing the cause.** A cleared listing gets read as recovery, then re-lists within days. Check: confirm the triggering behavior stopped and is documented before you submit the request.
- **Trusting a Postmaster label as a stopwatch.** A provider can keep showing Low for days after the behavior improves, because the score includes recent history. Check: judge on the 7-day spam-rate trend, not a single daily label - especially now that the old domain reputation score is being deprecated.
- **Declaring recovery on one clean day.** The gate is 7 consecutive days below 0.3%. The false positive: scaling after day two and re-spiking complaints. Check: hold the ramp flat until the full window passes.
- **Re-warming to a stale list.** Sending to the same unengaged data that caused the hit re-triggers traps. Check: restrict to 30-to-60-day engagers only during re-warm.
- **Switching ESPs to escape.** Domain reputation follows the domain. The false positive: brief relief, same collapse. Check: repair or retire the domain itself.
- **Over-aggressive ramp.** Doubling daily volume looks like a bot, and doubling daily is how mailboxes get flagged in week one. Check: cap weekly increases at 20 to 30%.
- **Missing a compromised sender.** Hygiene fixes will not stop infrastructure abuse. Check: look for volume, recipients, or timing you did not generate before concluding it is a hygiene problem.

## Before you call it recovered

Run this checklist before you declare the domain restored and reopen full volume. If any item fails, you are not done, no matter how good the inbox looks today.

#### Recovery sign-off

- [ ] You have the raw SMTP rejection or a positive blocklist lookup confirming the listing was real.
- [ ] The exact list is named (SBL, XBL, PBL, DBL, or CSS) with its reason string recorded.
- [ ] The root cause is identified as hygiene or infrastructure, fixed, and documented.
- [ ] SPF, DKIM, and DMARC alignment passes on a test message.
- [ ] Delisting is confirmed on a re-lookup through the correct path for that list.
- [ ] Re-warm ran only to 30-to-60-day engagers at 10 to 20% starting volume.
- [ ] Weekly volume increases stayed at or below 20 to 25%.
- [ ] User-reported spam rate held below 0.3%, targeting below 0.1%, for 7 consecutive days.
- [ ] Placement tests confirm inbox landing, not spam-folder delivery.

## Keeping the domain out of trouble

Recovery is only worth doing if the domain stays clean afterward. Three habits keep it there. First, verify lists before you send, not after, because recycled and pristine spam traps on stale or scraped data are the dominant trigger this whole runbook exists to clean up. Second, watch Postmaster daily and treat any drift toward 0.1% as an early warning, since the 0.3% cliff can be reached by one bad segment in a day. Third, re-check the mechanics rather than the current values: thresholds and signals change - the old domain reputation score was retired, and bulk-sender rules evolve - so confirm the current Gmail and Yahoo requirements directly before each major sending push rather than trusting a number you memorized last quarter.

If the program is large enough that recovery is a recurring risk, the durable fix is to put someone with real deliverability expertise on it, whether in-house or on advisory. That skill is scarce and sits inside the ESPs, so source it deliberately rather than hoping an existing generalist can run a delisting under pressure.

## Frequently asked questions

### How do I know if my domain is actually blocklisted or just having a DNS problem?

Pull the raw SMTP rejection text first, then run the official Spamhaus IP and Domain Reputation Checker and a multi-list scan like MXToolbox. A blocklisting produces a positive lookup against a named list such as SBL, XBL, PBL, DBL, or CSS, with a reason string. A broken DKIM record or MX outage mimics a collapse but shows no listing, and a DNS fix restores flow in an hour rather than weeks.

### How long does it take to recover a blacklisted email domain?

It depends on severity. A minor dip with no listing clears in 2 to 4 weeks of clean sending. One listing with a complaint spike takes 4 to 8 weeks after delisting and a root-cause fix. A severe case with multiple listings, sustained complaints, or a Gmail Bad reputation needs 8 to 16 weeks and sometimes 6 months or more, even with perfect sending.

### Can I just switch to a new ESP to escape the blocklisting?

No. Domain reputation follows the domain across ESPs and IP changes, so you generally cannot outrun damage by switching providers. Providers key reputation to the sending identity, not just the IP, so you get brief relief and then the same collapse. The real decision is whether to repair or retire the domain itself, not which provider to send through.

### When can I declare recovery after a Gmail spam-rate spike?

Gmail restores mitigation eligibility only after your user-reported spam rate stays below 0.3% for 7 consecutive days, measured daily in Postmaster Tools. Do not declare recovery on a single clean day or scale after day two. Hold the ramp flat until the full 7-day window passes, target below 0.1% rather than the 0.3% ceiling, and run placement tests to confirm inbox landing.

### Should I request Spamhaus delisting myself or does my provider do it?

It depends on the list. PBL, XBL/CBL, and CSS are self-service and you request removal yourself, often clearing in minutes to a day. SBL removal must be requested by the ISP or network owner that controls the listed space, not the end sender, and takes manual review. DBL covers the domain and needs the domain owner to request a manual review, typically 2 to 5 business days.

### What most often causes a sending domain to get blocklisted?

List hygiene dominates. You land on a blocklist by hitting spam traps, generating high complaint rates, sending to many invalid addresses, or pushing sudden volume spikes, and most of these trace to poor list hygiene rather than malicious intent. A hygiene problem shows complaints and bounces climbing after campaigns; an infrastructure compromise shows volume, recipients, or send times you did not generate.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/sending-domain-recovery-runbook*