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 Blocklist Removal Center. From here you will be able to enter your IP or Domain and begin your request for removal.
Please note that the Project’s Blocklist Removal Center 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.
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 Riccardo Alfieri on 29 Sep 2020
When an end-user views an email, it isn't always apparent if it's malicious or not. However, if you look at the email's source code, a wealth of information is revealed. By applying specific DNSBLs (blocklists) to a particular element of this source code, you can filter email with great success. But, before we discuss blocklists, you need to understand the anatomy of an email...
Let’s put some context around the difference between the information that an end-user sees when viewing a malicious email and the actual data contained within the source code. Firstly, take a look at the email below:
Above is a typical example of how a spam email displays via end-user client software, such as Apple Mail or Outlook.
In the rendering of this email, some elements of the email content may start to ring some warning bells, i.e., an HTML link, a bitcoin address and an attachment. Unfortunately, to a casual user, these elements will probably seem benign.
This is exactly what cybercriminals are counting on. They want to exploit how an email appears to the average end-user, keeping elements hidden that could point to the potentially dangerous nature of the email.
To see what an email really contains, we have to unpack it and look at the “source code” or “raw code,” viewing the email header and email content.
Take a deep breath – there is a considerable amount of information contained within email source code. However, we will explain it all, hopefully without boring you to death (or at least that’s the plan!)
Below is the same email as pictured above, only in “raw” format. It illustrates what information is seen and recorded by internet servers as they send and deliver email messages.
The “Return-Path” is also known as the “Envelope-From.” This is the “actual” email address that sent the email.
In terms of old-fashioned snail-mail, the “Return-Path” is similar to a local postal services stamp, i.e., it is an accurate indicator of the letter’s origin. However, when you’re reading the actual contents of the letter, you can’t see the postal services stamp on the envelope.
In the case of email, you can’t see the sender’s real email address in the visual rendering of an email, as illustrated in figure 1.
This is also commonly referred to as the “Friendly From.” The sender-address is comparable to the signature of the person who signs a letter you’ve received through the post, i.e., they can sign it from anyone.
In our example, the “Return-Path / Envelope-From” (#1) is different from the “Sender-Address (From)” (#7), aka “Friendly-From.” The Friendly-From name, which is visible to an end-user, is how the sender wants to appear to the recipient. Typically, it includes the sender’s name and email address.
That’s simple – to trick people! Bad actors want the recipient of the email to believe it’s from someone credible, important, or someone who is known to them. They are trying to add legitimacy and believability.
Remember! In most cases, email client software only shows the Friendly-From. It’s like opening a letter and throwing away the envelope before handing it to someone to read; they only see the writing on the actual letter.
Think of the “Received” chain as a paper trail of all the servers that have handled your email, including your mail server. The reading order is “final connection/most recent” at the top, and the preceding connections are listed in reverse order, culminating with the “originating computer/oldest” at the bottom.
These are vital elements because they include all the IP addresses of the email servers that have handled your email and information like the HELO string and reverse DNS (rDNS) of the IPs.
“HELO“ is a required element in a Simple Mail Transfer Protocol (SMTP) transaction. It is similar to the greeting that a postman might give to a colleague when handling over postal mail: “Hello, I am John from The Postal Service, and I have mail for someone on your route.”
Let’s take a deeper dive into our example email’s received chain, starting at the top and reading down:
This is the most recent and most trusted “Received” line because the recipient’s mail server has registered it; therefore, it’s guaranteed not to have been tampered with.
In an attempt to confuse anti-spam systems, miscreants will sometimes try to scramble the “Received” line chain. With this in mind, you should pay particular attention to the subsequent “Received Lines” following on from this most trusted one.
The key elements in Line C are:
Explanation: the sending mail server “mta-out.someisp.example” (#2) makes a connection to the recipient’s mail server “mx.email.example”, announcing itself via HELO with the IP “22.214.171.124″ (#4) and the rDNS of “mta-out.someisp.example” (#3). This is the final connection – if it is accepted (and in this case it was), then the email addressed to <[email protected]> is delivered.
Received Chain B:
This is where “smtp.someisp.example” acknowledges receipt of the email for the destination email address <[email protected]>.
Explanation: the mail server “smtp.someisp.example” connects to the outbound (Postfix) mail server “mta-out.someisp.example” for that ISP, telling the outbound that it has mail to be sent to <[email protected]>.
This line represents the original email transaction that generated the email. Since this is the initial transaction, the pertinent detail here is the connecting IP.
The key elements in Line A are:
Explanation: the originating local machine, “192.168.1.2″, makes an outgoing connection to “smtp.someisp.example” and announces itself as “192.0.2.1″. Upon connection, the server “smtp.someisp.example” tries to look up the rDNS of the connecting IP, “192.0.2.1″ (#5), and fails, returning in an “unknown” result.
Upon clicking “Reply” to an email, this field serves to instruct your email client software regarding what email address to insert in the “To” field. Usually, with legitimate emails, the “Reply-to” and “From” in the original email will be the same.
Our email example shows that the apparent sender is “[email protected],” but if you were to reply to this email, the address would populate as “[email protected]”… and the bad actors are hoping you won’t notice that.
The end-user has no visibility of the website address (URL) in the email they are viewing. This is because the sender has concealed the URL with a hyperlink associated with “click here.” The actual website URL is “www.worldlotterywinner.example” .
To see where a link will take you, hover over the link, and the details of the URL will display. In many cases, the URLs included in malicious emails will be directing you to a “spamvertised” product, a phishing website, something unsavory, or a malware dropper site.
A Bitcoin “wallet” is a crypto-address controlled by cybercriminals, often used as an avenue for payment in sextortion spam campaigns. These are campaigns where the bad actor claims to have recorded the victim indulging in some “private activities.” They threaten to share the recording with work, family, and friends unless the cybercriminal receives payment via the bitcoin wallet.
There are many variations on this theme, playing on people’s fears with the sole intent of extorting money.
In this example, the attachment is an Office document called “Further instructions.doc.” More than likely, it will be ‘weaponized’ in some shape or form. By this, we mean that if you were to download and open the document, malware would infect your computer. The cybercriminal can then use your computer for whatever purpose they want. This can include sending more spam, exfiltrating your personal data/passwords, or utilizing your computer in a distributed denial-of-service (DDoS) attack.
Congratulations – you made it through! We hope this deep dive into email source code helps provide some clarity.
With so many email elements to check, it can become confusing as to what blocklist to use at what point in the email filtering process. Take a look at this article to understand what Spamhaus blocklists to use and where to use them to maximize your catch rates.
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.
6 October 2020
Data Query Service enables email provider, Universo Online (UOL) to protect millions of users from spam and other malicious email threats while freeing-up 20% of the team’s time resources.
29 September 2020
Spamhaus produces many different DNSBLs (blocklists). The question is which ones to apply where? This simple guide provides you with all the information you need.
18 May 2020
It's a well-known fact that filtering emails using IP blocklists (DNSBLs) blocks the vast majority of malicious emails. It's effective and economical, using minimal computational power. So why should you also use domain and hash blocklists for filtering?