Frequently Asked Questions relating to Spamhaus data

The Spamhaus Domain Blocklist (DBL) is a list of domain names with poor reputation. It is published in a domain DNSBL format. These domain reputations are calculated from many factors and maintained in a database, which in turn feeds the DBL zone itself.

• It ONLY lists domains. No IP addresses are listed in the DBL.
• A dedicated team of specialists maintain the DBL’s reputation database.
• Data from many sources is used to build and maintain a large set of rules.
• The DBL zone is continually updated, and the data is served from over 80 mirrors world-wide.
• These rules control an automated system that constantly analyses a large portion of the world’s email flow and its domains.
• Most DBL listings occur automatically, although where necessary, Spamhaus researchers will add or remove listings manually.
• Listings will expire without intervention after the domain stops matching the criteria that caused the listing.

DBL data is exchanged with other Spamhaus systems, resulting in further listings in the DBL or in IP addresses being listed in other Spamhaus zones.

The Spamhaus Domain Block List (DBL) evaluates many factors for inclusion of domains. We do not discuss the specific criteria we use.

• Domains must match several criteria in order to be listed.
• We will not reveal specific listing criteria in most cases.
• DBL listings are constantly reevaluated by our systems, and listings do expire automatically when listing criteria are no longer met.

These are general observations to help domains build a good reputation and avoid DBL listings.

NOTE: These observations are universal and do not apply only to the Spamhaus reputation systems.

Domain reputation

• Reputations are built over time, and building a good reputation takes longer than building a bad reputation.
• Experience has shown that an unknown reputation has a much higher risk of emitting spam than known-good domains, so unknown reputations begin as “poor” by default.
• Anonymity does not contribute to a good reputation.
• Domain and IP address reputations affect each other.
• If domains are used in legitimate traffic for enough time to establish a good reputation, DBL will notice that and remove the listing.
  • The DBL will notice if domains are used for activities that cause poor reputations, such as spam, cybercrime or other “blackhat” pursuits.

Snowshoe spamming

• This is a technique that uses many domains and IP addresses, which change frequently.
• Legitimate bulk email builds a reputation over time on durable, long-term domains and IP addresses.
• Because of that investment in time and effort, reputable mailers don’t use nearly as many domains, and fewer IP addresses, than snowshoers.
• Domains which act like they are snowshoeing will get treated like snowshoers.

Authentication

• Having solid domain authentication is a necessary tool in today’s email ecosystem, but SPF, DKIM, and/or DMARC can all be used by spammers as well as by good senders.
• DBL listings occur for domains with and without those records.

Bulk email/Marketing email

• If a domain is being used in bulk email, be sure best practices are followed for sending only confirmed opt-in, solicited bulk mail.
• See our Marketing FAQs for more information.
• It can also help to consult industry experts or good deliverability consultants for further assistance.

Role Accounts and Feedback Loops

• These are a domain’s abuse detection system.
• If they are not set up and functional, there is a huge loss of visibility into abuse issues on a network.
• They should be used to identify problems including spam, and to stop those problems before they degrade a domain’s reputation.

Clean hosting

• Domains should be hosted on good, clean ISPs which do not allow abuse of their network.
• “Clean” includes a domain’s NS, A, MX and website DNS records.
• Hosting a domain on spam-friendly IPs or servers, or at ISPs that tolerate network abuse, including spam, has a negative effect on the reputation of all domains on that network.
• Mail server IPs should be identified with proper rDNS (PTR records) and mail servers should identify themselves with a proper HELO value (also RFC 5321 4.1.1.1).

Does a DBL listing expire automatically?

• DBL is highly automated and most listings will expire automatically after they cease to have associated activity.
• Domains are listed in DBL Zone automatically, and they may re-list automatically after removal if they are re-detected.

Can a domain be removed from the DBL before the expiry?

• While DBL is careful to not list innocent domains, it’s possible that a domain may need to be removed from DBL before the listing expires.
• If a domain is listed and believed to be eligible for removal, please use the IP and Domain Reputation Checker link on the Spamhaus homepage. Look up the domain and follow the instructions returned by that lookup form.
  • Using the form does not guarantee removal.
  • Excessive removers and other removal form abusers may be blocked.

How long does a removal take?

• Once the removal request is approved, the request will be processed immediately.
• It should only take a few minutes, but some users may lag up to 24 hours in removing domains from their local systems.
• If the listing remains active after 24 hours after the removal is approved, please contact us.

Is there a cost or fee for removal from the DBL?

• Absolutely not.
• There is never any charge or fee associated with removing any Spamhaus listing.
• Any offer from anyone to remove any Spamhaus listing for a fee is a scam.
• Spamhaus has no affiliation with anyone offering any ‘blocklist removal’ service, nor can any third party influence or expedite removals from any Spamhaus database.

