1997: DNS Blocklists: The Community Blacklists That Stopped Spam

In the summer of 1997, Paul Vixie was fed up with spam. Vixie was not a random internet user with an overflowing inbox. He was one of the most important infrastructure engineers in the history of the internet — the principal author of BIND, the DNS software that resolved domain names for most of the world’s servers, and the founder of the Internet Software Consortium. When Paul Vixie decided to do something about spam, the results tended to be consequential.

What Vixie created was the MAPS RBL — the Mail Abuse Prevention System Realtime Blackhole List. It was the first DNS-based blocklist, and it established a model for community-driven anti-spam defense that persists to this day. The idea was deceptively simple: maintain a list of IP addresses known to send spam, publish that list via DNS, and let mail servers worldwide query the list in real time to decide whether to accept incoming messages.

How DNS Blocklists Work

The technical elegance of DNS-based blocklists is worth understanding, because it explains why the model was so successful and so widely adopted.

DNS — the Domain Name System — is the internet’s phone book. When you type a website address into your browser, DNS translates that human-readable name into an IP address that computers can use. DNS queries are fast (typically milliseconds), lightweight, distributed across thousands of servers worldwide, and supported by every device on the internet.

Vixie realized that this same infrastructure could be repurposed for spam blocking. Here’s how it works: suppose a mail server receives an incoming connection from IP address 192.0.2.99. To check whether that IP is on the blocklist, the mail server reverses the octets of the IP address and appends the blocklist’s domain name, creating a DNS query like: 99.2.0.192.dnsbl.example.com.

If the blocklist contains that IP, the DNS query returns a result (typically 127.0.0.2). If the IP is not listed, the query returns “no such domain” (NXDOMAIN). The entire check takes milliseconds and requires no special software, protocol, or infrastructure beyond what every internet-connected server already has.

This was brilliant for several reasons. There was no need to download or sync massive databases. There was no need for specialized client software. Any mail server that could make DNS queries — which was all of them — could check blocklists with trivial code changes. The blocklist operator maintained a single authoritative database, and DNS’s built-in caching and distribution ensured that queries were fast regardless of where in the world the mail server was located.

The MAPS RBL

Vixie’s original MAPS RBL launched in 1997 as a blackhole list — IP addresses on the list were literally “black-holed,” meaning mail from those addresses was silently discarded. The list was curated by Vixie and a small team of volunteers who investigated spam complaints, verified sources, and added confirmed spam-sending IP addresses to the list.

The RBL concept was controversial from the start. Blocking email based on the sender’s IP address was a blunt instrument. If a shared hosting server sent spam, the entire IP address — including all the legitimate users on that server — would be blocked. If an ISP tolerated spammers among its customers, the ISP’s entire IP range might be listed, affecting all of the ISP’s customers.

Vixie argued that this collateral damage was a feature, not a bug. If blocking an ISP’s IP range caused legitimate users to lose email, those users would pressure the ISP to deal with its spam problem. The blocklist created an economic incentive for ISPs and hosting providers to police their networks — an incentive that hadn’t previously existed.

This reasoning was valid but ruthless. Small businesses lost email because their hosting provider was slow to respond to spam complaints. Universities found their entire mail systems blocked because a student’s compromised computer was sending spam. The power that a few blocklist operators wielded over global email communication raised legitimate questions about governance and accountability.

The Spamhaus Project

The most influential blocklist organization to emerge after Vixie’s pioneering work was the Spamhaus Project, founded by Steve Linford in 1998 in London. Spamhaus developed multiple specialized lists that became essential components of email security infrastructure worldwide:

The Spamhaus Block List (SBL) contained IP addresses of verified spam sources and spam operations. Entries were manually curated by Spamhaus researchers who investigated spam campaigns and identified the infrastructure behind them. The SBL was considered the gold standard of IP-based blocklists — conservative enough to avoid excessive false positives, but comprehensive enough to block a significant portion of spam.

