We Got Blocklisted: What to Do When Your Email Lands on a Blocklist

It usually starts the same way. Bounces spike overnight, someone in marketing notices campaign delivery cratered, and somewhere in the bounce log there's an error message with a domain in it nobody's ever heard of, like zen.spamhaus.org, bl.spamcop.net, or b.barracudacentral.org. Then the email arrives in my inbox: "We got blocklisted. What do we do?"

Take a breath. A blocklisting is a fire, but it's a fire with a well-worn playbook. And here's the part senders resist: it's almost never random. Something in your program put you there, and if you only chase the delisting without finding that something, you'll be back.

This post is the playbook: how blocklists work, which ones matter (fewer than you think), how to figure out what you're on, how to get off, and how to not end up on it again.

How email blocklists actually work

Most public blocklists are DNSBLs, short for DNS-based blocklists. The mechanics are simple, and they haven't changed much since the late 1990s. The list operator publishes a database of IP addresses (or domains) they believe are sending spam, and they make it queryable over DNS, the same system your browser uses to look up websites.

When your email arrives at a receiving mail server, that server takes your sending IP, reverses it, sticks the blocklist's hostname on the end, and does a DNS lookup. If you're sending from 203.0.113.7, the receiver queries 7.113.0.203.zen.spamhaus.org. If the lookup returns an answer, you're listed, and the receiver does whatever its policy says, which usually means rejecting the message outright, though some junk it or throttle it instead. If the lookup returns nothing, you pass.

That's it. That's the whole technology. A DNSBL is a phone book of IPs someone doesn't trust, checked millions of times a second by mail servers all over the world. The interesting questions are all about the someone: who runs the list, how you get on it, who actually checks it, and what it takes to get off.

