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.
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)
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 [beta]
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 out who we work with and how you can become a Spamhaus Partner.
Discover a wide range of blog posts, case studies and reports.
Commonly asked questions about Spamhaus products and processes.
In depth information about the technical details and implementation of our products.
Posted by The Spamhaus Engineers on 27 Jan 2021
Domain Name System Blocklists (DNSBLs) are a low-cost and effective way of stopping the torrent of inbound email traffic associated with spam and other malicious emails. 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.
There’s a wide range of email security options for your infrastructure, from content filtering and scanning to network-based tools that use distributed and collaborative methods.
Unfortunately, the majority of the above are resource-heavy and expensive. The key to email filtering is to remove the bulk of unwanted emails right at the beginning of the process before they reach the resource-intensive content inspection stage.
A DNSBL check is the simplest, quickest, and most economical method you have at your disposal….so why not use it?
When you accept and process an email, there are three areas that you should use blocklists:
At the very beginning of an email transaction, a remote server attempts to initiate a connection with your server. At this point, a quick lookup (query) to a blocklist can instantly (well, almost instantly) advise if the connecting IP address is associated with malicious behavior or not.
If the IP address is listed, you can choose to drop the connection immediately. Remember, this query is undertaken even before the Simple Mail Transfer Protocol (SMTP) handshake occurs.
For all email commands that occur after the initial email connection set-up (as detailed above) and before the DATA command during the SMTP connection, we term as the pre-data phase.
Once the connection is open, you (the receiver) should do a reverse DNS lookup of the connecting IP address.
The result of the above lookup should be queried against the domain contained in the HELO from the sender, e.g. (HELO mta-out.someisp.example). If they do not match, the connection should be dropped immediately. This is an indication that the sender isn’t who they say they are e.g. spoofing.
The domain returned should be queried against the DBL and the ZRD.
The domain contained in the HELO should be queried against the DBL and the ZRD, alongside running a forward DNS lookup against the SBL.
Subsequent to the HELO, during the SMTP connection, is the MAIL FROM command. This is often referred to as the “Envelope-from” or the “Return-path.” You should query the domain included in this string, e.g., <[email protected]>
Whenever a query is made against the DBL and ZRD and a positive response is returned, receivers can reject the email or tag it for further inspection during the content filtering process.
Once the RCPT TO command has been completed, the DATA command follows, and it is this that initiates the transfer of data, both the email header and content. After the receiver confirms this has been successfully executed, the sender transmits a QUIT command, either before or after content inspection, and the connection is closed.
This comes down to both your implementation decisions and software choices. As with all options there are pros and cons for both:
Some implementations choose to keep the connection open, until they have the result of the content inspection.
Pros: Senders will always be notified of a rejection, which is the best strategy should false positives occur.
Cons: This is resource heavy and your MTA must be up to the task, even during peaks. Where resources are not sufficient delays may occur.
The majority of implementations close the connection before content inspection.
Pros: Lowers costs due to lower resource requirements.
Cons: Where false positives have occurred, the sender will not be notified.
As previously mentioned, content filtering and scanning are resource heavy. Reducing the number of emails that reach this point of the email filtering process saves on memory, reduces processing power and reduces latency.
Consider a situation where you receive hundreds of messages per second during a sustained or escalating spam campaign. If you are reliant on content filtering or scanning to mitigate the attack, your email infrastructure has the potential to collapse under the load put on it by the sheer volume of inbound emails.
If you’re lucky enough for this not to happen, you will still incur high costs, as every email needs to be downloaded and scanned.
When an email is rejected at the initial connection or SMTP handshake, a Delivery Status Notification (DSN) is returned in real-time to the sender, advising them of the failed delivery. From a sender’s perspective, this can help with identifying and resolving mail relay problems.
As a result of emails being rejected early on in the email transaction, potentially spammy emails aren’t downloaded and left, forgotten in a junk folder. This stops end-users from hunting through their junk folder to find one legitimate email out of hundreds, if not thousands of spam ones.
If the sender address is forged, the innocent third party whose email was used in the forged sender address will be flooded with return messages.
Using domain blocklists as well as IP blocklists provides you with extra protection against hailstorm and snowshoe spam, in addition to other threats. For a deeper understanding of this subject matter, we suggest you read MTA developers: allow use of domain DNSBLs at the SMTP level.
It’s worth remembering that our domain blocklist will contain many domains before they’re seen in the wild!
Once the DATA command has run and the email header and content have transmitted to the receiver, content inspection commences, alongside running SPF, DKIM, and DMARC checks.
Email headers contain structured data making them far less resource-intensive to parse compared to that of the body of an email. To get a deeper understanding of an email header and body components, read Understanding the source code of a malicious email.
Here’s where blocklists can be used during the header inspection:
This is the IP address contained within the original transaction’s received chain, i.e., what initially generated the email. This lookup can be done against the SBL and AUTH BL. An rDNS lookup can also be done against the DBL & ZRD.
The full email address in this field should be queried against the Hash Blocklist (HBL), which contains cryptographic hashes of email addresses.
Commonly referred to as the “Friendly From” address, it should be queried against the HBL, and the domain contained in it should be queried against the DBL & ZRD, with a forward DNS lookup against the SBL.
Finally, we’re onto the inspection of the content (scroll up to think of all the opportunities you have had to reject email before it reaches this more expensive part of the email filtering process!)
Website URLs or emails in the body content should all be queried against the DBL, ZRD, with a forward DNS lookup against the SBL. Emails contained within the email body can also be queried against the HBL.
Query these against the HBL, which has a cryptowallet section containing hashes of bitcoin and other cryptocurrency addresses.
All attachments should be queried against the HBL, which lists malware files, in addition to email addresses and cryptocurrency addresses.
Sadly, with so many variances it’s not possible to cover all the specific operational details for different mail systems. Where some of our checks can’t be implemented, we recommend reaching out to the support desk of the product you are using.
The good news is that we do have two plugins for opensource filters, SpamAssassin and Rspamd, for both pre-data (SMTP) filtering and content analysis. Also here’s the full outline of what blocklists to apply where.
If you’d like to trial DNS Blocklists and run your own email server – then sign up to access the data free for 30 days. We’d love to hear how you get on.
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.
29 January 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.
11 November 2020
Here are 11 ways to help email administrators make running their own email infrastructure a success.
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.