How does Spamhaus decide whether to list a subdomain or a whole domain on the DBL?
Updated on 27 Jul 2026: We corrected how Spamhaus DBL scope works, added return-code guidance, and tightened the investigation and removal steps.
Spamhaus documents two relevant DBL behaviors. Ordinary DBL entries are made at the main-domain level, so hostnames beneath a listed domain also return a positive result through wildcard matching. The abused-legit component is the important exception: Spamhaus can list the specific hostname of a compromised legitimate site to avoid blocking unrelated content on the rest of the domain.
Spamhaus does not publish the exact criteria used to choose or classify every entry. The Spamhaus DBL includes domains associated with spam, phishing, malware, botnet command-and-control activity, abused legitimate sites, and abused redirectors.
- Main domain: This is the documented scope for ordinary DBL entries.
- Abused-legit hostname: A compromised hostname can be listed without listing the entire legitimate domain.
- Wildcard result: A hostname lookup can return listed because its parent domain is listed.
- Response code: The DNS answer identifies the DBL category or an error condition.
The direct answer
For a normal DBL entry, expect the registered or main domain to be the listed unit and its subdomains to match through wildcard behavior. For a legitimate site compromised at one hostname, expect the abused-legit component to support a narrower hostname entry. Spamhaus's DBL FAQ says domains must match several undisclosed criteria, listings are constantly reevaluated, and most listings expire automatically after the triggering activity stops.
Treat a DBL result as a scope and category question first. Check the exact hostname, the parent domain, and the DNS return code. Then identify where that name appears, such as the message body, envelope sender, HELO, rDNS, click tracking, image host, or visible sender identity.
|
|
|
|---|---|---|
Hostname only | Abused-legit entry | Return code |
Parent domain | Main-domain entry | All domain uses |
Host and parent | Possible wildcard match | Compare answers |
127.255.255.x | Query error | DNS access method |
Common DBL results and what they indicate.
The DNS label alone does not reveal whether the hostname has its own record or inherits a listed result from its parent. A blocklist or blacklist hit on a tracking hostname still needs a parent-domain lookup and a review of the response code. Mailbox filters can also combine DBL data with authentication, content, engagement, and prior reputation.
Spamhaus Reputation Checker screen showing a DBL lookup result for a domain.
When a hostname is listed
The clearest case for a narrow listing is the abused-legit component. Spamhaus put hostname-level data for this DBL component into production on February 1, 2022. If one user hostname on a large legitimate platform is compromised, listing only that hostname reduces collateral blocking.
The hostname update explains that hostname listings target compromised legitimate sites more precisely, especially where unrelated sites share one second-level domain. Spamhaus attributes these compromises to causes such as outdated software, weak security, or unauthorized access.
Abused-legit hostname
- Legitimate parent: The wider domain has legitimate content or many unrelated users.
- Compromised host: Spamhaus identifies abuse on one hostname.
- Fix path: Remove the compromise and secure the site or hosting account.
Main-domain entry
- Domain classification: The entry belongs to an ordinary DBL category.
- Wildcard effect: Queries for hostnames beneath the domain also return listed.
- Fix path: Review every mail, web, DNS, and redirect use of the domain.
Separating mail streams onto subdomains still helps with ownership and diagnosis, but it does not guarantee DBL isolation. An ordinary parent-domain entry makes descendant hostnames return listed. The same operational caution applies to subdomain reputation in mailbox filtering.
Rule for sending subdomains
Use subdomains to make ownership, monitoring, and incident response clearer. Do not use disposable hostnames to escape a poor reputation pattern.
Why the whole domain gets listed
Spamhaus says ordinary DBL data lists at the main-domain level. It does not publish a formula that maps a specific observation to that scope. Its public guidance does say that domains must match several criteria and that reputation depends on observed use over time, connected IP reputation, hosting quality, DNS configuration, and abuse activity.
- Unknown reputation: Spamhaus says an unknown domain begins with poor reputation because unknown domains carry greater abuse risk.
- Abusive activity: Spam, phishing, malware, botnet activity, and redirector abuse can produce DBL categories.
- Hosting and DNS: Spamhaus advises keeping NS, A, MX, website hosting, rDNS, and HELO data clean and correct.
- Connected reputation: Domain and IP reputation can affect each other.
- Automated or manual action: Most entries are automated, but Spamhaus researchers can add or remove entries manually.
How to treat DBL scope
A practical severity model for deciding how wide the investigation should be.
Exact hostname only
Focused
Check for an abused-legit code and inspect that host for compromise.
Marketing hostname
Elevated
Review the parent result, list source, URL chain, and recent campaigns.
Parent domain
High
Treat the event as a domain-wide reputation incident.
Relisted domain
Critical
The triggering activity continued or returned after removal.
Do not reduce a DBL entry to one complaint metric or one spam trap. The public criteria are not that simple. List acquisition, affiliate traffic, compromised web content, redirector abuse, connected infrastructure, or a URL reputation issue can matter even when the reported complaint rate looks low.
How DBL lookups can confuse the answer
DBL supports wildcard lookups for main-domain entries. If example.com is listed, a lookup for mail.example.com can return the same positive answer. That does not prove Spamhaus created a separate record for mail.example.com. The parent entry can produce the hostname result.
DBL lookup examplesBASH
dig +short example.com.dbl.spamhaus.org A dig +short mail.example.com.dbl.spamhaus.org A dig +short click.mail.example.com.dbl.spamhaus.org A
Test the exact hostname and the parent domain separately, then compare both response codes. If the parent and every hostname return the same listed code, wildcard behavior is the likely explanation. If only one hostname returns an abused-legit code, investigate that hostname as the narrower entry.
Do not query DBL like an IP blacklist
DBL contains domains and hostnames, not IP addresses. An IP query returns 127.0.1.255, which means IP queries are prohibited. It is not evidence that the IP is on the DBL blacklist.
How to read a DBL return code
A positive DNS answer is useful only when its code is interpreted. DBL listing codes use 127.0.1.0/24. No answer, returned as NXDOMAIN, means the queried domain is not listed. Codes in 127.255.255.0/24 describe query errors and must not be treated as listings.
|
|
|
|---|---|---|
127.0.1.2 | Spam domain | Ordinary DBL |
127.0.1.4 | Phishing domain | Ordinary DBL |
127.0.1.5 | Malware domain | Ordinary DBL |
127.0.1.6 | Botnet C&C domain | Ordinary DBL |
127.0.1.102 | Abused-legit spam | Hostname clue |
127.0.1.103 | Abused redirector | Redirector review |
127.0.1.104-106 | Abused-legit threat | Hostname clue |
Current DBL categories most relevant to domain and hostname scope.
Error codes are not listings
- 127.255.255.252: The DNSBL zone name contains a typing error.
- 127.255.255.254: The query came through an unsupported public resolver.
- 127.255.255.255: The query source exceeded the permitted volume.
For an individual incident, confirm the result in Spamhaus's Reputation Checker and follow the instructions returned for the domain. This avoids diagnosing a resolver error as a real blocklist or blacklist entry.
How to investigate the scope
Start with the queried label and work outward. A blocklist basics review helps if the distinction between a DNSBL, domain blocklist, blacklist, and URL list is unclear. For a broader technical check, the domain health checker can expose related DNS and authentication problems.
- Confirm the result: Use the Spamhaus Reputation Checker and record the listing guidance.
- Compare scope: Query the exact hostname and parent domain, then interpret the response codes.
- Inspect mail: Review the envelope sender, DKIM d= domain, HELO, rDNS, links, images, and redirects.
- Audit acquisition: Find purchased data, scraped addresses, inactive recipients, weak consent paths, and abusive affiliates.
- Review web assets: Check CMS updates, plugins, injected files, redirectors, upload paths, and user-generated pages.
- Fix before removal: Stop the triggering activity before requesting removal or waiting for automatic expiry.
Blocklist checker
Check your domain or IP against 144 blocklists.
Spamhaus
0Spam
Cisco
NoSolicitado
URIBL
abuse.ro
ALPHANET
Anonmails
Ascams
BLOCKEDSERVERS
Calivent Networks
EFnet
JustSpam
Kempt.net
NordSpam
RV-SOFT Technology
Scientific Spam
Spamikaze
SpamRATS
SPFBL
Suomispam
System 5 Hosting
Team Cymru
Validity
www.blocklist.de Fail2Ban-Reporting Service
ZapBL
2stepback.dk
Fayntic Services
ORB UK
technoirc.org
TechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftSpamhaus0SpamCiscoNoSolicitadoURIBLabuse.roALPHANETAnonmailsAscamsBLOCKEDSERVERSCalivent NetworksEFnetJustSpamKempt.netNordSpamRV-SOFT TechnologyScientific SpamSpamikazeSpamRATSSPFBLSuomispamSystem 5 HostingTeam CymruValiditywww.blocklist.de Fail2Ban-Reporting ServiceZapBL2stepback.dkFayntic ServicesORB UKtechnoirc.orgTechTheftIf the entry appears only on a click or image hostname with an abused-legit code, focus on that host, its software, credentials, and recent URL chains. If the parent domain returns an ordinary DBL code, widen the review to every mail stream and web property using the domain. More detail on DBL categories and remediation is available in the Spamhaus DBL guide.
Removal and expiry
Most DBL entries expire automatically after the associated activity stops. An eligible domain can also follow the removal instructions in the Reputation Checker. Removal is free, does not guarantee approval, and a domain can relist automatically if Spamhaus detects the activity again.
How Suped fits into the workflow
Suped's product covers the monitoring and investigation side of a DBL incident. It places DMARC data, authentication results, sending sources, domain changes, and blocklist monitoring in one workflow, so the team can connect an alert to recent domain use.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
The practical workflow is to identify the affected domain, compare it with verified and unverified senders, inspect authentication changes, and assign remediation. That context helps separate a compromised web hostname from a broader sending-domain problem.
Where Suped helps
- Listing alerts: Notifications reduce the delay between detection and investigation.
- Source context: Verified and unverified sending sources can be separated during an incident.
- Authentication context: DMARC, SPF, and DKIM results show which sources used the affected domain.
- Multi-domain review: Teams and MSPs can track incidents across client domains without separate spreadsheets.
Suped does not decide Spamhaus entries or force DBL removal. Its role is to provide an incident queue, authentication evidence, sending-source context, and ongoing checks after an entry clears.
How to reduce listing risk
Reduce DBL risk by building stable legitimate use and removing abuse quickly. Spamhaus specifically points to reputation over time, functional abuse reporting, clean hosting, correct DNS, proper rDNS, and a valid HELO. Authentication adds visibility but does not prove that mail is wanted or that linked websites are secure.
- Use stable domains: Avoid rotating new domains or disposable subdomains for ordinary email.
- Separate streams: Give transactional, lifecycle, marketing, and affiliate traffic clear ownership.
- Secure web systems: Patch CMS software and plugins, remove injected redirects, limit upload abuse, and protect credentials.
- Maintain role accounts: Keep abuse@ and postmaster@ working, and process feedback-loop reports.
- Monitor authentication: Use SPF, DKIM, and DMARC to expose spoofing and broken sending sources.
- Investigate relists: A repeated DBL entry means the triggering activity continued or returned.
Basic DMARC TXT valueDNS
v=DMARC1; p=none; rua=mailto:dmarc@example.com
SPF, DKIM, and DMARC prove identity or publish policy. They do not prove consent, website integrity, or good URL reputation. When a domain is listed without active sending, investigate message content, hosted images, redirects, compromised pages, DNS history, and connected infrastructure.
What the listing scope means
The direct answer depends on the DBL component. Ordinary DBL entries are at the main-domain level and match hostnames beneath that domain through wildcard behavior. The abused-legit component can use a specific hostname when a legitimate site has been compromised.
Use subdomains for operational separation, but do not treat them as a shield against a parent-domain result. Check the exact DNS label, the parent domain, and the returned category code. Then remove the underlying mail, web, DNS, or redirector cause before treating the incident as resolved. For the related case where there is no active sending, see why not sending emails can still lead to a DBL entry.
