Deliverability service
Off the blacklist, and kept off.
A blacklist — or blocklist — is a published list of IPs and domains believed to send spam, which receiving servers consult before accepting mail. Delisting is removal from one. The catch is that a listing is a symptom: remove it without fixing what caused it and you are relisted within hours, and many lists barely affect Gmail or Outlook in the first place.
A blacklist (or blocklist) is a published list of IPs and domains believed to send spam, which receiving servers check before accepting mail; delisting is removal from one. Doing it properly is a sequence, not a single form: read the bounce logs to identify which list is actually rejecting your mail, confirm the sub-list and reason at the list’s own checker, fix the root cause — a compromised account, an open relay, a complaint spike, a snowshoe pattern — then request removal or let an auto-expiring list clear, and finally prevent relisting. Most listings are free to clear, Spamhaus SBL is the main one that needs a request, and a listing removed before the cause is fixed is reversed within hours. Many lists barely affect Gmail or Outlook, which lean on internal reputation, so the first real question is whether the listing is on a list your recipients’ providers actually consult.
In short
- → A listing is a symptom, not the disease: remove it before fixing the compromised account, open relay or complaint spike underneath, and the same behaviour re-triggers it within hours.
- → Delisting is free everywhere that matters — CSS, XBL and SpamCop auto-expire, the PBL takes a free exclusion form, and only the Spamhaus SBL needs a request — so a fee just to submit a form is selling a button you can press yourself.
- → Not every listing is worth acting on: Gmail and Outlook lean on internal reputation over public lists, and UCEPROTECT L2/L3 list whole provider ranges, so the first question is whether your recipients’ providers actually consult the list.
- → A clean listing status with mail still in spam is the clearest sign the problem was never a blacklist — it is reputation and engagement, and a delist form will not move it.
- → Removal times range from same-day or automatic (CSS, XBL, PBL, SpamCop) to 24–48h for a first SBL listing and 1–2 weeks for a repeat, while provider reputation recovers over 2–6 weeks and is not a blocklist at all.
When a blacklist listing hits, it tends to arrive as a panic. Mail stops reaching half your recipients, the bounce logs fill with rejections naming a list nobody has heard of, and the instinct is to find the removal form as fast as possible. That instinct is usually what makes the problem worse. The listing is the visible symptom of something underneath — a compromised account, an open relay, a complaint spike, a sending pattern a filter does not like — and a removal granted before that cause is fixed is a removal that gets reversed almost immediately.
There is a second hard truth worth saying early, because it saves a great deal of wasted effort. Not every listing matters. Spamhaus protects something on the order of three billion mailboxes and its main list holds tens of thousands of active entries at any moment, so a listing there is worth acting on. A great many other lists are low-impact or list whole provider ranges, and the largest mailbox providers lean on their own internal reputation rather than a simple check against public lists. Knowing which listing is actually costing you delivery, and which is noise, is most of the value in handling one well.
Which Spamhaus list is it, and how does each clear?
Most serious listings are somewhere in the Spamhaus family, and the single most common mistake is treating “a Spamhaus listing” as one thing. It is five different systems with five different removal paths. Getting this wrong is how teams burn days submitting the wrong form to the wrong list.
| List | What it means | How it clears |
|---|---|---|
| SBL | Manually reviewed: an IP or network tied to spam, spamvertised URLs or bulletproof hosting. | No self-service. The SBL Team removes it once the cause is fixed and verified; subnet listings go through the network operator. |
| CSS (SBLCSS) | Automated: snowshoe and high-volume spam patterns spread across many IPs. | Self-service at check.spamhaus.org once the sending pattern stops. |
| XBL | Exploit data from the CBL: malware, botnet traffic, an open relay or an open proxy. | Auto-expires once the infection is removed or the relay is closed — no request needed. |
| PBL | Policy, not abuse: an IP range an ISP marks as end-user or dynamic, not meant for direct-to-MX sending. | ISP portal, or a single-IP exclusion form for a legitimate static server. |
| DBL | Domain reputation: a domain seen in spam, independent of any IP. | Resolve the domain’s abuse, then request a review. |
SBL, CSS, XBL, PBL and DBL together make up the Spamhaus ZEN combined list. Checking which one you are on, at check.spamhaus.org, comes before any removal attempt.
A listing is a symptom
The reason removal-first fails is that each list is triggered by a specific behaviour, and the behaviour is the thing to address. An XBL listing comes from the CBL and means malware, botnet traffic or an open relay was seen from your IP — a security problem before it is a mail one. A CSS listing flags snowshoe and high-volume patterns, the fingerprint of spam spread thinly across many addresses. An SBL listing is a human judgement that your IP or network is tied to spam or to the hosting that shelters it. A PBL listing is not abuse at all, but a statement that the IP is the wrong kind of address to be sending directly. Each points at a different fix, and none of them is the removal form.
In 2026 a Spamhaus listing carries an extra meaning it did not a few years ago. With SPF, DKIM and DMARC now effectively mandatory and most legitimate senders authenticated, a listing is increasingly a signal that something is compromised rather than merely misconfigured — a cracked mailbox relaying spam, a forgotten test server left open, a credential leaked and abused. Treating it as a deliverability nuisance and rushing the delist misses the real message, which is to find what is sending mail you did not authorise and close it.
# Query Spamhaus ZEN for the sending IP (reversed octets)
$ dig +short 45.2.0.203.zen.spamhaus.org
127.0.0.2 # SBL — manually reviewed, needs a request after the fix
127.0.0.4 # CSS — snowshoe pattern, auto-expires once it stops
# What does Spamhaus say the reason is?
$ dig +short 45.2.0.203.zen.spamhaus.org TXT
"https://check.spamhaus.org/sbl/query/SBLxxxxxx"
# the return code names the sub-list; the TXT points at the reason and the fix127.0.0.2 is a manually reviewed SBL that needs a request once the cause is fixed, while 127.0.0.4 is an automated CSS listing that clears on its own when the snowshoe pattern stops. Reading the code first is what stops a team from filing the wrong removal on the wrong list.What gets you listed in the first place?
The causes behind a listing are a short, recurring set, and naming the right one is the fastest route to a fix that holds. Each maps to a different list and a different repair.
- A compromised account or server. A cracked mailbox or a breached application relays spam under your IP, the classic route onto the XBL. The fix is a security one: rotate the credentials, patch the host, and find how it was reached.
- An open relay or proxy. A misconfigured server that accepts and forwards mail for anyone is found and listed quickly. Closing it is the only repair that holds.
- A complaint spike. A campaign to a stale or poorly sourced list drives complaints past the threshold a list watches, and the IP is flagged. The repair lives in the data and the sending rather than the form.
- A snowshoe pattern. Volume spread thinly across many IPs and domains to dodge limits is exactly what the CSS list is built to catch — and it catches senders who drifted into the pattern as readily as those who chose it.
- The wrong class of IP. Sending direct-to-MX from residential or dynamic space lands you on the PBL, a policy statement rather than an accusation.
- A spamtrap hit. Mail to an address that exists only to catch senders who do not clean their lists, which is among the hardest listings to argue with.
Shared IPs and the neighbour problem
A listing is not always your own doing. On a shared sending IP — the model most ESPs use for lower-volume senders — the reputation of the address is the sum of everyone on it, and a single bad neighbour can get the whole IP listed while your own sending stayed clean. You inherit the consequence without having caused it, and you cannot repair a neighbour you do not control. The options are narrow: ask the provider to act on the offender, move to a segment with better-behaved company, or move to a dedicated IP where the reputation is yours alone to build and protect. For a sender with the volume to sustain one, a dedicated IP turns reputation into something you own rather than something you share, which is the more durable answer to recurring shared-pool listings. We help weigh that move against the warm-up it demands, since a dedicated IP with no history starts from nothing.
Spamtraps: the listings hardest to argue with
Spamtraps are addresses that exist only to catch senders who are not maintaining their lists, and hitting one produces a listing you cannot really dispute. There are two kinds, and the difference is diagnostic. A pristine trap was never a real address — it was seeded onto the web to be harvested — so mail to it means you are sending to scraped or purchased data. A recycled trap was once a genuine address, abandoned and later repurposed by a list operator, so mail to it means you are still sending to people who stopped engaging long ago and were never cleaned out. Both point at the same root problem: data that is not being validated, suppressed and pruned. The only real defence is hygiene — permission-based collection, prompt removal of hard bounces, and re-engagement or suppression of the long-dormant — because once a trap is in your list, no removal keeps you off the list it triggers while the trap is still being mailed.
Not every listing is worth your time
A blacklist scan will light up entries across a dozen lists, and presented as a flat list of problems it invites you to fix all of them. Most of them do not warrant the effort, and a few cannot be cleanly fixed at all. A sensible order of attention looks like this.
- Act on these first. Spamhaus SBL and XBL, and Barracuda — these are consulted widely enough that a listing genuinely costs delivery.
- Handle if present, but calmly. Spamhaus CSS and PBL, and SpamCop — real but often auto-clearing once the cause is addressed.
- Usually safe to leave. UCEPROTECT Level 2 and 3, which list entire provider ranges and are seldom used as a primary block, and the long tail of minor lists few filters consult.
- Ignore the ghosts. Defunct lists such as SORBS, which closed in 2024, still surface in some scanning tools long after they stopped meaning anything.
How long does removal take?
Timeframes vary by list and by whether it is a first listing or a repeat. The figures below are typical once the underlying cause is resolved; none of them apply if the cause is still active, because the listing simply returns.
| List | Typical removal | Notes |
|---|---|---|
| Spamhaus SBL | 24–48h on a first listing | Repeat listings run 1–2 weeks; the cause must be verified as fixed first. |
| Spamhaus CSS & XBL | Auto-expires | Clears on its own once the pattern or infection stops. |
| Spamhaus PBL | Same day | A policy listing, not an abuse one — removed by form or ISP. |
| Barracuda (BRBL) | About 12–24h | Responsive once the cause is resolved. |
| SpamCop | 24–48h, automatic | Clears when fresh reports stop arriving. |
| UCEPROTECT | 7 days (paid express option) | L2 and L3 list whole provider ranges and are rarely used as a primary block. |
| Gmail / Outlook reputation | 2–6 weeks | Not a blocklist at all — internal reputation, which recovers slowly. |
Gmail and Outlook reputation recovery is a separate, slower process from any blocklist removal, and the one most often mistaken for a blacklist problem.
Delisting is free — so what are you paying for?
This is the part of the service we would rather state plainly than let you discover later. The act of delisting costs nothing. Spamhaus, Barracuda, SpamCop and the rest do not charge to remove a listing, and several clear automatically with no request at all. Any firm whose pitch is simply to submit a removal form on your behalf is charging for a button you can press yourself, and we will not be that firm.
What genuinely takes skill, and what we are paid for, is everything around the form. Reading the bounce logs to find the one listing that is actually costing you delivery, rather than chasing a scan full of harmless entries. Tracing the listing to its cause — the open relay, the compromised mailbox, the sending pattern, the wrong class of IP — and closing it so the removal holds. Handling the listings that are genuinely involved, where an SBL listing needs a documented remediation the team will review, or a subnet block has to be resolved with the network operator. And confirming afterwards that the fix held and the listing has not returned. The removal is free; not getting relisted is the work.
What if the listing is your domain, not your IP?
Not every listing is about an IP. The Spamhaus DBL and similar domain and URL lists track domains seen in spam, and a domain can be listed while the sending IP is spotless. The trigger is often a link rather than the sender: a URL shortener or redirect domain others have abused, a tracking domain that picked up a bad reputation, or a landing domain that appeared in mail flagged elsewhere. Because these lists read the content of the message rather than its origin, the fix lives in what you link to — retiring a tainted shortener, moving to a clean tracking domain, and confirming that every domain in your mail carries its own healthy reputation. A domain listing also sheds more slowly than an IP one, since domain reputation is built and lost over time rather than reset on request.
Recovery after a hard listing
Removal and recovery are not the same event, and treating them as one is why senders expect mail to snap back the moment a listing clears. Delisting reverses the block; it does not restore the reputation the episode cost. After a serious listing, the receiving providers have watched a stretch of bad behaviour, and their internal reputation for your IP or domain reflects it for a while after the public list is clean. The way back is the discipline of a cold start: drop volume, send first to the most engaged recipients, and rebuild the signal of wanted mail over days and weeks rather than hours. Gmail reputation recovery in particular runs on the order of weeks for a severe case. Treating the delist as the finish line, and resuming full volume the next morning, is how a recovered sender earns a second listing.
What if it is not a blacklist at all?
A fair share of the senders who come to us convinced they have a blacklist problem do not have one. Their IPs are clean on every list that matters, and their mail still lands in spam — which points away from blocklists entirely and toward the internal reputation Gmail, Yahoo and Microsoft each maintain. No delisting helps here, because there is nothing to delist. The honest service in that case is to say so and redirect the effort to where it pays: the reputation, authentication and engagement work that our managed deliverability service exists to run. We would rather lose a delisting job than take payment for one that cannot move your delivery.
How do you stay off the lists?
Prevention is cheaper than every cure above, and it is mostly the same hygiene that protects deliverability in general. Authenticated mail with DMARC at enforcement closes the spoofing route that gets domains abused in the first place. A clean, permission-based list, validated on the way in and pruned on the way out, starves the complaint spikes and spamtrap hits that trigger most listings. Steady sending patterns — warmed IPs, consistent volume, no drift into snowshoe shapes — keep you clear of the automated lists. And monitoring the IPs and domains continuously means a listing is caught within hours, while it is still a single entry, rather than discovered weeks later as a slow bleed of lost mail. This is the posture our managed deliverability service keeps up, and most senders who have been listed once decide the watch is worth keeping.
How we run it
The sequence is deliberately unglamorous, because the discipline is the point.
- Identify the real listing. We read the bounce logs and confirm the exact list and sub-list at its own checker, rather than treating a multi-list scan as a to-do list.
- Triage by impact. We separate the listings that cost you delivery from the ones that do not, so effort goes where it changes the outcome.
- Find and fix the cause. Open relay closed, compromised account secured, sending pattern corrected, IP class addressed — the work that keeps the removal permanent.
- Submit with evidence. Where a request is needed, it goes in with a clear account of what was found and fixed, which is what manually reviewed lists require to approve it.
- Verify and watch. We confirm the removal cleared within the expected window and put the IP and domain on monitoring, so a recurrence is caught early rather than rediscovered in a bounce log.
Most of this leans on the same infrastructure knowledge we use to run mail systems day to day, because the causes of a listing — relays, compromised hosts, sending patterns, IP architecture — live in the infrastructure rather than in the removal form. We work it independently, with no fee attached to the free part, and in Spanish and Portuguese as readily as in English. The free 25-point audit is a sensible first step if you are unsure whether a listing is even your real problem; often it shows that the blacklist was a symptom of something the audit can name precisely.
FAQ
Delisting questions
Can we just remove ourselves from a blacklist?
Often, yes, and at no cost. Spamhaus CSS and XBL listings auto-expire once the behaviour or infection that triggered them stops, SpamCop clears on its own when reports stop, and a legitimate static server on the PBL can file a single-IP exclusion. The SBL is the exception that needs a request, and even then only after the cause is genuinely fixed. Delisting itself is free everywhere that matters, so anyone charging you a fee simply to submit a removal form is selling a button you can press yourself.
Will delisting fix our deliverability?
Only if a blacklist was actually the thing holding your mail back, and frequently it is not. Gmail and Outlook lean primarily on their own internal reputation rather than a simple check against public lists, so you can be removed from every blacklist in a scan and still land in spam. The right first question is whether the listing is on a list your recipients’ providers actually consult. If your problem is Gmail placement, the work is reputation and engagement, not a delist form.
We delisted and got relisted within hours. Why?
Because the cause was still active when you requested removal. A blacklist listing is a symptom; submitting the form without fixing the underlying open relay, compromised account, complaint spike or snowshoe pattern means the same behaviour re-triggers the listing immediately. Spamhaus verifies that the issue is resolved before approving a removal, and it can disable self-service delisting entirely until it is satisfied the problem is gone. The order matters: fix first, delist second.
Do you charge to delist us?
No, because delisting is free and we will not pretend otherwise. What we are paid for is the part that actually takes skill: diagnosing which listing matters and which is noise, finding and fixing the root cause so the listing does not return, and handling the cases — a manually reviewed SBL listing, a compromised server, an ISP-level subnet block — where the removal is genuinely involved. If your situation is a one-click auto-expiring listing with an obvious cause, we will tell you to handle it yourself and save your money.
We are on UCEPROTECT Level 3. Is that a problem?
Usually not a serious one. UCEPROTECT’s higher levels list entire provider IP ranges rather than individual offenders, which makes them too broad for most serious filtering stacks to use as a primary blocking signal. A Level 1 listing can occasionally matter; Level 2 and Level 3 rarely do on their own. We check whether any provider your recipients use actually consults it before spending effort there, and most of the time the honest answer is to leave it alone and focus on the listings that move delivery.
We are on the PBL but run a real mail server. What now?
The PBL is not an accusation of spam — it flags IP ranges that ISPs have designated as end-user or dynamic space, not meant to send directly to mail exchangers. If you run a legitimate mail server on a static IP that landed there, the fix is a single-IP exclusion through the form or your ISP. If the IP is genuinely residential or dynamic, the listing is correct, and the real answer is to send through a proper relay or sending infrastructure rather than direct-to-MX from that address.
Our IP is clean on every list but mail still goes to spam. What is going on?
That is the clearest sign the problem was never a blacklist. Placement into spam with a clean listing status points at reputation and engagement — the signals Gmail, Yahoo and Microsoft weigh internally — rather than at any public list. Chasing blacklist checks here wastes time on a symptom that is not present. The work that helps is the ongoing reputation and placement management that lives in our managed deliverability service, and we will point you there rather than sell you a delisting you do not need.
How do we know which list is actually affecting us?
Your bounce logs usually name it: a rejection from a receiving server typically cites the specific list and often a URL to the listing. From there a lookup at the list’s own checker confirms the sub-list and the reason. The mistake we most often correct is a team treating a multi-list scan as a to-do list and chasing low-impact entries while the one listing that matters goes unfixed. We read the logs, identify the listing that is actually costing you delivery, and start there.
Start with the audit.
Twenty-five points across authentication, reputation, infrastructure and compliance — a written assessment, no charge and no obligation. It tells both of us exactly what we are working with.