This blocklist is technically online but receives inconsistent maintenance. Its deliverability impact is lower than actively maintained lists.
What it is
SORBS (Spam and Open Relay Blocking System) operated one of the largest and most controversial email blocklists of the 2000s. Its RHSBL (Right-Hand Side Blocklist) targeted domain names used in spam campaigns. SORBS was acquired by Proofpoint in 2011 and subsequently transitioned into Proofpoint's internal threat intelligence infrastructure.
Ownership history
How it affects SMTP delivery
The SORBS RHSBL still receives queries from legacy MTA configurations that have not been updated since Proofpoint's acquisition. Its responses are inconsistent and removal requests are handled sporadically. Senders finding themselves listed here should prioritise addressing other more actively maintained lists.
What causes a listing
Historical SORBS listings reflected domains used in spam, open relay abuse, or associated with known spam networks. Current listing behaviour is unpredictable due to inconsistent maintenance.
How to get removed
Removal requests can be submitted via the Proofpoint support channels. Response times are inconsistent. Listings on the legacy SORBS infrastructure are increasingly irrelevant to modern mail filtering.
For the full reference catalog, see the email blocklist directory.
Delisting process in detail
SORBS (Spam and Open Relay Blocking System) operates both IP-based zones (sorbs.net DNSBL) and RHSBL zones that list domains rather than IPs. RHSBL removal is handled at sorbs.net through the delisting portal specific to the listed zone (rhsbl.sorbs.net, badconf.rhsbl.sorbs.net, nomail.rhsbl.sorbs.net). SORBS delisting historically required a nominal fee for expedited processing, which drew criticism; the fee has been reduced or waived in most cases as of recent years. Automatic delisting occurs after the observed abuse pattern stops, typically 7-14 days. Manual delisting requires documenting the abuse cause and remediation steps.
Prevention practices
SORBS RHSBL listings are domain-based rather than IP-based, so prevention focuses on domain hygiene: configure DMARC at reject to prevent domain spoofing, monitor DNS for unauthorized additions, audit third-party services that resolve to your domain. Nomail.rhsbl targets domains that should not send mail; ensure your DNS records correctly indicate whether the domain sends mail (SPF with -all versus ~all, DMARC published, MX records present if you receive). Badconf.rhsbl catches misconfigured domains: broken SPF syntax, dangling MX records, missing NS records, and similar DNS hygiene issues.
Common listing causes
RHSBL listings typically come from domains actively used in spam, hijacked domains (dangling subdomains re-registered by attackers), or newly-registered gTLDs that pattern-match known spam campaigns. Badconf.rhsbl catches DNS misconfiguration that inadvertently signals spam sending: MX records pointing to nonexistent hosts, SPF records that overflow the DNS lookup limit, or CNAME chains that break email authentication. Nomail.rhsbl catches domains declared as non-mail-sending that unexpectedly send mail: this is a soft signal, not a spam accusation, but affects delivery to strict receivers.
Related blocklists
SORBS operates alongside Spamhaus DBL, SURBL, and URIBL as one of the four main domain-based blocklists. Its IP-based zones (dnsbl.sorbs.net) compete with Spamhaus ZEN and Barracuda’s RBL. SORBS is queried by mid-market mail servers more than by major mailbox providers, so its impact varies significantly by recipient. Gmail, Outlook, and Yahoo rely primarily on internal reputation systems rather than external DNSBLs, so a SORBS listing has less impact at those providers than at smaller ISPs and enterprise gateways that query SORBS directly.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