(One vocabulary note: the industry has largely moved from "blacklist" to "blocklist." You'll see both. Same thing.)

The block you can't look up: mailbox providers' internal lists

Here's a distinction that trips up even experienced senders. The public DNSBLs are only half the picture, and arguably the smaller half.

Gmail, Microsoft, Yahoo, and Apple all maintain their own internal reputation systems and block lists. These are not DNSBLs. There is no site to check, no lookup tool, and no listing page. The only way to know you're on one is to read your bounce messages and logs. When Gmail rejects you with:

550-5.7.1 [203.0.113.7] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent
550-5.7.1 to Gmail, this message has been blocked.

That's Gmail's own reputation system talking. No third-party blocklist is involved, no delisting form exists, and no blocklist checker on the internet will show it. The same goes for Microsoft's S3150 blocks and Yahoo's TSS04 deferrals. Each provider's block is its own animal with its own remediation path.

And to make it properly confusing: mailbox providers also use the public DNSBLs as one input among many. A Spamhaus listing will hurt you at providers that subscribe to Spamhaus data, on top of whatever their internal systems think of you. So the two layers stack.

The practical takeaway: your bounce log is the single source of truth. Not a checker tool, and not a dashboard. The receiving server tells you exactly why it refused your mail, in the bounce, every time.

First move: read the bounce

Before you check anything else, pull the actual SMTP bounce text from your ESP or MTA logs and read it. In the majority of blocklist cases, the bounce names the list:

554 5.7.1 Service unavailable; Client host [203.0.113.7] blocked
using zen.spamhaus.org; https://check.spamhaus.org/query/ip/203.0.113.7

That one line tells you the list (Spamhaus ZEN), confirms it's an IP listing, and hands you the URL to look up your specific listing. That's your diagnosis and your starting point in a single log entry.

Segment your bounces by receiving domain while you're in there. A public DNSBL listing hits you across many receiving domains at once, like corporate domains, small ISPs, and universities. A mailbox provider's internal block hits only that provider. The pattern of who's bouncing tells you which layer you're dealing with.

Not all blocklists matter. Most don't.

At some point someone on your team will run your IP through a blacklist checker and come back pale: "We're listed on eight blacklists!" This is where a lot of senders spiral, and it's where I get to deliver good news.

There are hundreds of public blocklists. The number that can meaningfully affect your delivery is roughly half a dozen. The rest are hobby projects, zombie lists nobody queries, or lists so aggressive that no real mail system would dare use them. Some are literally dead. SORBS, a list that terrified senders for two decades, shut down in June 2024, and checker tools and stale blog posts kept "listing" people on it long after.

The short version of the watchlist: Spamhaus matters most, by a wide margin. Its data is used directly or indirectly by most of the world's mailbox providers. After that, a small tier of lists used by real filtering products: SpamCop, Barracuda, Cloudmark CSI, Proofpoint's reputation systems, Invaluement, Trend Micro ERS. They behave differently enough that I'll take them one at a time later in the series.

And then there's the special case: UCEPROTECT, famous for listing entire networks at its higher levels and offering "express delisting" for a fee. Here is a rule you can carry for life: legitimate blocklists never charge for delisting. Not expedited, not "administrative fee," and not donation-strongly-suggested. The moment money enters the delisting conversation, you are not dealing with a list any serious mail system trusts, and the correct response is to close the tab. If your mail is actually delivering fine, a listing on a list like that is noise.

So before you panic about any listing, ask the only question that matters: is mail actually bouncing because of it? If the answer is no, it's trivia, not a crisis.

IP listings vs. domain listings

One more distinction before we get to delisting, because it changes the entire diagnosis.

Classic blocklists list IP addresses. But the lists that hurt also maintain domain blocklists (Spamhaus's DBL is the big one), and a domain listing follows you everywhere. New IPs won't help. A new ESP won't help. The listing is attached to the name, not the infrastructure.

And the listed domain isn't always your sending domain. Receivers scan every domain in the message: the from domain, the links, the images, the click-tracking domain your ESP wrapped your links with. I've seen senders with pristine sending domains blocked because a partner's domain in the footer was DBL-listed, and senders blocked because their ESP's shared click-tracking domain got listed thanks to another customer on the same infrastructure.

If your bounce references a URL or domain block, inventory every domain that appears anywhere in your message body and check each one. The culprit is frequently not the one you'd guess.

If you're on a shared IP, whose problem is this?

If you send from an ESP's shared IP pool and that IP gets listed, the delisting itself is your ESP's job. They own the IP, they have the relationship with the list operators, and blocklist operators generally won't work delisting requests from someone who doesn't control the IP anyway. Open a ticket, reference the bounce, let them run it.

But don't fully relax. Shared pools get listed because of what the pool sent, and you might be the reason, or at least a contributor. If your ESP's compliance team comes asking about your list sources after a pool listing, that's not harassment, that's them doing the root-cause work this post keeps telling you to do. And if you're repeatedly on listed shared IPs across different pools, the common denominator argument starts pointing at your data.

One non-alarm worth flagging: Spamhaus's PBL lists IP space that shouldn't be sending direct mail at all (dynamic ranges, residential space). If a checker shows a "PBL listing," that's a statement about the IP range's policy, not an accusation of spamming. It matters if you're running your own mail server on the wrong IP space; it means nothing if your mail routes through your ESP.

Getting delisted: how blocklist removal works

Every reputable list publishes its own removal process, and the bounce already handed you the link. The processes fall into three buckets.

Self-service and automatic. Some listings expire on their own once the offending traffic stops. SpamCop delists automatically in about 24 hours; Spamhaus CSS listings age out on a similar timescale if the behavior actually changes. Others give you a lookup page with a removal button. For these, the delisting is the easy part. (Which should tell you something: the list operators made removal easy because removal isn't the point. Changed behavior is.)

Form with a human on the other end. Spamhaus SBL and DBL listings, Barracuda, Invaluement, and most of the serious lists route your request to an actual investigator who decides whether to remove you.

Reset-style systems. Cloudmark CSI and similar fingerprint-based systems don't "delist" so much as reset, and if the content or behavior that triggered the block continues, the block simply re-fires. There is no form that fixes a pattern.

What not to say when you plead your case

This is where I can save you real time. I've read a lot of delisting requests, and the same few arguments fail every single time. The people who work these queues have seen every version of every excuse. Here's what doesn't work:

"But we're CAN-SPAM compliant!" CAN-SPAM is a legal floor, not a deliverability standard. It doesn't require permission. You can be perfectly CAN-SPAM compliant while mailing a purchased list of people who never heard of you, which is exactly the behavior that got you listed. Citing it tells the investigator you don't understand why you're listed, which is the opposite of what gets you removed.

"We're a legitimate business and this listing is killing us." The list operator doesn't doubt you're a real company. Real companies send spam constantly, usually by accident. Your revenue impact is not their problem and isn't evidence of anything. Every request in the queue says this.

"We've been sending this way for years with no problems." So the data got worse, or the list finally caught up with you. Either way, this is an argument for the listing, not against it.

Threatening lawyers. Blocklists publish opinions about IP addresses; receivers voluntarily choose to use them. Legal threats have been tried for twenty-five years, they don't work, and they move your request from the "process normally" pile to the "this sender is hostile" pile.

"We bought the list from a reputable vendor." You've just confessed. Purchased data is the single most common root cause of the listings these operators deal with.

What does work is depressingly simple: figure out what actually caused the listing, fix it, and describe both concretely. "We identified that our trade-show lead imports bypassed our opt-in flow. We've suppressed those 40,000 records, added validation at the point of entry, and sunset all addresses with no engagement in 12 months." That's a request that gets processed, because it reads like it was written by someone who won't be back next month.

While you're listed: stop digging

The instinct when delivery drops is to resend: the campaign underperformed, so push it again, or route it through a backup IP. Resist all of it.

Continuing to blast through a listing deepens the damage. You're generating more trap hits, more complaints, and more evidence for exactly the systems that flagged you, and you're doing it while they're watching most closely. Pause sending, or at minimum cut back hard to your most-engaged recipients while you work the problem. And a warning about "just warm up new IPs": moving infrastructure to escape a listing without fixing the cause is called snowshoeing, list operators are extremely good at spotting it, and it's a fast way to convert an IP problem into a domain problem, the kind that follows you.

There's a longer-game reason too. Blocklist operators remember. First-time listings with a credible remediation story get handled with a certain amount of grace. The third listing in six months does not, and the delisting conversations get slower and colder each time.

Why you got listed in the first place

Spam traps are the most common trigger: addresses that should never have received your mail, planted by list operators, that fire when you hit them. They arrive on your list via purchased data, scraping, unverified forms, and plain old list decay. I wrote a whole post on why spam traps aren't a problem your tools can fix, and everything in it applies here.

But traps aren't the only path. Complaint volume at scale gets you listed. So does a compromised account or web form quietly blasting spam from your infrastructure. One of the most common causes of sudden Spamhaus listings at otherwise-clean companies is a hacked contact form or a phished employee mailbox, and if that's your cause, no amount of list hygiene will fix it. Check for compromise early in any investigation, especially if the listed traffic doesn't look like anything you knowingly send.

Whatever the trigger, the pattern underneath is the same: mail going to people who didn't ask for it, from data you can't fully account for. If you'd rather find these holes before a blocklist finds them for you, the 27-point deliverability checklist covers every root cause in this section.

If you change nothing, you'll be back

I want to be blunt about this because it's the most predictable failure in the entire process. The delisting is not the fix. The delisting is the list operator agreeing to give you another chance. If the data and practices that caused the listing are still in place, the listing will recur, usually within weeks. Same acquisition sources, no sunset policy, same unvalidated forms: the tripwires you hit are still on your list and still being mailed.

Senders treat delisting as the finish line. Operators treat it as the start of probation. The operators are right.

When to bring in help

You can absolutely work a delisting yourself, and for a simple first-time listing with an obvious cause, you should. Where a consultant earns their fee is when the cause isn't obvious: the bounce patterns don't add up, the listing keeps recurring, you're staring at a domain listing you can't explain, or the delisting request needs to be credible on the first attempt because the business can't afford a slow one. Someone who has worked hundreds of these knows what each operator responds to, what the listing type implies about root cause, and, just as valuable, which listings you can safely ignore.

That's exactly the work I do. If you're staring at a bounce log full of blocklist rejections right now, get in touch. This is a fire I've put out many times.

---

FAQ

How long does a blocklisting last? Depends entirely on the list and listing type. SpamCop auto-delists in about 24 hours; Spamhaus CSS listings age out on their own once the behavior stops; SBL and DBL listings last until a human removes them, which happens only after a credible removal request. Provider-internal blocks (Gmail, Microsoft) lift as your behavior improves, on their own timeline.

A blacklist checker says I'm on several lists. Should I panic? Not until your bounce logs agree. Most lists on checker reports aren't used by any receiver you care about. If mail isn't bouncing with that list named in the error, you can ignore it.

What's the fastest way to get off an email blacklist? Read the bounce to identify the list, stop the traffic that triggered the listing, then follow that list's own removal process. The link is usually right in the bounce. Requests that name a real cause and a real fix get processed fastest.

Can I pay to get delisted faster? No legitimate blocklist charges for removal, ever. A delisting fee is the signature of a list that no serious mail system uses. Don't pay; usually, don't even bother delisting.

We got delisted but Gmail still puts us in spam. Why? Because those are different systems. Public blocklists are one input; Gmail's internal reputation is its own machine with its own memory. Delisting removes a penalty, but it doesn't grant a good reputation. That recovery is a separate, slower project.