Have you been blocked?
All blocklists are researched and managed by The Spamhaus Project.
Simply click on the link below, which will take you to the Project’s IP and Domain Reputation Checker. From here you will be able to enter your IP or Domain and begin your request for removal.
Please note that the Project’s IP and Domain Reputation Checker is the only place where removals are handled.
IT and security teams consistently face multiple business challenges. Discover how our solutions can help overcome some of those issues.
From processing issues, to email-borne threats our blocklists easily integrate with your current email set-up to improve anti-spam & anti-virus email filtering.
Employ our threat intelligence to increase visibility across security events, reveal potential weaknesses in your network, and threats to your brand.
Stay on top of the latest threats and proactively combat botnet infections, and other forms of abuse, with our solutions.
From clicking on phishing emails to visiting malware dropper sites, our threat intelligence provides automatic protection for your users.
Data for Integration
Enhance your service and create competitive advantage by integrating Spamhaus’ world-class IP and domain reputation data.
Our products provide additional layers of security for networks and email. They also present security teams with additional insight into malicious behavior.
Border Gateway Protocol (BGP) Firewall
Block the worst of the worst at your network edge, taking advantage of your existing BGP-capable routers. Configuration only takes minutes.
Data Query Service (DQS)
Benefit from industry-leading real time blocklists. These DNSBLs easily plug into your existing email infrastructure to block spam and other email threats.
A powerful research tool to investigate relationships between internet infrastructures. Quickly pivot to new areas of concern to rapidly investigate potential threats.
Immediately block connections to dangerous sites, including phishing and malware dropper websites. A ‘set and forget’ solution.
Spamhaus Intelligence API
Threat intelligence data in API format to enable users to easily integrate metadata relating to threats with their own applications, programs, and products.
A wide range of datasets, providing multiple layers of protection. They can be plugged directly into your existing hardware, making them an affordable choice.
Border Gateway Protocol (BGP) Feeds
Do Not Route Or Peer (DROP) and Botnet Controller List (BCL) datafeeds can peer with your existing BGP-capable router.
Domain (DBL), Zero Reputation (ZRD) and Hash blocklists (HBL) enable you to block content in emails, filtering out a higher rate of email-borne threats.
Data for Investigation
Passive DNS and extended datasets give you additional information on internet resources. They provide deeper insights into incidents and possible threats.
DNS Firewall Threat Feeds
A wide range of feeds to apply to your DNS recursive server. Choose the right level of protection for your organization.
Spam (SBL), Policy (PBL), Exploits (XBL) and Auth (AuthBL) blocklists allow you to filter email from IPs associated with spam, botnets, and other threats.
Find out more about us.
Learn more about Spamhaus; who we are, and what we do.
Find a parter
Discover our partners and how they can support you.
Become a partner
Learn about the benefits of being a Spamhaus partner and how to get started.
Discover a wide range of blog posts, case studies and reports.
Spamhaus’ insight into malware, botnet C&Cs, and the domain reputation landscape.
Commonly asked questions about Spamhaus products and processes.
The Blocklist Tester
A tool to help you check if your servers are correctly configured to use Spamhaus DNSBLs.
The Reputation Portal
A tool for ASN owners to get visibility of their IPs’ reputation and proactively manage listings.
Help for the Project's legacy DNSBLs users
Using the Project’s legacy blocklists and suddenly experiencing email issues? This page may be able to help.
In depth information about the technical details and implementation of our products.
Posted by The Spamhaus Team on 29 Jan 2021
There are various comments bandied about with some regularity relating to Domain Name System Blocklists (DNSBLs). So, we thought it was about time to provide some truths when it comes to blocklists and dispel these myths.
The delivery mechanism for DNSBLs has been around for years. However, the threat intelligence within blocklists is continually evolving to reflect current dangers, as are the means by how this data is researched and published.
There is a vast difference between “old and dated” and “tried and tested.” One can’t deny that blocklist data’s delivery mechanism, i.e. via DNS zone, is decades old. In fact, the first DNSBL was created in 1997 by Eric Ziegast, who was working at MAPS with its founder, Paul Vixie.
But, and this is a big BUT, DNSBLs are a light, robust, and convenient real-time delivery mechanism for reputation data relating to IPs, domains, and content. They are continually developing to counter nefarious online activity.
The early days of blocklist creation involved hours of tireless manual research and the use of heuristics. Today, machine learning enables us to process an ever-increasing amount of data, with our researchers still undertaking manual investigations and applying heuristics.
The type of datasets that are produced is also advancing. In addition to IP and domain reputation data, hash blocklists are compiled, enabling specific content such as email addresses, malware files, and cryptowallet addresses to be listed.
By leveraging new tools and technologies, we continue to identify bad actors and bad behavior while limiting the number of false positives. We spend considerable resources advancing our threat hunting capabilities, allowing our customers to place their focus elsewhere.
So, while DNSBLs’ delivery mechanism might be considered “old,” the actual data within is carefully researched using up to the minute technology and techniques to deliver IP, domain, and content reputation data that protects against current threats.
Er, no. DNSBLs can filter all manner of email-borne threats, including phishing links, malware files, bots, and URLs to malware dropper sites. Spam is just the tip of the iceberg.
Firstly, let’s define spam…. Obviously, we don’t mean the trademark name of the famous processed meat product. We are talking about unsolicited emails that are sent in bulk to a large number of recipients.
Most people consider spam to be the umbrella term for the plethora of scummy emails distributed, selling pills, sex, and lists, among other undesirable things.
Email, though, is also a vector for more sinister issues like malware files (94% of which are delivered via email), ransomware, phishing sites….and, so the list goes on. Blocklists can mitigate the risks from these and more.
Emails that have malware files attached can be blocked with the malware component of the afore mentioned Hash Blocklist. This lists cryptographic hashes of malware files. The Spamhaus researchers can list malware files within 20 seconds of initially observing them.
Domain blocklists (DBL) contain lists of domains that are not only associated with sending spam but also those associated with phishing, malware, and botnet command and controllers (C&Cs).
Our eXploits Blocklist (XBL) only lists IP addresses (approximately 13 million of them) that are showing signs of compromise, i.e., machines infected with malware, worms, and Trojans, or third-party exploits such as open proxies or devices controlled by botnets.
You’ll note that there isn’t a single mention of the word ‘spam’ in that litany of internet baddies. Where a machine is compromised, it’s highly likely that further criminal activity will follow, including spewing out emails with malware attachments to all available contacts to further propagate and increase its reach or the download of its log-in and financial credentials.
We could continue, but we figure that we’ve made the point that blocklists filter out a whole lot more than just spam!
The belief that blocklists are purely reactive, i.e., an IP, domain, or hash is only listed once observed to be behaving maliciously, is simply not accurate.
Spamhaus spends a significant amount of time investigating internet environments and resources. Our researchers are continually looking for indicators that suggest a property is about to participate in malicious activity. Here are some examples of where blocklists are proactive in their listings:
Where we observe a hijacked IP range, it is (almost) a dead cert that nefarious activity involving that range will follow. Therefore, we will list the respective IP range(s) to block any potential attack vectors they may emit.
Spamhaus is provided with lists of domains, as and when they are registered, and we proactively investigate their various proprieties. From this analysis, our researchers can score the domain’s reputation, evaluating its likelihood of being used with malicious intent. These are then listed before the domains are used in the wild.
Our Zero Reputation Blocklist (ZRD) lists all newly registered domains for 24 hours. When a new domain is initially registered, it’s improbable that emails will be sent from it immediately, unless it’s being used by bad actors, who register and burn through hundreds and thousands of domains.
The Policy Blocklist (PBL) that Spamhaus supports enables Internet Service Providers (ISPs) to list ranges of IP addresses that should never be sending email directly to the internet. This is an entirely pro-active blocklist.
Spamhaus has reduced latency, so when attacks occur, it takes less than 20 seconds from detection for an IP, domain, or hash to be listed. For large, vicious campaigns, our data may not protect users hit at the initial start of the attack, but in the case of a hailstorm campaign, which runs for up to 5 minutes, 90% of those affected will have protection.
This is far from true in many ways. Having read this far, you will quickly be realizing (if you hadn’t already) that no blocklist is the same. Each has separate listing policies, i.e., the criteria used to decide as to whether something should be listed or not. Similarly, the organizations that research and compile blocklists are not the same. While starting a blocklist is relatively easy, maintaining its consistency is difficult (and crucial).
Given that every blocklist has a different focus, they need to be applied to the right part of an email transaction. For example, using the PBL in deep header parsing would be a recipe for disaster. Follow our best practice to ensure you are implementing them correctly.
Always make sure you understand the functionality of each blocklist you use. Spamhaus, for example, has an “Abused legit” section to the DBL. Here hacked legitimate resources are listed. You can choose whether to ignore or act on the query response relating to this part of the DBL. Be aware that it can potentially increase your risk of false positives. You need to weigh-up your organization’s appetite for risk versus the operational issues relating to an increased number of false positives.
When it comes to blocklists; providers need to be consistent. Each listing needs to adhere to its particular policies, day in, and day out, which isn’t easy to do.
Incorrect! Suppose you use blocklists only during the SMTP transaction. In that case, you miss the opportunity to scrutinize many elements, such as URLs, Reply-To email addresses, files sent as attachments, etc., against reputation data.
While it is true that the SMTP stage alone can block 95% of the spam or more, a fraction of nasty messages carrying threats could still pass through.
No! If you are only using blocklists during content analysis, you are missing a huge opportunity to immediately drop a massive percentage (see that 95% figure above?) of unwanted email at the initial IP connection and during the SMTP transaction before transferring data.
Dropping malicious email before it reaches the expensive content-filtering stage enables you to save on bandwidth, significantly reduce the number of open connections, conserve storage, and benefit from a general reduction in memory and CPU requirements.
Absolutely not! As discussed, Spamhaus lists a number of domains before they’re seen in the wild. Therefore, querying the DBL and ZRD at the appropriate stages of the SMTP transaction provides additional proactive protection.
What myth would you like busted?
That’s enough myth-busting for one day. If you’ve any other myths relating to blocklists and Spamhaus, let us know via Twitter or LinkedIn – we’d be delighted to bust those too.
To ensure our DNSBLs protect your email stream, a simple tool is available called the Blocklist Tester. It’s quick and easy to use; once you have verified an email address associated with your email server, test emails are sent. These emails contain resources listed on our blocklists and should be rejected.
Once the test is complete, a full detailed report is available, and the SMTP exchange of each email sent is available to help you understand where any problems may lie in your configuration.
Spamhaus’ Data Query Service (DQS) is an affordable and effective solution to protect your email infrastructure and users.
Using your existing email protection solution, you will be able to block spam and other related threats including malware, ransomware, and phishing emails.
The service has never failed and utilizes the longest established DNSBLs in the industry.
28 September 2021
There's now a tool to test if your email servers are correctly configured to use the Spamhaus blocklists, called the Blocklist Tester.
27 January 2021
There are multiple benefits to using blocklists, reducing infrastructure costs, and workforce hours to increasing catch rates. However, to get the most from DNSBLs, it's vital to use them at the right points in your email filtering process.
29 September 2020
Grasp the specifics relating to email source code, so you can apply IP and domain threat intelligence to the right place in your email filtering process.