The Exploits Block List (XBL) focused on IP addresses of compromised machines — computers infected with malware that were being used to send spam without their owners’ knowledge. The XBL aggregated data from several sources, including the CBL (Composite Blocking List), and was typically the largest of the Spamhaus lists by entry count.

The Policy Block List (PBL) listed IP ranges that should never be sending email directly — typically dynamic IP addresses assigned to residential broadband connections. Legitimate email from these addresses should be sent through the ISP’s mail server, not directly from the end user’s computer. Direct connections from these IPs were almost always from infected machines.

The Domain Block List (DBL), introduced in 2010, marked an important evolution. Rather than listing IP addresses, the DBL listed domain names associated with spam — domains used in spam message URLs, phishing domains, and malware distribution domains. This was a response to the decreasing utility of IP-based blocking as spammers moved to cloud hosting where IP addresses were ephemeral and shared.

Spamhaus processed billions of DNS queries per day from mail servers worldwide. The organization operated as a not-for-profit, funded by data feeds sold to large-scale users (ISPs, large email providers) while providing free access to smaller operators. This model allowed Spamhaus to maintain its independence while sustaining operations at a scale that would be impossible for a purely volunteer effort.

The Proliferation

The success of the MAPS RBL and Spamhaus inspired numerous other blocklist operators:

SORBS (Spam and Open Relay Blocking System) maintained lists of open relays, open proxies, and dynamic IP ranges. SORBS was known for aggressive listing policies that generated significant controversy but also blocked substantial spam.

Barracuda Reputation Block List (BRBL) was maintained by Barracuda Networks, a security appliance vendor. Unlike community-operated lists, the BRBL was backed by data from Barracuda’s extensive network of email security appliances deployed worldwide.

SpamCop allowed email users to report spam, automatically identified the source, and maintained a blocklist based on complaint volume. SpamCop’s approach was more automated than Spamhaus’s curated model, which made it faster to update but also more susceptible to manipulation by organized delisting efforts.

UCEPROTECT operated a multi-level blocking system: Level 1 listed individual IPs, Level 2 listed entire allocation blocks, and Level 3 listed entire Autonomous System Numbers (ASNs). The escalating levels created increasing pressure on network operators to control spam from their networks.

At the peak of the proliferation, there were dozens of active blocklists with varying levels of quality, reliability, and aggression. SpamAssassin integrated checks against multiple blocklists into its scoring system, assigning different point values to different lists based on their reliability. Being listed on Spamhaus SBL might add 3 points to SpamAssassin’s spam score, while being listed on a less reliable list might add only 1 point.

The Power Controversies

The concentration of email blocking power in the hands of a few organizations — particularly Spamhaus — created ongoing tension. Several incidents highlighted the stakes.

The Spamhaus v. e360 Insight lawsuit (2006) was a landmark case. e360 Insight, a bulk email company, sued Spamhaus in the United States for listing e360’s servers, claiming tortious interference with business. Spamhaus, headquartered in London, initially declined to participate in the U.S. proceedings, resulting in a default judgment of $11.7 million against Spamhaus. The judgment was later vacated on appeal when the court determined that e360 couldn’t demonstrate actual damages. The case established important precedents about the legal status of blocklist operators and their right to publish opinions about email sources.

The 2013 Spamhaus DDoS attack was one of the largest distributed denial-of-service attacks in internet history at that time. A Dutch hosting provider, CyberBunker, and its associates were accused of launching a massive DDoS attack against Spamhaus after being listed on the SBL. The attack peaked at approximately 300 gigabits per second, large enough to cause measurable slowdowns in internet traffic across Europe. Several people were eventually arrested and convicted in connection with the attack. The incident demonstrated both the importance of Spamhaus to global email infrastructure and the lengths to which some parties would go to avoid being listed.

