If a blocklist checker reports you on SORBS, there is nothing to delist. Proofpoint, which had operated SORBS since acquiring it in 2011, shut the service down on 5 June 2024 after more than two decades. The database is no longer maintained, its zones do not answer reliably, and removal requests are not processed by anyone.
That matters mostly because so much tooling and so many guides have not caught up.
What a SORBS result means today
- A "listed" row in a multi-list checker is either a cached result, a stale local copy of the zone, or a checker that has not updated its list of lists. It is not evidence that any receiver is refusing your mail.
- A rejection that names SORBS means the receiving server is running an old configuration that still queries a dead zone. Dead zones can behave unpredictably — including, in some failure modes, answering positively for everything — which is why mail operators were urged to remove SORBS from their configurations promptly.
- Your own mail server should not be querying it. If you run Postfix, Exim, or a filtering appliance with a SORBS zone in its DNSBL list, remove it. A dead list in your query chain adds latency at best and blocks legitimate mail at worst.
The one case that needs action
If a recipient's server is rejecting your mail with a SORBS reference, you cannot fix it from your side — there is no delisting path. Contact the recipient's postmaster, say plainly that SORBS was decommissioned in June 2024 and that their configuration is querying a retired zone, and ask them to remove it. Most will, because the same misconfiguration is blocking plenty of other legitimate mail.
In the meantime, confirm your own house is in order on the lists that are live, so the conversation is short: Spamhaus (ZEN and DBL), Barracuda, SpamCop, and the URI lists.
SORBS DUHL and the other sub-zones
SORBS ran several zones — the DUHL (dynamic user and host list), the spam zone, open relay and proxy zones. All of them went down with the service. Guides specifically about "SORBS DUHL removal" are describing the same decommissioned infrastructure. The underlying *concern* remains real, though, and it is worth fixing on its own merits: if your sending IP is in a dynamic or residential range, Spamhaus PBL will list it and plenty of receivers will refuse you. Send through a proper relay or a static, forward-confirmed address.
What to monitor instead
A short, current list beats an exhaustive historical one:
| List | Why it matters |
|---|---|
| Spamhaus ZEN | Widest reach of any IP list |
| Spamhaus DBL | Domain-level, catches link domains too |
| Barracuda BRBL | In front of many corporate mail systems |
| SpamCop SCBL | Fast-moving, auto-expiring, widely consulted as one input |
| SURBL / URIBL | Link-based listings |
| Validity Heatwave | New domain list aimed at synthetic warming, feeds live filtering |
Then measure the thing a blocklist can never tell you: whether your mail is reaching inboxes, per provider. A listing explains a drop; placement monitoring is what detects one.
The broader lesson
Blocklists come and go, and tooling lags both. Treat any "you are on N of 60 lists" result as a starting point for triage rather than a verdict, and weight each row by whether receivers actually consult that list. The alternative is chasing removal from services that have not existed for years.
MailPilot checks the lists that are live and consulted, against your sending domains and IPs, and reports them next to your daily per-provider placement.
Sources: CSO Online, heise, Verifalia.
Ready to reach the inbox every time?
Automated email warmup across real peer mailboxes. Live inbox placement monitoring. Free 7-day trial - no credit card required.
Start free trial