SORBS blacklist: how to delist and prevent re-listing

For two decades SORBS (the Spam and Open Relay Blocking System, run originally out of Australia) was a major DNSBL operator with one quirk that made it controversial: it categorised listings by reason, and its DUHL feed for "dynamic user host list" entries was famously aggressive. Many legitimate small business sending IPs ended up on DUHL because their reverse DNS pattern looked like a residential ISP allocation.

The 2024 Proofpoint shutdown — what it means

Proofpoint acquired SORBS as part of a broader infrastructure consolidation and in mid-2024 announced the public DNSBL would be retired. The feed servers stopped accepting new listings in June 2024 and the lookup interface was wound down shortly after. For most modern receivers — Gmail, Microsoft 365, Yahoo, anything cloud-filtered — SORBS is no longer a delivery factor.

However, you may still see SORBS-attributed blocks in 2026 from:

• On-prem mail gateways (Postfix, Exim, Sendmail) at small ISPs and self-hosted business mail servers, where admins configured SORBS zones years ago and never updated.
• Open-source spam filters shipping default DNSBL configurations that still include SORBS by name, sometimes returning cached or unauthoritative results.
• Custom Postfix configurations usingreject_rbl_client rules that point at the retired zones.

If you're seeing recent SORBS-related bounces, the issue is on the receiving side — not on yours. The fix is contacting the receiver's admin and asking them to update their DNSBL list. There is no live SORBS removal request to file in 2026.

Historical sub-lists — what each one meant

Knowing the categories still matters, because legacy bounce text references them and because the underlying issues (dynamic-IP appearance, open relays, zombie compromises) are the exact same issues that get you listed on Spamhaus and Barracuda today.

• http (SORBS HTTP). IP detected as an open HTTP proxy. Closing the proxy was the only fix.
• socks (SORBS SOCKS). Same as above for SOCKS proxies.
• misc (SORBS MISC). Other open proxy types (SMTP, telnet, etc).
• smtp (SORBS SMTP). Open SMTP relay confirmed.
• web (SORBS WEB). Vulnerable web form being abused for spam relay.
• spam (SORBS SPAM). Manually listed for spam-trap hits or reported abuse.
• recent / new (RECENT-SPAM, NEW-SPAM). Time-windowed variants of the spam list.
• block (SORBS BLOCK). Operator requested no mail from this IP.
• zombie (SORBS ZOMBIE). Compromised end-user machine.
• dul / DUHL. Dynamic IP space — addresses likely to be residential ISP allocations and not legitimate mail servers.

DUHL was the one that bit legitimate senders

DUHL — Dynamic User Host List — auto-listed IPs whose reverse DNS pattern matched residential allocations. If your reverse DNS read like cpe-12-34-56-78.example-isp.net or 78.56.34.12.dynamic.example-isp.net, you got DUHL-listed regardless of whether you actually sent any spam.

The fix that worked then and still solves the same problem with modern lists today:

1. Get a static IP from your ISP if you don't already have one.
2. Set the PTR record to a meaningful, mail-related hostname: mail.yourdomain.com, not the ISP's default. Coordinate with the ISP because the PTR is set in their reverse-zone delegation.
3. Configure forward-confirmed reverse DNS (FCrDNS): the A record of mail.yourdomain.com must resolve back to the IP. Many receivers verify this independently today.
4. Set HELO / EHLO to the same hostname your PTR resolves to. Mismatches alone can trigger modern filtering.

How SORBS delisting worked (historical reference)

For senders who bookmarked the old workflow or are dealing with archived bounce reports: SORBS delisting was per-sub-list and required separate forms. The lookup at sorbs.net/lookup.shtml indicated which lists applied. Each list had its own form linked from the result.

Manual lists (SPAM, BLOCK) required a removal request with evidence the abuse stopped. Auto-detect lists (DUHL, proxy/relay categories) required first proving the underlying condition (dynamic IP appearance, open service) was fixed. Response times ranged from 48 hours to multiple weeks.

The legacy delisting infrastructure is no longer reachable in 2026. Any "SORBS removal" service charging fees in the current year is a scam.

Modern equivalents to watch instead

With SORBS gone, the behaviour categories it monitored have not disappeared — they're monitored by other lists. The rough mapping for a 2026 sender:

• Open relay / proxy detection: CBL feed inside Spamhaus XBL, plus various cloud-provider abuse desks.
• Dynamic IP detection: Spamhaus PBL, Microsoft's dynamic-IP heuristic, Gmail's built-in detection.
• Spam-trap hits: Spamhaus SBL, SpamCop SCBL, Barracuda BRBL.
• Compromised endpoint detection: CBL, plus ISP-level botnet feeds shared between AOL, Microsoft and others.

Troubleshooting a SORBS bounce in 2026

If you're reading this because of a recent bounce mentioning SORBS, the workflow is:

1. Confirm the bounce is recent and not a stale failure report. SORBS DNS zones may now return errors that permissive filters interpret as listings.
2. Identify the receiving server. Look at the bounce headers for the receiving MX hostname.
3. Reach out to the receiving organisation's postmaster. Tell them SORBS was retired in mid-2024 and ask them to remove the SORBS zone from their DNSBL list.
4. If you can't reach the postmaster, document the bounce and accept the loss. The sending side cannot resolve a retired-list listing.
5. In parallel, audit your IP for the underlying issues SORBS would have flagged: PTR sanity, no open services, clean sending behaviour. These will surface elsewhere if not already addressed.

Frequently asked questions