We don’t scan at all.

Scanning is not a very effective way to detect many of these hacks. We watch Internet traffic for signs of abuse, spam and botnet traffic. When we see those signs it means for certain that the website or server is insecure, infected or compromised.

“Abused-legit” is a component of the Domain blocklist (DBL) detailing hostnames on domains that are legitimate, but are being abused for malicious purposes. This is often the result of a compromise, usually of software on a website (CMS) or of the credentials providing access to the hosting infrastructure.

Listings occur because Spamhaus has identified a legitimate website that is compromised.

Hostnames are used in the listing to avoid listing an entire domain that may be serving other legitimate content. The reason for compromise can be linked to several issues, including; outdated software, substandard security, or fraudulent access.

Search, review and request removal of “abused legit” hostnames via the IP and Domain Reputation Checker.

If your hostname/domain is listed, we recommend you follow these basic steps:

1. Take the website/server offline while it is being fixed, if possible.
2. Remove all infected files.
3. Update the content management system (CMS), and all plugins and extensions to the latest and most secure versions.
4. Ensure the server itself is secure, or ask a system administrator to perform a security audit.
5. Change all passwords. Strong passwords should be used, and where possible, two-factor authentication also.

For more in-depth information, please refer to our FAQs regarding hacked CMS:

• Hacked Website or CMS – General Information
• CMS-Specific help

Domain Blocklist listings include only the hostnames, not the full directory path of URL/URIs.

However, in some cases, additional DBL information may be available for admins of hacked CMS sites. Start the removal procedure from our IP and Domain Reputation Checker and follow the steps from there.

We suggest that all domains, especially redirector domains, be set up with appropriate and RFC required role accounts (abuse@ & postmaster@, etc.) ISP feedback loops, and other reporting such as DMARC notifications for email. These can help provide notification of problems.

The DBL uses DNS return codes in the 127.0.1.0/24 range. Queries regarding any domain listed in DBL and all IP queries will return a response code. If no code is returned (NXDOMAIN) the domain is not listed in DBL.

DBL return codes in current and future use are:

This table will be updated as specific DBL categories are added and 127.0.1.* return codes are assigned to them.

The following special codes indicate an error condition and should not be taken to imply that the queried domain is “listed”:

Spamhaus Zen is an IP address DNSBL zone. Zen lists numeric IP address zones only, it does not list domains and does not include the DBL.

The DBL is a purely domain-based zone, and must be queried separately by software capable of extracting domains from email message bodies and headers.

No. The DBL cannot be used to look IP addresses.

The DBL is a domain-only blocklist and does not include or support IP addresses.

