Email Blacklist Removal: A Calm Guide to Getting Delisted
Bounces citing Spamhaus? Email blacklist removal in the right order: find what's listed, fix the cause, and get delisted without making it worse.
Bounces citing Spamhaus? Email blacklist removal in the right order: find what's listed, fix the cause, and get delisted without making it worse.
Tuesday, 7:14 AM. A text from a client: "Did you get hacked? Your invoice bounced and it says something about Spamhaus."
Ten minutes later I'm reading a bounce that looks like a ransom note:
550 5.7.1 Service unavailable; Client host [203.0.113.44]
blocked using zen.spamhaus.org;
https://check.spamhaus.org/query/ip/203.0.113.44
And this is the exact moment most people botch email blacklist removal. They rotate DNS records at random, change every password, fire off six delisting requests in twenty minutes, and email the blocklist operator in capital letters. I've done a version of all four. None of it helped. Two of them made things measurably worse, because every list that matters re-checks you after you ask, and asking twice in a day is a great way to look like a spammer having a bad morning.
So. Deep breath. Here's the calm order of operations.
Email blacklist removal starts with a diagnosis, not a form. By the end of this you'll know which thing got listed (domain, sending IP, or a URL inside your message bodies — three different problems), why it got listed, and how to file a delisting request that actually gets approved on the first try. Then we'll talk about not doing this again.
Prerequisites: DNS access, admin access to your mail hosting, and the ability to read raw bounce messages. That last one isn't optional. The bounce string is the single highest-value piece of evidence you have, and people delete it constantly. (I deleted mine once, in a tidying frenzy, then had to ask the client to forward theirs back. Great look.)
Open the full bounce, not the friendly summary your mail client shows. You're looking for two things: an identifier (an IP address or your domain) and a list name.
blocked using zen.spamhaus.org with an IP in brackets → IP listing550 ... Spamhaus DBL or a rejection naming your domain → domain listingMessage contains a URL listed by SURBL → URI listing (something you linked to is dirty, possibly not even yours)550 5.7.1 b.barracudacentral.org → Barracuda IP listingCopy that whole block into a scratch file with a timestamp. You'll need it for the removal form, and half the forms ask for a sample rejection verbatim.
Before you spiral: if you're on shared sending infrastructure, that IP listing might have nothing to do with you. A neighbour on the same outbound IP got compromised and you're collateral. Which changes the fix entirely — you don't file, your host does. I learned that the slow way, by writing a long and genuinely contrite delisting request for an IP address that was never mine to begin with, while the host quietly filed their own; two requests on one IP in one morning is exactly the pattern reviewers are trained to distrust.
There are hundreds of DNSBLs. Three of them matter. Ignore the rest of your MXToolbox red rows for now — a listing on some hobby list run out of a basement in 2009 isn't why Gmail is bouncing you, and I'll happily die on that hill. Most of those rows exist to make you anxious enough to buy a monitoring subscription.
Spamhaus — check.spamhaus.org. Enter both your domain and your sending IP; they're separate lookups and people forget the second one. What you might find:
Barracuda Central — barracudacentral.org/lookups. IP-focused, and heavily used by Barracuda appliances sitting in front of a lot of mid-market and enterprise mail. If your B2B invoices are the ones bouncing, check here early.
SURBL — surbl.org. Different animal. SURBL lists domains found inside message bodies, not senders. So you can be clean as a sender and still get filtered because you linked to a shortener, a compromised WordPress site, or a partner whose domain got hijacked. If your transactional mail died right after a template change, look here first. (This one's tripped me up — the culprit was a tracking-link domain a marketing tool had silently swapped.)
MXToolbox — mxtoolbox.com/blacklists.aspx sweeps 80+ lists at once. Use it as a map, not a to-do list.
Write down: identifier, list, and the reason string each list gives you. That's your case file.
Do not skip to Step 4. Delisting without fixing is how a 48-hour problem becomes a three-week one.
Four causes cover almost everything:
A compromised mailbox. The most common by far. Someone reused a password, got phished, and now their account is relaying a few thousand messages an hour through your legitimate, well-authenticated infrastructure. Check outbound logs for volume spikes by account. If one mailbox sent more mail last night than it did all quarter, there's your answer. Kill the session, rotate the password, enable 2FA, and check for a sneaky forwarding rule or a rogue app password — attackers leave those behind so they can come back after you "fix" it.
A form or script with no rate limit. Contact form with no captcha, a signup flow that emails confirmations, a cron job that got stuck in a retry loop at 3 AM. Boring, extremely common, entirely self-inflicted.
A bad sending pattern. You imported a list, blasted 5,000 cold emails from the same domain you send invoices from, and got a wall of hard bounces plus a handful of complaints. Blocklists read that signal in hours. If you're doing outbound at all, it belongs on a separate sending subdomain, not on the domain that carries your billing mail.
Inherited baggage. You bought the domain and someone else already ruined it. That's a different playbook — we wrote it up in fixing email reputation on a purchased domain.
Also check your auth records while you're in here. A stale SPF include: for a tool you cancelled in March is a live authorization for whoever owns that infrastructure now. If SPF passes but DMARC still fails, that's its own diagnosis.
Contain first, then verify. Rotate the credentials, revoke app passwords and OAuth grants, delete unknown forwarding and filter rules, put a rate cap on the offending account, patch or captcha the form.
Then wait an hour and re-read your outbound logs. Volume should be back to baseline. If it isn't, you haven't found it yet — and filing now will get you relisted with a note on your file.
I have talked myself into "close enough" at this stage more than once. Usually around hour three. Usually because I wanted to go to bed. It cost me another two days every single time.
Sanity checks worth two minutes each: does your SPF still resolve under 10 DNS lookups, is your DKIM selector still signing, is _dmarc still pointing at a mailbox someone reads?
Now you can ask. One request per list. Calm, factual, specific.
Spamhaus. Use the removal link on your lookup result. Say what happened, what you did, and when. Something like: "Compromised mailbox on 2026-09-11, ~4,100 messages relayed between 02:00-03:40 UTC. Credentials rotated, 2FA enforced account-wide, outbound rate limit of 200/hour applied, all forwarding rules audited. Outbound volume returned to baseline (~90/day) as of 06:00 UTC." PBL removals are self-service and fast. CSS is usually same-day. SBL and DBL go to a human, so give it 24-72 hours and don't refile in the meantime — a duplicate request resets your place in the queue.
Barracuda. Their form wants an email address and a reason. Mostly automated; often clears within the hour if you're not on multiple lists simultaneously.
SURBL. Submit through their removal process, and if the listed URL isn't yours, say so plainly and name the actual owner. If it is yours and the site was compromised, clean the site first — they check.
Everything else on your MXToolbox sweep. Work down only the lists that appeared in real bounces. Track what you filed and when in the same scratch file. Some need a nudge after a week; most don't.
You'll get the "removed" confirmation and mail will still bounce. That's DNS caching, not a failed removal — receiving servers hold DNSBL answers for a few hours. Give it 6-12 hours before you conclude anything.
This is the worst part, and nobody writes it down. You've done the work, the list agrees you've done the work, and you still get to sit there watching bounces land while a client quietly reconsiders whether you're competent. There's no status page for that half-day.
While you wait: keep volume low and human. Real replies to real people. Don't fire the delayed newsletter the moment you're clear.
Watch Google Postmaster Tools and Microsoft SNDS over the following week. Spam rate above 0.3% in Postmaster means you're not done.
Honestly? Most of the listings I've seen were preventable with three unglamorous things: 2FA on every mailbox, an outbound rate cap, and someone actually watching a blocklist feed.
The piece people underestimate is outbound filtering. Inbound spam filtering is table stakes; scanning what leaves your server is what stops a compromised account from becoming a listing before you've had coffee. Rspamd scoring plus ClamAV on outbound mail catches the sudden-burst pattern in minutes — we wrote about why we run Rspamd and ClamAV rather than rolling our own filters. It's also the honest argument for managed hosting over a self-run Postfix box: not that you can't configure this yourself, but that almost nobody keeps the signature sets and scoring current after month three.
The rest of the kit:
p=none left running for two years is worse than no DMARC at all, because it hands you a compliance checkbox in exchange for zero protection. It reports. It blocks nothing. Ramp it properly — here's the safe path from p=none to p=reject.Same instinct applies outside email, incidentally — ClickzProtect for bot traffic hitting your campaigns, JustAnalytics for the traffic that's real. You can't fix what nothing is watching.
"I got delisted and relisted within 48 hours." You didn't find the cause. Check for a second compromised account, a leftover app password, or a forwarding rule you missed on the first sweep.
"MXToolbox shows 6 red rows but Gmail delivers fine." Ignore the small lists. Only act on lists that appear in actual bounce messages.
"Spamhaus says clean, mail still bounces." Cached DNSBL answers. Wait 12 hours, then check whether the receiving domain uses its own internal reputation system — plenty of enterprises do, and those have separate appeal paths.
"I can't find a removal form for this list." Some lists genuinely have no removal process, or want payment. Don't pay. If it's not causing real bounces, leave it.
"My host says the IP isn't mine to fix." On shared outbound infrastructure, they're right — and their response time to that ticket tells you a lot about whether you should stay.
Automated lists like Barracuda Central often clear within an hour of a valid request. Spamhaus CSS and PBL removals are usually same-day. Spamhaus SBL and DBL entries go to a human reviewer and typically take 24-72 hours. SURBL is somewhere in the middle. The delay that actually hurts is the one after removal: receiving mail servers cache DNSBL answers for a few hours, so mail can keep bouncing for a while after the list says you're clean. Give it half a day before you panic again.
After. Always after. Every serious blocklist re-tests you, and a second listing on the same IP or domain is treated as evidence you're not paying attention — Spamhaus in particular applies escalating scrutiny to repeat offenders. Fix the compromised mailbox, kill the script that dumped 4,000 emails in an hour, remove the stale SPF include, and only then file. One clean request beats four rushed ones.
Yes, and it's not close. An IP listing on shared hosting can be someone else's mess, and you can often route around it by moving to a different sending host. A domain listing on Spamhaus DBL or SURBL follows the domain everywhere — new host, new IP, new provider, doesn't matter. It also poisons mail that merely mentions your domain in the body, so partner newsletters linking to you start getting filtered too.
Partly. Enforce 2FA on every mailbox, cap outbound rate per account, keep SPF/DKIM/DMARC accurate, and set up blocklist monitoring so you find out before your customers do. The part you can't fix yourself is outbound filtering — if nothing scans mail on the way out, one compromised mailbox becomes a listing in under an hour. Managed hosts that run Rspamd and ClamAV on both directions catch that burst automatically, which is why self-inflicted listings are rarer on managed infrastructure than on a hand-rolled Postfix box.
Unlimited custom domain email hosting for $49/year flat — unlimited domains, unlimited mailboxes, 10 GB storage, full IMAP/SMTP. Built for agencies, freelancers, and anyone managing email across more than one domain.