Overly aggressive listing was a recurring complaint. When a blocklist operator listed an entire ISP’s address range because of spam from a few customers, the collateral damage could be enormous. Legitimate businesses lost email. Customer service departments were flooded with complaints. And the affected parties often had no recourse — blocklist operators were generally volunteer organizations with no formal appeals process and no accountability to the people affected by their decisions.

The Evolution: From IP to Domain to Reputation

The blocklist model evolved significantly over its history, driven by changes in how spam was sent.

In the late 1990s and early 2000s, most spam came from fixed IP addresses — dedicated spam servers, open relays, or compromised machines with static IPs. IP-based blocking was effective because the source infrastructure was persistent. Block the IP, stop the spam.

As cloud computing and dynamic IP allocation became common, IP-based blocking became less effective. A spammer could spin up a cloud server, send spam for an hour, and abandon the IP. By the time the IP was listed, the spammer had moved on. Meanwhile, the IP might be reassigned to a legitimate user who found themselves inheriting a blocklist entry.

The shift to domain-based blocking (exemplified by Spamhaus DBL) was a response. Spammers might use many different IPs, but the domains in their spam messages — the URLs they wanted recipients to click — were more persistent. Blocking the domain rather than the IP proved more durable.

The next evolution was reputation systems. Rather than binary listed/not-listed decisions, reputation systems assigned continuous scores to IP addresses and domains based on their observed behavior over time. Google’s sender reputation system, Microsoft’s Smart Network Data Services, and Return Path’s (later Validity’s) Sender Score all provided nuanced reputation assessments that influenced email delivery without the blunt force of blocklist rejection.

Modern email security uses all three approaches in combination. SPF, DKIM, and DMARC authenticate senders at the domain level. IP-based blocklists catch known-bad infrastructure. Reputation systems provide continuous risk assessment. And machine learning models layer additional analysis on top of all these signals.

The Present Day

DNS blocklists remain a critical component of email security infrastructure, despite being nearly three decades old. Spamhaus alone processes over 100 billion DNS queries per day. Most major email providers check multiple blocklists as part of their filtering process. SpamAssassin and other filtering tools continue to incorporate blocklist checks as significant scoring factors.

The blocklist ecosystem is more mature and professionalized than in its early years. Listing and delisting processes are generally documented and accessible. The most aggressive lists have either moderated their policies or lost relevance as the industry converged on more balanced approaches. The legal landscape has clarified the rights of blocklist operators to publish their assessments.

But the fundamental model — a shared, queryable database of known bad actors, maintained by the community for the community — remains the same model Paul Vixie conceived in 1997. The neighborhood watch for email is still on patrol.

If you’re running email infrastructure and want to make sure your sending IPs and domains are clean, you can check whether your domain appears on major blocklists using our free Blacklist Checker tool. And for a deeper understanding of how blocklists fit into the broader anti-spam ecosystem, see our coverage of the economics of spam and the SpamAssassin project that integrates blocklist checks into its scoring engine.

Infographic

Share this visual summary. Right-click to save.

Frequently Asked Questions

What is a DNS blocklist?

A DNS blocklist (DNSBL), also called a DNS blacklist or RBL (Realtime Blackhole List), is a database of IP addresses or domains known to send spam. Mail servers check incoming messages against these lists using fast DNS lookups. If the sender's IP appears on the list, the message can be rejected, flagged, or scored as likely spam.

How do I check if I'm on a blocklist?

You can check whether your sending IP or domain appears on major blocklists using lookup tools that query multiple lists simultaneously. Being listed usually means your server has been observed sending spam or your IP belongs to a range associated with spam activity. You can check whether your domain appears on major blocklists using our free Blacklist Checker tool at /tools/blacklist-checker.

How do I get removed from a blocklist?

Each blocklist has its own delisting process. Generally, you need to identify and fix the source of spam (compromised account, misconfigured server, purchased list), then submit a delisting request through the blocklist's website. Spamhaus, SORBS, and Barracuda each have online delisting forms. Some lists delist automatically after a period with no spam activity.