If your cold email domain looks blacklisted, stop sending from it today. Then find out exactly where it is listed, fix whatever caused it, and only after that ask for removal. Spamhaus, for one, will want to know how the problem was solved.
"Blacklisted" covers two different problems. One is a real listing: a named list, such as the Spamhaus domain list, Barracuda's IP list or Microsoft's blocked senders list, has your domain or a sending IP on it, and a bounce or a lookup shows it. Those have a removal route.
The other is a bad reputation score, like a Low or Bad tier in Google Postmaster Tools. There is no delisting form for that. Google's advice is to stop the behavior, then "wait for the sending domain or IP address to recover" (Postmaster Tools dashboards).
Google does run a Report delivery issue form in Postmaster Tools, but its scope is narrow. It covers mail "incorrectly classified as spam or phishing" or rejected.
Only the verified owner of a domain that meets Google's sender guidelines can file one (Google's form page).
And if the domain was a spare bought only for cold email, replacing it is often the cheaper fix. I checked every rule and time limit below in September 2026.
Listed, or just scored badly?
Work this out before you touch a single form, because the two paths barely overlap.
You are listed when a bounce names a blocklist or a block, or a lookup shows your domain or IP on a public list.
Microsoft's bounce, for example, reads "550 5.7.606-649 Access denied, banned sending IP". It points you straight to its delist portal (Microsoft Learn).
You are scored badly when nothing bounces, the replies quietly stop, and Postmaster Tools shows your domain slipping. Google grades IP and domain reputation in four tiers, best to worst, and defines them like this:
- High means "History of very low spam rates, and complies with Gmail's sender guidelines"
- Medium means "History of sending legitimate email, but occasionally sends spam"
- Low means "History of sending a significant volume of spam regularly"
- Bad means "History of sending a high volume of spam regularly"
The tiers describe history, and history moves slowly in both directions. Reputation damage shows up late and leaves late, which is about the worst pairing you can get.
One caveat on those tiers. Google has said the Domain and IP Reputation dashboards will be retired when the old Postmaster Tools interface moves to v2, with no date given yet (Google's deprecation note).
Every other dashboard, Spam rate included, carries over, so the spam rate is the number to build habits around.
There is a third case: nothing bounces, Postmaster shows nothing, and the mail simply lands in spam. That is an inbox placement problem, and no blocklist removal will fix it.
How do I check where the domain is listed?
Start with evidence you already have, then run lookups.
- Read the bounces. A rejection that names a list or quotes a code tells you who blocked you and usually where to go. Save the full text of each one.
- Run the Spamhaus checker. Spamhaus sends domain owners to its IP and Domain Reputation Checker. Check the domain and every sending IP.
- Run a multi-list lookup. MxToolbox, for one, tests a mail server IP against over 100 DNS-based blocklists, and its search box takes a domain too.
- Open Postmaster Tools. Google lists eight dashboards, among them Compliance status, Spam rate, Domain Reputation and IP Reputation. At low volume the Compliance status dashboard may say "No data found", which means there is not enough mail from you to evaluate.
One catch. If you send through a mailbox provider or a sending platform, the IP in a listing often belongs to them, not to you.
Spamhaus accepts removal requests for its IP list (the SBL) only from "the Internet Service Provider in charge of the listed IP address(es)" (Spamhaus SBL FAQ). In that case the request is your provider's to file, and your job is to open a ticket with them.
Write down every list, the date you found it and the evidence. Do not file anything yet.
Fix the cause before you ask anyone for anything
Removal requests are judged on what changed. Spamhaus says "we always need to know how the problem was solved." Barracuda ignores requests without valid information (Barracuda removal page).
Microsoft warns the IP "might be blocked again" if the mail keeps looking abusive.
None of the causes below is about the wording itself. A rewrite of the email will not repair a bad list, or a sender the providers have stopped trusting.
So go through the causes one at a time, and fix each one you find.
The list. This is the cause I check first. To a mailbox provider, every hard bounce is evidence that the list was collected carelessly.
In my campaigns, every address is verified before it goes out, and the bounce rate stays under half a percent.
If a new segment went in shortly before the trouble started, check the list before you touch the copy.
Complaints. Gmail's sender guidelines set a ceiling of 0.3% on the spam rate Postmaster Tools reports, and recommend staying under 0.10% (Gmail sender guidelines).
Where do complaints come from? Almost never from a relevant message: people ignore those, reply to them or delete them. The ones who press the complaint button are the people who feel scraped. So a complaint problem is a targeting problem, and it takes you back to the list.
Spam traps. Spamhaus describes a spamtrap as an address "used to expose illegitimate senders who add email addresses to their lists without permission".
Some are old addresses that hard bounce for a while, "often 12 months or more", and then quietly come back as traps. Keep mailing addresses that once bounced and you can end up mailing a trap.
Spamhaus also has a view on the channel itself. In June 2025 it wrote that from its perspective cold email is spam (Spamhaus on cold emailing).
Cold outreach "sent in bulk and hitting our spamtraps" gets assessed "as candidates for listing", in its words.
Hunting down the traps one by one does not help. Spamhaus says it "only treats the symptom". The fix is the list.
Authentication. SPF, DKIM and DMARC should already exist on every sending domain. What matters now is whether they pass on a real message you sent. A later DNS change can break one without anyone noticing, while the record still sits in DNS looking fine.
Volume. Did sends per mailbox jump just before the trouble? An overworked mailbox fails quietly. The reply rate slides while the copy stays the same, and no provider writes to tell you.
By the time you notice, the domain's reputation needs more repair time than a proper warm-up would have needed.
For scale, in one real client month in 2023, from my walkthrough of the sending setup, 15,000 cold emails went out from 20 addresses, roughly 25 per mailbox per day.
Google's guidelines warn against "sudden volume spikes if you do not have a history of sending large volumes."
A compromised site or mailbox. Spamhaus's domain list also covers compromised legitimate sites used for abuse. Its fix list: take the site offline if possible, remove infected files, update the CMS, secure the server and change every password (Spamhaus DBL FAQ).
The wrong domain. If the listed domain is the one your invoices come from, the damage reaches your whole business.
I put it this way in that setup post: "Cold email carries a reputation risk that has no upper bound, and the day your main domain gets flagged, your invoices, your support replies and your contracts start landing in spam folders alongside your outreach."
How do I get removed from each blacklist?
Each operator runs its own process. Some expire listings on their own, some want a form, one only takes requests from the provider in charge of the IP, and Gmail has no list at all.
Removal routes as published by each operator, checked September 2026.
| Where you are blocked | What it covers | How you know | Removal route | Time it takes, in their words |
|---|---|---|---|---|
| Spamhaus DBL | Domains only | Checker shows the domain | Request through check.spamhaus.org once eligible. "Most listings will expire automatically" once the activity stops, and a domain can be listed again if the activity returns. No fee, ever | Approved removals "should only take a few minutes," though Spamhaus says some users lag up to 24 hours |
| Spamhaus SBL | IP addresses | SBL listing page for the IP | "Contact the SBL Team" link on that listing page, explaining how the problem was solved. Only the provider in charge of the IP can ask | No review time published. Once a removal is approved, the DNS zone runs on a 5-minute cycle: "rebuilt and reloaded every 5 minutes, 24/7" |
| Gmail | A reputation score for your domain and IPs; there is no list | Postmaster Tools: Low or Bad tier, spam rate over 0.3% | No removal request. Fix and wait. Bulk senders that meet every requirement can ask for mitigation (Gmail sender FAQ). A verified owner whose domain meets the sender guidelines can file a Report delivery issue in Postmaster Tools for mail wrongly sent to spam or rejected; the reported message must pass DKIM and SPF | Mitigation eligibility returns after 7 consecutive days below 0.3%. No response time is given for delivery reports |
| Microsoft 365 | Sending IPs | Bounce "550 5.7.606-649 Access denied, banned sending IP" | sender.office.com: the address that got the bounce plus the IP from the error, one of each per visit, confirm by email, then Delist IP | "Up to 24 hours or longer" |
| Microsoft 365, code 5.7.511 | Banned sender | Bounce "550 5.7.511 Access denied, banned sender" | The delist portal cannot be used for this code. Forward the bounce to delist@microsoft.com with the full code and IP | Microsoft replies "within 48 hours" with next steps |
| Outlook.com (consumer) | Consumer mailboxes | Bounces from Outlook.com addresses | A separate Microsoft delisting form, linked from the same Microsoft Learn page | Not stated |
| SpamCop | IP addresses | Lookup result | Nothing to file: "IPs are automatically delisted after 24 hours with no new spam reports" (SpamCop FAQ) | Up to 4 hours to propagate |
| Barracuda | IP addresses | Lookup result | Removal form: server IP, contact details and an optional reason. Give one anyway: requests without valid information are ignored, and so are repeats | "Typically... within 12 hours" when the explanation is valid |
Two things matter most here.
First, read the Gmail row twice. Mitigation belongs to bulk senders, which Google defines as anyone who sends Gmail accounts more than 5,000 messages in one day. A cold email domain sending a couple of hundred emails a day is nowhere near that line.
So for Gmail your levers are clean sending, time and the report form. The form is only open to a domain that meets the sender guidelines, and those include keeping the Postmaster spam rate below 0.3%. Use it only for mail you can honestly call wrongly classified.
Second, repeated requests hurt. Spamhaus says "excessive removers and other removal form abusers may be blocked", and Barracuda ignores duplicates. File once, with the fix written down. A complete request carries five things:
- The exact listed item, domain or IP, as the list shows it.
- The full bounce text and code. Microsoft asks for both in the 5.7.511 case.
- The cause, in one sentence.
- What you changed, and the date you changed it.
- What stops it from happening again.
Should you repair the domain or replace it?
My view on burned domains is simple. When the damage is bad, a new domain usually costs less than nursing the old one back. Park the old one, stop sending from it, and start clean on new domains that are set up properly.
"Usually" is the important word. Here is how to decide:
| Repair it when | Replace it when |
|---|---|
| It is your main company domain, so replacing it would cost you your invoices and contracts | It was bought only for cold email and does nothing else |
| One listing, on a list that expires on its own or has a clear form | Listed on several lists at once, or listed again after a removal |
| You can name the cause and it is already fixed | You cannot name the cause |
| Postmaster shows Medium, a spam rate under 0.3%, or no data | Postmaster shows Bad, or stays at Low after weeks of clean sending |
Replacing it wipes nothing clean. Spamhaus says "unknown reputations begin as 'poor' by default", so a fresh domain starts with nothing in its favor and needs a proper warm-up. Move the same bad list onto it and you will lose the new domain the same way.
A worked example, day by day
This is a hypothetical, built to show which row of each table applies when.
A founder runs cold email from 4 spare domains with 8 mailboxes, about 200 emails a day in total. In week five a new 3,000-contact segment from a cheap data vendor goes in without verification.
Day 1. Replies stop on domain A. Bounces from company recipients on Microsoft 365 read "550 5.7.606-649 Access denied, banned sending IP".
Seed addresses on Gmail land in spam, and Postmaster Tools shows no data at this volume. The Spamhaus checker shows domain A on the DBL. Every mailbox on domain A stops sending that afternoon.
Day 2. The bounce log shows a 4% hard bounce rate on the new segment against under half a percent on the old lists. The cause is the segment. It comes out of every campaign, on every domain, and the remaining contacts are re-verified. SPF, DKIM and DMARC pass on a test message, so authentication is ruled out.
Day 3. The decision. Three rows of the repair-or-replace table point to repair: domain A is on one list, the DBL, where most listings expire on their own; the cause is known and fixed; and Postmaster shows no data. One row points the other way: domain A was bought only for cold email and does nothing else.
So the founder keeps both options open. Nobody files anything, because Spamhaus says most DBL listings expire once the activity stops. Domain A stays parked, and a new domain starts warming up in case A never comes back clean.
The Microsoft block is a separate problem. The IP in the bounce belongs to the founder's mailbox provider, so the bounce text goes into one support ticket with that provider.
The Gmail report form does not fit this case. It is for mail wrongly sent to spam, and this mail went there for a reason.
Days 4 to 21. Domains B, C and D keep sending to verified contacts only, and any Microsoft bounce with the same code goes into the same ticket. The new domain warms up in the background and passes a seed test before it touches a single prospect.
Domain A returns only if the Spamhaus checker shows it clean and it passes the same seed test.
What to do while the domain recovers
Keep the rest of the program running on healthy domains, with the bad segment removed.
If you chose to repair the domain, bring it back slowly. Google's advice when errors show up is to "reduce the sending volume until the SMTP error rate decreases. Then, increase slowly again."
Before any paused or new domain goes back to prospects, run a seed test: send to your own addresses on Gmail, Outlook and one company domain, and open all three by hand.
Then watch three things every week for the next month: bounce rate per campaign, Postmaster spam rate and reputation where Google shows data, and a blocklist lookup on every sending domain and IP.
How to keep it from happening again
Smirnov Consulting Group is a Prague-based B2B outbound lead generation agency that runs cold email and LinkedIn campaigns for founder-led B2B companies and books qualified sales calls. My team builds the sending side of those campaigns before the first message goes out.
Beyond fixing the causes above, three habits are worth building in.
Add every sending domain to Postmaster Tools before anything goes wrong. Google only takes a Report delivery issue from a verified owner, so nobody can file one for a domain that was never verified. If an agency bought your sending domains, check who controls those domains at the same time.
Adding the domain also gives you the Spam rate dashboard, which carries over to the new interface, whenever there is enough mail for Google to show data.
Never let one domain carry the whole program. Spread the sending across several domains. In the worked example, domains B, C and D kept going while A sat parked. A founder who sends everything from a single spare has nothing to switch to.
Vary the text. The same string of text sent thousands of times, with nothing to tell one send from the next, is one of the setup failures I see most often.
Short answers on blocklists and recovery
Does moving to a new IP fix a blacklisted domain?
No. The Spamhaus DBL lists domains only, and Gmail scores domain reputation separately from IP reputation. A new IP leaves both where they were.
What if my removal request is refused or ignored?
Go back to the cause. Barracuda ignores requests without valid information, and Spamhaus can block people who send too many. Fix it, write down what you changed, then file once. On a cold-only domain, this is usually the moment to park it.
Can I keep sending while I wait?
Not from the listed domain. Other domains can keep sending to verified contacts, as long as the segment that caused the problem is out of every campaign.
How long does recovery take?
It depends on the list. SpamCop clears an IP 24 hours after the last report, an approved Spamhaus DBL removal usually takes minutes but can lag up to 24 hours, and Microsoft says up to 24 hours or longer. Gmail publishes no time. Its tiers describe sending history, so they move as clean history builds up.
Is being on several blocklists worse than one?
It means more work. Each operator runs its own list and its own removal route, so clearing one does nothing for the others. Listings that appear in the same week may share one cause, so find that first. On a domain used only for cold email, several listings put you in the replace column.