• It only includes domain names in the form of text strings.
• It should not be used the same way as the Spamhaus IP-based DNSBLs.
• An IP query against the DBL always returns a positive (listed) return code.
  • If legitimate emails containing http links specified as IP addresses (e.g. “http://1.1.1.1”), are expected to be delivered, wrongly using DBL this way will reject them.

“dbl.spamhaus.org” must not be configured in any email server’s “DNSBL” or “RBLs” feature, spam firewall, or spam filter unless it specifically states that blocklists entered there are used for domain checking only. If this is unclear, please refer to the spam filter developer.

Spamhaus DNS returns the code 127.0.1.255 to IP queries to the DBL zone, along with a TXT record referring to this FAQ page.

If an IP lookup DNSBL is required, Spamhaus Zen is a good choice. More information can be found on the DNSBL FAQ page.

The DBL can be used with a Response Policy Zone (RPZ).

Also known as a “DNS firewall,” an RPZ is highly effective at protecting networks and their users from spam as well as malware of many kinds including bots, spyware and other malicious attack vectors.

Our partner, Spamhaus Techncology, produces RPZs from our Domain datasets. For more information see their DNS Firewall service.

Unfortunately Microsoft does not include native support for DBL or other domain blocking lists in their Exchange product. However, Exchange users can use DBL through a third party product such as Vamsoft ORF.

The Spamhaus DBL can be effective when used to defend against blog spam.

• Many of the same actors that send spam email also spam blog comment sections and guestbooks.
• Most blogging software does a good job in catching comment spam, but if needed, the DBL is able to detect some of the domains used, and can flag or block these postings.

The DBL supports wildcard lookups. Querying the full hostname will return a positive result if the host’s domain is listed. In other words, DBL lists at the main domain level, and all hostnames and subdomains of that domain also return a “listed” result. Therefore, it is optional and not necessary to strip the hostname down to query the actual domain only.

For example, if example.tld is listed:

$ host example.tld.dbl.spamhaus.org

example.tld.dbl.spamhaus.org has address 127.0.1.2

Any  wildcard: “*.example.tld” sub-domain will also get the same response:

$ host www.bank.phish.tld.dbl.spamhaus.org

www.bank.phish.tld.dbl.spamhaus.org has address 127.0.1.2

The wildcard query works for subdomains only, and not variations of the domain itself:

$ host example.tld.dbl.spamhaus.org

example.tld.dbl.spamhaus.org not found: 3(NXDOMAIN)

This enables the DBL to be used for either URI type queries (domains in links advertised in spam) and RHSBL type queries such as rDNS, HELO string, FROM and other email headers.

Yes, it can be used to protect URL shorteners from abuse.

• Spammers frequently use URL shortening services to try and avoid spam filtering systems that use tools such as the DBL.
• URL shortening services should check every URL’s domain against the DBL and not allow those that are listed.

• Don’t string several shorteners/redirectors together!

  • This includes ‘Don’t shorten other shorteners’ and ‘Don’t accept referrals from other shorteners.’
  • DBL has a specific return code for abused shorteners/redirectors in the DBL zone: 127.0.1.103.
  • For more in-depth information, see our blog article Changes in Spamhaus DBL DNSBL return codes.

• Don’t redirect to domains with the ‘A’ Record on the SBL (and possibly the XBL – your decision).

• Check blocklists at the time of URL creation and again, later, as traffic on the new URL ramps up (a day or a week’s time later).

• Don’t allow users to change the landing URL after the redirect is created.

• Don’t provide an interstitial link to the spammer’s payload if abuse is detected: Fully suspend the offending URL (404 or 410 HTTP return).

• Code a system to prevent automated URL creation (using good CAPTCHA or other bot-stopping tools).

• If you have access to the Spamhaus ZRD product, consider not creating URLs for brand new domains with no reputation.

• Do create and maintain role accounts & feedback loops (FBLs) to help detect abuse, and process that information promptly.

• The ISP Spam Issues FAQ can provide more tips on dealing with abuse of Internet resources in general, especially “Role Accounts & Feedback Loops”.

• Also see this article from SURBL about the issue for additional points of view and information.

We have seen that people have published code to do DNS lookups on the DBL.

One example is here.

This Python code was written for checking SURBL and could be modified to work with the DBL.

There are two ways to test the DBL.

1. The DBL follows RFC5782 for determining whether a URI zone is operational with an entry for TEST.
2. The DBL has a specific domain for testing DBL applications: dbltest.com.
   • To test functionality of the DBL, use “host” or “dig” from the command line to do a manual query.
   • If using the web to look up a domain in the DBL, the domain lookup form at our Blocklist Removal Center should be used.

NOTE: Do not query our website with automated tools!

RFC5782 operational test

Query: test.dbl.spamhaus.org

Result: test.dbl.spamhaus.org IN A 127.0.1.2

“Listed” Test Results

Query: dbltest.com.dbl.spamhaus.org

Result: dbltest.com.dbl.spamhaus.org IN A 127.0.1.2

“Not Listed” Test Results

Query: example.com.dbl.spamhaus.org

Result: Host example.com.dbl.spamhaus.org not found: 3(NXDOMAIN)

(Note: the IANA reserved “example.com” domain will never appear in the DBL zone)

Test Point TXT Record

Query: TXT dbltest.com.dbl.spamhaus.org

Result: TXT "https://check.spamhaus.org/query/domain/dbltest.com"

We have developed our datasets with the final goal of being the most compatible with existing software. The two biggest open source antispam projects are SpamAssassin and Rspamd.

To show the best way to use our data with these products, we have created two dedicated Github projects. The projects contain instructions, rulesets, and code to make the best out of our DQS product.

• SpamAssassin-DQS
• Rspamd-DQS

The DBL is not listing twitter.com, facebook.com, pinterest.com or other social network domains.

Network traffic entering or exiting China can be altered if it contains particular keywords or domains.

• This is due to the policy set by the Golden Shield Project which is operated by the Chinese Ministry of Public Security (MPS) division.
• The interference of the Chinese government’s system has the following consequences for the DBL:
  • Spamhaus has servers located in China, to better serve our Chinese customers, but the DBL is not available on those servers. They are only used to answers queries relative to IP addresses (SBL, PBL, XBL).
  • Spamhaus users in China will get all DBL answers from servers located outside China, and it is possible the answers will be altered as described above.
  • It is therefore very important that all users in China validate our responses by having their software check that the A record is a valid one in the range 127.0.1.0-127.0.1.255.
  • Any other code is a result of the actions of the Golden Shield Project and the queried domain is not listed by DBL.