What is SORBS?
DNS zone: dnsbl.sorbs.net
SORBS (Spam and Open Relay Blocking System) was a long-running family of DNS blocklists covering spam sources, open relays, proxies, hijacked hosts and dynamic IP space. Its aggregate zone, dnsbl.sorbs.net, combined all of them into one lookup, with return codes identifying the category.
In mid-2024 its operator, Proofpoint, discontinued SORBS and the project ceased operations. Since then the zones have not been actively maintained: responses can be stale leftovers, empty, or plain DNS errors. That is why modern checkers, ours included, treat SORBS results as low-confidence and expect intermittent failures.
How serious is a SORBS listing?
Minimal and shrinking. Mail administrators have been removing SORBS from their filter configurations since the shutdown, because querying a dead list causes false positives and timeouts. A residual SORBS hit can still matter at the rare mail server whose admin never updated the config, but it should never be your deliverability priority.
Why your IP got listed
A stale pre-shutdown listing
Your IP (or more likely a previous holder of it) was listed before mid-2024 and the entry was never cleaned up because nobody maintains the zone.
DNS artefacts and mirrors
Leftover mirrors or resolver quirks can return listing-like answers for a zone that is no longer authoritative in any meaningful sense.
A misread error
Timeouts and SERVFAILs from the dead infrastructure are sometimes displayed as listings by naive checkers. Our checker shows these as "Check failed" instead.
How to remove your IP from SORBS
Verify the result before acting
Re-run the check and compare against the other 20 lists. A SORBS-only hit with everything else clean is almost certainly stale noise. A SORBS hit alongside Spamhaus or Barracuda listings means you have a real problem, and those lists are where to act.
Do not hunt for a SORBS delisting form
The historical process (a support ticket through the SORBS site) is gone. There is no functioning removal channel, and any service selling SORBS removal today is selling nothing.
If a specific receiver still blocks you citing SORBS
Contact that mail server's postmaster directly, point out that SORBS was discontinued in 2024, and ask them to drop the zone from their configuration. Admins are generally receptive; a dead blocklist harms their own users' mail.
Spend the effort on live lists
Check the actively maintained lists in the same sweep (Spamhaus, SpamCop, Barracuda) and work through their guides if flagged. Those decide your real inbox placement.
How long removal takes
There is no removal timeline because there is no removal process. Stale entries persist indefinitely on unmaintained infrastructure, and the practical fix (a receiver dropping the zone) happens per-receiver. The good news: the population of receivers still querying SORBS keeps shrinking.
After delisting: the part most guides skip
Getting off SORBS removes a block; it does not restore trust. While you were listed, mailbox providers were accumulating their own negative signals about your domain (bounces, spam-folder placements, dropped engagement), and those persist after the listing clears. If placement does not bounce back within a couple of weeks, the domain needs a structured re-warming: reduced volume, genuinely engaged recipients and clean authentication, sustained until providers trust the domain again.
Frequently asked questions
Is SORBS still active?
+
No. Proofpoint discontinued the SORBS project in mid-2024 and the lists stopped being maintained. Residual DNS responses can still appear, but they no longer reflect current data, and most mail administrators have removed SORBS from their filters.
How do I get delisted from SORBS?
+
You cannot in any meaningful sense: the removal process shut down with the project. Verify the hit is not just a stale artefact, and if a particular receiver still blocks on SORBS, ask their postmaster to drop the dead zone. Focus your delisting effort on actively maintained lists.
Should I worry about a SORBS listing in my blacklist report?
+
On its own, no. Cross-check the maintained lists in the same report. If they are clean, your deliverability problem, if you have one, lies elsewhere: authentication, content or provider-level reputation rather than blocklists.