TL;DR
The pattern is always the same. Reply rates halve in a week. Then a prospect forwards a screenshot of your email in their spam folder. Someone runs a blacklist checker, finds a red row, and the whole team starts filling in delisting forms. Two weeks later nothing has improved, because the red row was never the problem.
This post is the remediation playbook: how to tell which of the two failures you have, which lists you can genuinely act on, what to fix before you file anything, and the decision almost nobody documents — whether to repair the domain or retire it and rebuild elsewhere.
Our cold email deliverability monitoring guide covers the detection side: which dashboards to watch and which metrics still mean something. This post picks up at the moment detection has already failed you and the damage is done. If your infrastructure was never set up properly to begin with, start instead with SPF, DKIM and DMARC setup and cold email infrastructure — recovery on a broken foundation is wasted work.
Every removal process, timeline and threshold below was read from the blocklist operator's or mailbox provider's own documentation, and quoted as they state it. Recovery timelines are the weakest-sourced part of this entire subject: almost every number in circulation comes from vendors selling warmup tools. Those are flagged directional throughout. Where sources contradict each other we name the conflict instead of picking the tidier answer.
Check whether you are listed or merely disliked, because the response is completely different. Run your domain and sending IPs through check.spamhaus.org and open Google Postmaster Tools. If a specific list names you, there is a form, a published timeline and usually a free self-service path — file it after fixing the cause. If no list names you but Gmail reputation reads Low or Bad, there is nothing to file: cut volume, fix the underlying spam-complaint driver, and wait out a rolling multi-day average.
Then make the decision the industry avoids putting in writing. A domain at Low with real sending history and months of age is usually worth repairing. A domain rated Bad, or one under two months old that is already listed, is usually worth retiring — the sunk reputation isn't valuable enough to justify weeks of reduced sending while you nurse it back.
Both present as "our emails stopped landing." They share almost nothing else.
| A listing | Reputation decay | |
|---|---|---|
| Who decided | A third-party blocklist operator (Spamhaus, Barracuda, SpamCop) | The mailbox provider itself (Gmail, Outlook, Yahoo) |
| Is it visible | Yes — a named list, a lookup tool, often a bounce message citing it | Only as a category in a dashboard, or as silence |
| Is there a form | Usually yes, usually free, often self-service | At Google, none exists at all |
| Time to resolve | Hours to a few days, once the cause is fixed | Weeks, on a rolling average you cannot accelerate |
| What the asset is | Often an IP — frequently one you share and don't control | Usually your domain — which follows you everywhere |
That last row decides how much agency you have. A listing on a shared IP is often somebody else's problem and resolves without you; a damaged domain reputation is entirely yours and cannot be transferred, appealed, or bought off.
Verified from each operator's own documentation. Note how many rows are IP-based — that column matters more than the timeline column if you send from Google Workspace or Microsoft 365.
| List / provider | Lists | Can you self-serve | Documented timeline | Cost |
|---|---|---|---|---|
| Spamhaus DBL | Domains only | Yes | Minutes once approved; auto-expires when activity ceases; up to 24h downstream lag | Free |
| Spamhaus CSS | IPs | Yes | Auto-expires "three (3) days after the last detection" | Free |
| Spamhaus SBL | IPs | No — network owner only | Only after abuse is terminated and the ISP requests removal | Free |
| Spamhaus PBL | IP ranges that shouldn't send direct-to-MX | Yes, for a single static IP | ~15 min; end-user exclusions expire after 1 year | Free |
| Microsoft 365 / Outlook | IPs | Yes for one code family, no for another (below) | "Up to 24 hours or longer"; 48h response on the manual path | Free |
| Barracuda BRBL | IPs | Yes | Processed "within 12 hours of submission" with a valid explanation | Free |
| SpamCop SCBL | IPs | No manual process at all | Auto-delists 24h after the last report, plus up to ~4h propagation | Free |
| Google / Gmail | Domain and IP reputation | No path exists | Recheck the compliance dashboard after 7 days | N/A |
| Yahoo Sender Hub | Domain (feedback loop is DKIM-domain based) | A "sender support request" exists by name | No published process, criteria or SLA | Free |
| UCEPROTECT | IP, /24 netblock, whole ASN | A free path exists, conditional on network-level steps | Not published for the free path | Paid express removal, confirmed on their own site |
| SORBS | — | Defunct since June 2024 | N/A — nobody is home to process a request | N/A |
Three other lists get cited constantly in blacklist-checker output — SURBL, Invaluement and Spam Eating Monkey. We deliberately publish no removal timelines for them: their own sites did not yield a verifiable self-service process or timeline when we checked, and Invaluement's widely-cited removals URL now returns a 404. If a checker flags you on one of these, go to the operator's current site rather than trusting a third-party summary, including this one.
The structural trap: the only row in that table you fully control is Spamhaus DBL, because it lists domains. Nearly everything else lists IPs. If you send cold email through Google Workspace or Microsoft 365, you do not own the sending IP, cannot see who else is on it, and cannot meaningfully remediate it. Spamhaus restricts SBL removal to the network owner for exactly this reason. Before you spend an afternoon on delisting forms, confirm the listed asset is actually yours — see Google Workspace vs Microsoft 365 for cold email for how each provider handles sending infrastructure.
Microsoft documents two different remediation routes, and picking the wrong one wastes days. A 550 5.7.606-649 bounce — a banned sending IP — is handled through the self-service delist portal at sender.office.com, where Microsoft's own caveat is that results "can vary widely" and removal "might take up to 24 hours or longer." A 550 5.7.511 bounce is a banned sender and is explicitly not eligible for that portal; it requires emailing delist@microsoft.com with the full bounce code and IP, after which Microsoft states it will respond within 48 hours.
Other Microsoft error codes circulate widely in community write-ups with confident remediation instructions attached. We could not confirm those specific codes against Microsoft's own documentation, so we're not repeating the advice — read the actual bounce string you received and match it to Microsoft's published pages rather than to a forum post.
Spamhaus states on its own FAQ pages that "There is never any charge or fee associated with removing any Spamhaus listing," adding that any service charging for Spamhaus removal is fraudulent. That is a useful sentence to keep handy, because "we'll get you delisted" is a common upsell.
UCEPROTECT is the exception worth understanding. Its own site confirms that where a network has not implemented its required remediation steps, removal is offered "on a payment basis." Charging to remove a listing whose entire purpose is to signal abuse is a conflict of interest the deliverability community treats with open skepticism, and major senders' support documentation says as much (directional — that characterisation is community and vendor opinion, though the paid mechanism itself is confirmed by UCEPROTECT). Practical guidance: check whether major mailbox providers actually query the list that flagged you before paying anyone anything.
This is the most consequential finding in this post, and it is a finding about absence. Google's bulk sender guidance and its own deliverability troubleshooter offer no delisting portal, no appeal form, and no reconsideration request for domain or IP reputation. What they offer is a self-diagnostic flowchart, the Gmail Help Community forum, and Postmaster Tools. That's it.
So for the mailbox provider that most likely holds your prospects, remediation is not a transaction. Google's Postmaster Tools defines four reputation tiers, and the wording matters: Bad means a "history of sending a high volume of spam regularly" and mail is "almost always marked as spam or rejected by the receiving server." That is Google describing rejection, not spam-foldering. Low means a significant volume of spam sent regularly. Medium means you "occasionally send spam" — which is why treating Medium as a clean bill of health and returning to full volume is a mistake.
Two numbers are genuinely Google's own: keep spam complaint rates below 0.10%, and never let them reach 0.30%. Google also tells senders to recheck the compliance dashboard after 7 days following a fix, because the status runs on a rolling multi-day average that "might not update immediately."
Where the widely-quoted numbers come from. You will read that IP reputation recovers in 2 to 4 weeks and domain reputation in 6 to 12 weeks, or that a burned domain comes back in 30 to 90 days at low volume. Those figures come from email vendors' blogs, not from Google, and they measure different starting conditions — recovering from a single filtering event is not the same problem as recovering from a sustained Bad rating. Treat them as directional, and note the one thing every source agrees on: IP reputation recovers faster than domain reputation, because the domain is the part that follows you.
The rolling average also cuts both ways, which produces the single most common self-inflicted wound in recovery. Because the dashboard lags reality, an operator who ramps volume back up as soon as numbers look better gets punished for behaviour that already stopped — and reads the resulting drop as proof that recovery failed.
Across every removal policy we read, not one offers delisting on request alone. SpamCop is the bluntest: "Please do not write us to tell us that you have fixed the problem and ask for early delisting." Its listings expire on their own 24 hours after the last report, so the only thing that matters is stopping the reports.
Which means diagnosis comes before paperwork. It helps to know which causes are measurable and which are folklore:
| Suspected cause | Is there a published threshold? |
|---|---|
| Spam complaint rate | Yes — Google: under 0.10%, never reaching 0.30% |
| Authentication failures (SPF, DKIM, DMARC) | Partly — pass/fail is binary and checkable, but no provider quantifies the reputation cost |
| Bounce and invalid-address rate | No documented Google ceiling — every "keep bounces under X%" figure is industry convention |
| Spam-trap hits | No — universally blamed, never quantified by a provider |
| Volume spikes | No published limit; provider sending caps are system limits, not safe-sending advice |
| Shared or previously-burned tracking domain | No — flagged by vendors who sell the fix (directional) |
| Content and copy triggers | No — the least measurable and most over-diagnosed cause of all |
The practical order: authentication first because it's binary and free to verify, then list quality because it's the dominant driver of both complaints and bounces, then volume. Content copy is where teams instinctively start and where the least verifiable gain is. If bounces are your problem, email verification tooling and how you build the list matter far more than rewriting subject lines. If complaints are your problem, targeting relevance and compliance basics are the levers.
Here is the real gap in the published literature. Google, Microsoft and the major email platforms all document reputation definitions and thresholds. None of them publish a framework for deciding whether a given domain is worth saving. Every decision table you'll find, including this one, is practitioner synthesis rather than vendor policy — so treat it as a starting bias, not a rule.
| Where you are | Call | What to do |
|---|---|---|
| Gmail reputation Medium, complaints between 0.10% and 0.30% | Repair | Cut the weakest segments, fix list hygiene, reduce volume. Don't treat Medium as recovered. |
| Gmail reputation Low, domain 6+ months old, some replies still landing | Repair, on probation | Stop sending, fix authentication and lists, re-warm from very low volume. Give it a fixed assessment window and a defined give-up point. |
| Listed on a domain-based list, cause identified and fixed | Repair | File the removal, expect hours-to-days. Listings are the cheap failure to recover from. |
| Gmail reputation Bad, or zero inbox placement after weeks of clean sending | Retire | There is no appeal to file and no timeline to plan against. Harden the DNS, stand up replacements. |
| Domain under ~60 days old and already burned | Retire immediately | There is no sunk reputation worth rescuing. The only asset lost is the registration fee. |
The economic logic behind the bias toward retiring: a domain is cheap and weeks of suppressed sending are not. If your model is roughly known — and our cost per meeting breakdown gives a way to price it — you can compare the cost of a replacement domain and a fresh warmup against the pipeline value of six weeks at reduced volume. That comparison usually settles the argument faster than any deliverability debate.
There is no authoritative warmup ramp. We compared vendor and community guidance and the spread is genuinely wide: starting volumes anywhere from 5 to 30 emails per mailbox per day, daily increments from +2 to +10, and steady-state cold-sending ceilings from 20 to 50 per mailbox. The closest thing to a consensus is a minimum warmup period of about two to three weeks before real campaign volume. Every one of those numbers is directional, and most come from companies that sell warmup products.
Two things are firmer. First, provider sending caps — such as Google Workspace's published daily message limits — are system limits, not recommendations; sending anywhere near them on cold outbound is a different activity from what those limits were designed for. Second, recovery re-warming should be slower than new-domain warming, because you are working against an existing negative history rather than no history at all (directional — no provider documents this distinction).
For tooling, see our warmup and deliverability tools comparison. We've deliberately left warmup pricing out of this post: the numbers we found couldn't be confirmed on the vendors' own current pricing pages, and stale prices are worse than none.
Most teams "retire" a domain by simply stopping. That leaves a domain with live sending records, a real reputation history and no owner watching it — an attractive target for spoofing, which can make the reputation worse after you've left.
The hardening pattern for a domain that will never send again is well established. Publish a hard-fail SPF record at the apex and as a wildcard: v=spf1 -all. Publish a rejecting DMARC policy at _dmarc: v=DMARC1; p=reject; — and remove any existing subdomain-policy tag, so reject actually applies to subdomains. Revoke DKIM with a wildcard record carrying an empty key: v=DKIM1; p=;. And if the domain should no longer receive mail either, publish an RFC 7505 null MX — MX 0 . — as its only MX record.
Do not do all of that on day one. That hardening recipe is written for domains that never sent mail. A retired cold email domain is different: prospects are still sitting on emails you already sent, and some will reply for weeks. Publish a null MX and you bounce those replies — deleting pipeline you already paid for. The sequence that protects both: stop sending immediately, keep MX and inbound working through a reply window while forwarding or monitoring those mailboxes, and only then harden the domain fully. This ordering is our operational recommendation, not vendor guidance — nobody publishes advice on this transition at all.
On replacements, one widely-repeated claim deserves a clear label. You will be told that a new domain added inside the same Google Workspace or Microsoft 365 tenant inherits the burned domain's reputation. We could not find any statement from Google or Microsoft confirming that reputation is linked across domains in one tenant or one billing identity, and the claim traces largely to vendors who sell separate-tenant sending infrastructure. So: unverified folklore. That said, the downside is asymmetric — if it's true and you ignore it you lose a second domain, and if it's false you've spent a little more on separation. Erring toward a clean tenant is a cheap hedge on an unproven risk, which is a different argument from the one usually made for it.
What is not folklore: reusing the burned tracking or link domain on a fresh sending domain reintroduces the flagged asset into every email. Replace the tracking domain along with the sending domain. Then decide how many mailboxes and domains you actually need — our guide on how many domains and mailboxes to run covers the arithmetic.
Swapping domains mid-flight raises three practical questions, and we want to be straight about the answers: nobody publishes them.
Neither Smartlead's nor Instantly's public documentation describes what happens to an in-flight sequence when you swap sending accounts — whether prospects reset, whether reply threading survives, or how mid-sequence sends behave. The one adjacent fact we could confirm is that follow-ups without a new subject line thread to the previous email, which implies threading is subject-line dependent, but that isn't the same question. Our Smartlead vs Instantly comparison covers how the two platforms differ in general; this specific behaviour is undocumented on both sides.
Third, and this is the one that costs RevOps teams real reporting accuracy: HubSpot's documentation explains how email activity is attributed, but does not address what happens to logged activity or attribution when the sending domain changes. If your outbound reporting is built on data flowing in from your sending tools — see syncing cold email and LinkedIn data into HubSpot — a domain migration is exactly the kind of event that quietly splits a contact's history across two identities without erroring.
The only defensible approach: run the swap on a small sandbox campaign, watch what actually happens to threads and to your CRM records, then do it at scale.
Recovery is expensive enough that the real win is making the next burn survivable rather than existential.
Never cold-send from your root brand domain. The domain your customers, invoices and support mail depend on should be structurally incapable of being burned by an outbound campaign, which means separate lookalike sending domains carrying all outbound risk. On whether a subdomain gives you that protection: deliverability vendors describe subdomain reputation as mostly independent but explicitly not guaranteed to be isolated, and no mailbox provider publishes a rule either way. Plan as though a burned subdomain can touch the parent, because nobody will tell you it can't.
Give every sending domain its own tracking domain, so one flagged link domain cannot contaminate the rest of your infrastructure. And consider dropping open tracking altogether — an unusually broad set of competing vendors independently converge on tracking replies and clicks while skipping the open pixel, partly on deliverability grounds and partly because open data became unreliable anyway once Apple Mail Privacy Protection started inflating it. Losing a metric you couldn't trust is a small price.
Finally, keep monitoring in place so the next incident is caught in days rather than discovered in a prospect's screenshot. That's the subject of our deliverability monitoring guide, and it is the cheapest insurance in this entire discipline.
No, and this is worth knowing before you spend time looking. Google's bulk sender guidance and its own deliverability troubleshooter describe no delisting portal, no appeal form and no reconsideration request for domain or IP reputation. The only routes Google offers are a self-diagnostic troubleshooter, the Gmail Help Community forum, and monitoring in Postmaster Tools. The levers that exist are fixing the underlying spam-complaint and authentication problems and then waiting: Google says the compliance status runs on a rolling multi-day average and should be rechecked after 7 days following a fix. With Gmail, reputation is not delisted, it is rebuilt.
Never. Spamhaus states on its own FAQ pages that there is never any charge or fee associated with removing any Spamhaus listing, and that any service charging for Spamhaus removal is fraudulent. The notable contrast is UCEPROTECT, whose own site confirms that where the required network-level remediation steps have not been implemented, removal is offered on a payment basis. Before paying anyone to remove any listing, check whether the mailbox providers your prospects actually use even query the list in question.
Faster than most people expect, once the cause is fixed. Published timelines include: Spamhaus DBL removals processed within minutes of approval, with listings that expire automatically once activity ceases; Spamhaus CSS listings expiring roughly three days after the last detection; Barracuda processing removal requests within 12 hours of submission; and SpamCop auto-delisting 24 hours after the last spam report with up to about four hours of mirror propagation. Microsoft's self-service delist portal says results may take up to 24 hours or longer, and its manual path promises a response within 48 hours. The slow part of recovery is almost never the delisting itself.
Severity and age decide it. A domain with real history that Postmaster Tools rates Low, or one carrying a fixable domain-list listing, is usually worth repairing. A domain rated Bad, or one that still gets zero inbox placement after weeks of clean low-volume sending, is usually worth retiring — with Gmail there is no appeal to file and no published timeline to plan against. A domain under about two months old that is already burned should be retired without debate, because there is no accumulated reputation to rescue. No mailbox provider publishes a framework for this decision, so weigh the cost of a replacement domain and a fresh warmup against the pipeline value of several weeks at suppressed volume.
Possibly, and nobody will give you a definitive answer. Deliverability vendors describe subdomain reputation as mostly independent from the parent domain, but every source hedges that separation is not guaranteed — shared authentication, shared infrastructure and obvious brand association can all let signals cross over. No mailbox provider publishes a rule confirming or ruling this out. The safe planning assumption is that a cold-outbound subdomain sits close enough to your brand to matter, which is why dedicated lookalike sending domains are the more common architecture for outbound at volume.
Unknown, genuinely. Neither Smartlead nor Instantly publish what happens to in-flight sequences when sending accounts are swapped, including whether reply threading survives or how partially-sequenced prospects behave. HubSpot documents how email activity gets attributed but does not address what happens to logged activity or attribution when a sending domain changes. Because a domain migration can split one contact's engagement history across two identities without throwing any error, test the swap on a small sandbox campaign and inspect both the threads and the CRM records before migrating a live book of business.
Burned a sending domain and trying to work out whether it's worth saving? Start with our deliverability monitoring guide so the next incident gets caught early, or talk to our team. We build and run cold email, LinkedIn outreach and HubSpot RevOps systems for B2B teams — including the unglamorous infrastructure work that decides whether any of it lands.
By the GenFlows GTM engineering team. Removal processes, timelines and costs were read from each blocklist operator's or mailbox provider's own documentation and are quoted as they state them. Recovery and warmup timelines are the weakest-sourced area of this subject and are flagged directional throughout — most originate from vendors selling deliverability products. Where sources contradict each other, the conflict is named rather than resolved. Blocklist policies, bounce codes and pricing change; verify against the operator's current site before acting. Last updated September 2026.