How does Spamhaus decide whether to list a subdomain or a whole domain on the DBL?
Updated on 29 Sep 2026: We updated this guide to explain how full-hostname queries, wildcard matches, and DBL return codes reveal the scope of a listing.
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, the abused-legit component can 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 full 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 | Possible abused-legit entry | Code and parent |
Parent domain | Main-domain entry | All domain uses |
Host and parent | Possible wildcard match | Compare answers |
127.255.255.x | Query error | Resolver and zone |
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. It supports hostname-level data when one site on a legitimate shared domain is compromised, allowing a narrower result that 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. Common causes include a compromised CMS, injected files, stolen credentials, and redirect abuse.
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 says reputation depends on observed use over time, connected IP reputation, hosting quality, DNS configuration, and abuse activity.
- Unknown reputation: Spamhaus says an unknown domain starts with poor reputation because unknown domains carry greater abuse risk. That starting reputation does not by itself mean the domain is listed.
- 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 full 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.
Why full-hostname queries matter
A lookup system can erase the distinction before the query reaches DBL. Software that converts shop.customer.example.com to example.com will still detect an ordinary parent-domain entry, but it cannot ask whether the full hostname has a narrower abused-legit entry. Spamhaus's hostname guidance specifically warns that configurations which reduce every query to the base domain do not benefit from hostname-based data.
|
|
|
|---|---|---|
Full hostname preserved | Host entry or parent wildcard | Nothing at that label |
Reduced to parent | Ordinary parent entry | Narrow hostname entry |
IP sent to DBL | Only prohibited-query code | Actual IP reputation |
How query normalization changes the scope you can observe.
Preserve the fully qualified hostname for the first query, then query the parent separately. A positive hostname result still needs the parent comparison because wildcard matching can produce the same answer. In automated filtering, confirm that the integration is designed for domain and URI checks rather than an IP DNSBL field.
A lookup is only as precise as its input
Record the original hostname, normalized parent, DBL return code, query zone, and resolver result. Without those fields, an incident record cannot reliably show whether Spamhaus listed one hostname or the wider domain.
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. An authoritative NXDOMAIN response to a correctly formed DBL query means the queried name is not listed. A timeout, SERVFAIL, or other resolver failure does not mean the name is clear. 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 | Abused-legit phishing | Hostname clue |
127.0.1.105 | Abused-legit malware | Hostname clue |
127.0.1.106 | Abused-legit botnet C&C | 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 original DNS 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.
- Preserve and compare scope: Query the full hostname before the parent domain, then interpret both 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.
If 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 brings DMARC data, authentication results, sending sources, domain changes, and blocklist monitoring into 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. Preserve and check the full DNS label, then check the parent domain and returned category code. 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.
Frequently asked questions
No. DBL contains domains and hostnames. A DBL query for an IP returns 127.0.1.255, which means IP queries are prohibited and does not mean the IP is listed.
Not always. A listed parent domain produces positive wildcard results for its hostnames. Preserve the full hostname, compare it with the parent domain, and interpret both return codes. Software that strips every query to the parent cannot reveal a narrower hostname entry.
No. Subdomains improve ownership and diagnosis, but ordinary DBL entries are made at the main-domain level and apply to descendant hostnames through wildcard matching.
The parent domain is likely listed. DBL wildcard behavior makes hostnames under a listed parent return a positive result even when those hostnames do not have separate records.
Most do. Spamhaus continually reevaluates DBL entries, and most expire after the associated activity stops. A domain can relist automatically if the activity is detected again.
No. Stop the triggering activity first, then follow any removal instructions in the Spamhaus Reputation Checker. Approved removal is free, but unresolved activity can cause relisting.
