DNSBLs for email filtering – an introduction

By on 12 Nov 2020

Category: Tech matters

Tags: , ,


Blog home

This post is the second of a series that will examine matters associated with running your own email server and email security.

If you choose to manage your own email infrastructure, it’s vital to put email filtering in place. A considerable amount of unwanted email can be dealt with at the Simple Mail Transfer Protocol (SMTP) handshake, followed up with content filtering. At both of these points, you can use Domain Name System Blocklists (DNSBLs).

Here’s a recap on some DNSBL basics to help get you started. For more on the benefits of running your own email server, see Is outsourcing email always the best option?

What’s in a name?

As you read various articles, you’ll see DNSBLs are also referred to as ‘black lists’, ‘blackhole lists’, ‘domain name system blocklists’, (DNSBLs) and ‘real-time blocklists/ blacklists/ blackhole lists’ (RBLs). For the purposes of this blog post we’ll refer to them as ‘DNSBLs’ and also the simplified version as a ‘blocklist’.

Revisiting the basics

A blocklist is a database of IP addresses, domains, or hashes, which are presented in a DNS zone. The blocklist provider will have predefined policies that need to be met for an IP, domain or hash to be listed. Generally, if they are on a blocklist, this means the Internet resources have been observed to either:

  1. Be directly involved in malicious behaviour for example, sending spam, distributing malware, hosting botnets, sending phishing emails or hosting phishing websites and so forth, or
  2. Have a bad reputation associated with them.

How the data is compiled

As touched on above, before curating a DNSBL, the IP and domain reputation provider defines ‘policies’. These policies should be formed in consultation with the broader industry (both senders and receivers), ensuring they are fit for purpose and meet their users’ needs. These policies are then applied to the data.

At a basic level, enormous data sets are analysed by researchers who apply the above policies to the data.

This big data is shared with the blocklist provider by various sources, including hosting companies, Internet Service Providers (ISPs) and Internet governing bodies, to name but a few. In addition to these data sources a blocklist provider will run their own honeypots and spam traps.

Researchers analyse a multitude of data points, via machine learning, manual analyses and heuristics.

Here are some numbers from the Spamhaus Project to understand the volume of data that is processed daily:

  • 3 million domains assessed daily
  • 18,000 malware samples processed
  • 9 billion SMTP connections analysed
  • 100s of heuristics used to identify the good from the bad

How a blocklist works

DNSBLs can be queried in real-time, to check if an email is being sent from an Internet resource that either is or could potentially be malicious.

If the query returns a positive response, the information delivered by a blocklist can be used by the receiving server to:

  • Reject the message in real-time, with an appropriate delivery code.
  • Accept the message but tag it for additional filtering.

It is down to the organization running their own email infrastructure, to define the exact policy of how an email is handled if the query is positive.

A flowchart showing the Spamhaus filtering process
Figure 1 – A policy flowchart for filtering spam.

What Internet resources are listed?

Various blocklists exist, providing multiple layers of protection for email filtering. The three key types of blocklists available are IP, Domain, and Hash blocklists. Within these, you will find subsets focusing on different areas:

IP blocklists — these include IP addresses sending spam or exhibiting signs of being infected with malware.

At Spamhaus, there is also a Policy Blocklist (PBL). This enables ISPs to list dynamic ranges that shouldn’t be sending email. For example, Internet of Things (IoT) devices, such as doorbells, heating controls and so forth, will emit spam if they become infected.

Domain blocklists — these include domains associated with spam, phishing and botnet command and controllers, among many others. There are also lists containing domains that have recently been registered and therefore wouldn’t be expected to be sending email within the first 24 hours. 

Cybercriminals often register domains and instantly send email before the domain has a bad reputation associated with it and becomes listed on a DNSBL. This means blocking newly registered or observed domains can be very effective.

Hash blocklists — these focus on blocking content within your email. A hash blocklist is a list of cryptographic hashes. The hash is associated with malicious content — this could be a cryptowallet address, a malware file, or even an email address.

Now you know the basics, what’s next?

We hope you’ve enjoyed your basic introduction to DNSBLs. In our next post, we’ll be taking you on a deeper dive into how to use blocklists, examining exactly where to apply them to your email infrastructure to ensure high catch rates.

WEBINAR — DNS Blocklist Basics

Register for our upcoming free webinar to learn more about DNS Blocklists, happening on Thursday, 26 November from 16:00 (UTC + 10).

DNSBL experts Carel and Skull will walk you through all the blocklist basics from how they’re compiled, to how they work, and how to use them in your email infrastructure.

Matt Stith is Industry Liaison at Spamhaus.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.


  1. Nicola Selenu

    Great speakers. I won’t miss it!

    however, please note that there’s a wrong date in the yellow box 🙂

    this is the right one:

    Thu, 3rd December
    9.30AM CDT | 10.30am EDT | 2.30pm GMT | 3.30pm CET


Leave a Reply

Your email address will not be published. Required fields are marked *