Blacklist Checker (DNSBL/RBL)

DNSBL Triage Summary

{{ overallStatusMeta.label }} Listed {{ listedCount }} Policy {{ policyListingCount }} Resolver {{ resolverIssueCount }} Clear {{ clearCount }} {{ resolvedIpCount }} IPs {{ selectedListCount }} lists

Primary action: {{ primaryRecommendation }}

Input: {{ runMeta.input }} ({{ kindLabel(runMeta.kind) }})

Targets: {{ summaryTargets }}

Last run: {{ lastRunLocal }}

Host or IP:

Use a mail host or sender IP: mail.example.com, 203.0.113.45, or 2001:db8::25.

Catalog preset:

DNSBL catalog:

{{ selectedListCount }} of {{ catalogSize }} lists selected; hold Cmd or Ctrl to adjust the set.

List	Zone	Support	Open
{{ item.name }}	{{ item.zone }}	{{ supportLabel(item) }}

Fetch TXT evidence:

On adds TXT notes for listed rows when the provider publishes them.

Resolve IPv6 (AAAA):

On checks resolved IPv6 addresses against lists that support IPv6 DNSBL queries.

#	Target	DNSBL	Status	Return	Evidence	TTL	Time (ms)	Resolver	Copy
{{ index + 1 }}	{{ row.ip }} {{ row.familyLabel }}	{{ row.listName }} {{ listZone(row.listKey) }}	{{ statusLabel(row.status) }} {{ row.actionLabel }}	{{ row.responseDisplay \|\| '—' }} {{ row.responseTags.join(' · ') }}	{{ row.evidence }} — {{ row.message }}	{{ row.ttl === null \|\| typeof row.ttl === 'undefined' ? '—' : row.ttl }}	{{ row.ms === null \|\| typeof row.ms === 'undefined' ? '—' : row.ms }}	{{ row.provider \|\| '—' }}

Target	DNSBL	Signal	Next step	Open
Primary action	Triage	{{ primaryRecommendation \|\| 'No follow-up needed yet.' }}	Use this as the first triage lane before opening provider pages or delisting work.	—
Affected targets	Targets	{{ listedIpCount }} of {{ resolvedIpCount }} targets show listing signals	The target chart keeps each resolved IP separate so hostname checks do not hide a single bad sender.	—
Resolver watch	Resolver	{{ resolverIssueCount }} resolver-limited rows	Spamhaus and similar providers can reject public-resolver queries. Those rows are separated from true listings here.	—
Run note {{ index + 1 }}	Run note	{{ note }}	Action context	—
{{ row.target }}	{{ row.dnsbl }} {{ row.status }}	{{ row.signal }} {{ row.meaning }}	{{ row.nextStep }}

No selected DNSBL returned a positive listing or resolver-limited warning on this run. Treat that as clear for this list set only, not as a delivery guarantee.

Query	Resolver	Status	Answers	Notes	Copy
{{ row.query }}	{{ row.provider }}	{{ row.status }}	{{ row.answers }}	{{ row.note }}
{{ row.target }}	{{ row.family }}	Coverage	{{ row.listed }} listed / {{ row.error }} error / {{ row.skipped }} skipped	{{ row.note }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Mail delivery can fail before a message body is even inspected. Many receiving mail systems check the connecting sender IP against DNS-based blocklists, usually called DNSBLs or RBLs, while deciding whether to accept, reject, defer, or score a message. A positive DNSBL answer is a reputation or policy signal published through DNS, not a full diagnosis by itself.

The same word, "listed," can cover very different situations. One list may point to spam from a compromised server, another may flag an open proxy, and a policy list may mark residential or dynamic address space that should not send mail directly. Treating all of those as one blacklist problem can waste time, especially when the right fix is to use an authenticated outbound relay instead of requesting removal.

DNSBLs use ordinary DNS answers, but the meaning depends on the list, the return code, the resolver path, and the sender address being checked.

Hostname checks add another wrinkle. A mail name can resolve to several IPv4 addresses, and some operators also send over IPv6. One address may be listed while the others are clear, and many older blocklists still only publish IPv4 data. For that reason, a useful RBL status check keeps the resolved address, list name, return code, TXT note, and resolver outcome together instead of collapsing the hostname into a single verdict.

Resolver behavior matters because DNSBL providers can refuse or special-code lookups made through public or high-volume resolvers. A response that looks like a listing code may actually be a warning about how the query was made. Spamhaus, for example, publishes special 127.255.255.x answers for resolver or query problems, so those rows need follow-up before anyone treats the sender as abusive.

A clear DNSBL pass is still only one delivery clue. SPF, DKIM, DMARC, sender history, message content, throttling, recipient rules, and provider-specific reputation systems can still affect inbox placement after the selected blocklists return no positive answer.

How to Use This Tool:

Use the checker as a triage pass for the sending address you actually care about. Start with the exact SMTP sender IP when you have mail logs, and use a hostname only when you need the page to resolve the address set first.

Enter an IPv4 address, IPv6 address, or mail hostname in Host or IP. Literal IP input is checked directly; hostname input is resolved before DNSBL queries run.
Choose Catalog preset. Default mail triage runs a seven-list first pass, Core reputation snapshot narrows the run, IPv6-capable only avoids IPv4-only lists, and All implemented lists checks the full catalog.
Select Check DNSBLs. While lookups are active, the status surface shows that the DNSBL matrix is being scanned; results appear after usable rows return.
Open Advanced when you need a custom list set. The DNSBL catalog shows each selected provider zone and whether it supports IPv4 only or both IPv4 and IPv6.
Keep Fetch TXT evidence on when you need provider-published notes for an incident ticket, appeal, or audit trail. Turn it off for a shorter first pass because TXT requests are only useful after a positive listing answer.
Enable Resolve IPv6 (AAAA) for hostname checks when dual-stack sending may matter. If you leave it off, the resolver report records that AAAA records were not requested.
Read the summary badges and Action Plan before scanning every row. Then use DNSBL Results for return codes, evidence, TTL, response time, resolver label, and the exact lookup target.
Use Target Impact, Outcomes by List, and Response Time to see whether the issue is concentrated on one IP, one DNSBL provider, or the resolver path.

If the page reports no usable IP addresses, check the hostname spelling or paste the sender IP from the mail log. If rows show resolver follow-up, verify the same address through an allowed resolver or the provider's own lookup page before opening a delisting request.

Interpreting Results:

The main number counts positive listing rows, not bad hosts. A single hostname can resolve to more than one address, and each address is checked against each selected DNSBL. Use Target Impact to identify the affected sender address before changing mail routing or contacting a blocklist provider.

DNSBL result states and first checks
Status	Meaning in this run	Best first check
`Listed`	The selected DNSBL returned one or more usable address answers for that sender IP.	Read the return code, TXT evidence, provider note, and action lane before requesting delisting.
`Clear`	The selected list did not return a positive answer for that IP during this run.	Treat it as clear only for that list, target, time, and resolver path.
`Error`	The resolver path failed, returned an access warning, or returned a DNS status that cannot support a reputation decision.	Retry from an allowed resolver or provider page before treating the row as a sender problem.
`Skipped`	The selected list does not support the address family being checked.	Use an IPv6-capable preset for IPv6 senders, or expect skipped rows when broad presets include IPv4-only lists.

The action lane separates three common follow-up paths. Source remediation points to abuse, compromise, malware, or spam-like behavior that should be fixed before any removal request. Policy-block guidance usually means the address should not send directly and should relay through an authenticated provider or smarthost. Resolver follow-up means the query path itself needs confirmation.

TXT evidence can be useful, but it is not a substitute for understanding the returned A code. Some providers publish clear removal hints, while others provide terse notes or links. When the evidence conflicts with a return-code interpretation, verify the row on the provider page and check the actual mail server path.

The chart tabs are explanatory aids. Outcomes by List shows whether one DNSBL is driving the result set, Target Impact separates affected IPs, and Response Time helps spot resolver slowdowns. None of those charts proves why a recipient accepted or rejected a real message.

Technical Details:

DNSBL lookups use the DNSxL pattern documented in RFC 5782. For IPv4, the four address octets are reversed and appended to the list zone. For IPv6, the address is expanded into 32 hexadecimal nibbles, the nibbles are reversed, and the list zone is appended. The query asks for address records; a returned loopback-style value is a signal code, not a mail server.

Most IP-based DNSBLs use an A record in the 127.0.0.0/8 range to signal a listing, often with optional TXT text for a human-readable reason. The exact code mapping is provider-specific. NXDOMAIN commonly means the queried item is not listed, but other DNS status values can mean the resolver could not answer the question reliably.

Core DNSBL lookup and classification mechanics
Stage	Mechanism	Evidence exposed in results
Target preparation	Literal IP addresses are checked directly. Hostnames are resolved to A records and, when enabled, AAAA records.	`Resolver Path` records query type, resolver label, DNS status, answer count, and skipped AAAA notes.
Query name	IPv4 uses reversed octets. IPv6 uses reversed nibbles. Unsupported address families are not queried against IPv4-only lists.	`DNSBL Results` keeps each IP-list pair as a separate row.
Positive answer	A usable address answer usually marks the row listed, unless a provider-specific code is known to represent a query or resolver problem.	`Return` shows the answer code, and the row receives a listed or error status.
No positive answer	No listing answer, including the common not-found case, is treated as clear for that exact target and list.	The row becomes `Clear`, with any resolver timing still recorded.
TXT follow-up	TXT records are requested after a positive listing only when evidence collection is enabled.	`Evidence` shows provider notes, removal hints, or a TXT lookup failure note.

The built-in catalog contains Spamhaus ZEN, SpamCop, SORBS, UCEPROTECT Level 1, PSBL, SPAMRATS, DroneBL, SPFBL, HostKarma, and Invaluement ivmSIP. Spamhaus ZEN and SPFBL are marked as IPv6-capable, so a broad IPv6 run can contain many expected skipped rows. Presets only choose subsets of that catalog; they do not change how a provider defines abuse, policy, or delisting.

Spamhaus return-code handling used for DNSBL interpretation
Return code	Meaning used for triage	Action lane
`127.0.0.2`, `127.0.0.3`, `127.0.0.4`, `127.0.0.9`	SBL, CSS, XBL/CBL, or DROP/EDROP style abuse and reputation signals.	Fix the sender, host, or upstream abuse source before requesting removal.
`127.0.0.10`	PBL policy signal for address space that should not send mail directly.	Route outbound mail through an authorized relay or provider smarthost.
`127.0.0.11`	Policy signal combined with CSS data.	Fix sender behavior and avoid direct outbound delivery from that IP.
`127.255.255.252`, `127.255.255.254`, `127.255.255.255`	Query problem such as missing resolver identity, public resolver use, or excessive query volume.	Verify through an allowed resolver or the provider lookup page before treating the sender as listed.

TTL and response time answer different questions. TTL is the cache lifetime attached to the DNS answer. Response time is how long the resolver path took to answer during this run. Neither value predicts when a provider will remove a listing, but both can explain why repeated checks differ during caching, rate limits, resolver failover, or partial DNS failures.

This checker does not send mail, authenticate a domain, inspect SPF, DKIM, or DMARC records, or test every reputation system a recipient might use. It reports the selected DNSBL answers and separates provider, policy, and resolver signals so the next operational step is less ambiguous.

Privacy and Accuracy Notes:

The check runs from the browser through public DNS-over-HTTPS resolvers. The target hostname or derived DNSBL query names can be visible to those resolver services during a lookup, and selected options can appear in the page URL for shareable state.

Use the literal sender IP when the hostname itself is sensitive and you already know the address that appeared in mail logs.
Avoid confidential internal hostnames or investigation targets if sharing those lookup names with public resolvers is not acceptable.
No message content is checked. The result is about sender address reputation signals, not the body, attachments, authentication alignment, or recipient filtering rules.
For blocking, routing, or delisting decisions, confirm important rows from the resolver path used by your mail infrastructure or from the provider's lookup page.

Worked Examples:

Sender IP with a policy block

You enter 203.0.113.45 with Default mail triage. Most rows are clear, but Spamhaus returns 127.0.0.10. The next step is to route outbound mail through the provider or ISP smarthost, not to assume the server is infected.

Hostname with one affected address

You enter mail.example.com, enable Resolve IPv6 (AAAA), and keep TXT evidence on. The hostname resolves to one IPv4 address and one IPv6 address. Target Impact shows the IPv4 rows clear while the IPv6 address has one listed row and several skipped IPv4-only rows. The issue belongs to the IPv6 sending path, not the hostname as a whole.

Resolver-limited Spamhaus response

A Spamhaus row returns 127.255.255.254. The row is treated as resolver follow-up instead of source remediation. Recheck the same sender IP from an allowed resolver or the Spamhaus lookup page before changing mail flow or opening a delisting task.

No usable address records

A mistyped host returns no usable A or AAAA records. The page reports that no usable IP addresses were found, and Resolver Path shows the resolution outcome. Fix the hostname or paste the literal sender IP from the SMTP log, then run the check again.

FAQ:

Does a clear result mean mail will be delivered?

No. It means the selected DNSBLs did not return a positive answer for the checked IP during this run. Delivery still depends on authentication, content, recipient policy, rate limits, sending history, and reputation systems outside the selected catalog.

Why can one hostname create many checks?

A hostname can resolve to multiple addresses. The total row count is the number of resolved IPs multiplied by the number of selected DNSBLs, with unsupported address-family combinations marked as skipped.

Why are some IPv6 rows skipped?

Only DNSBLs marked as IPv6-capable are checked for IPv6 addresses. In the built-in catalog, Spamhaus ZEN and SPFBL are marked for IPv6 support, so skipped rows are expected when wider presets include IPv4-only lists.

When should TXT evidence be enabled?

Enable it when you need provider-published notes for an incident record, ticket, or removal request. Leave it off for a faster first pass because TXT evidence is requested only after a positive listing answer.

Why can Spamhaus show resolver follow-up?

Spamhaus publishes special return codes for query problems such as public resolver use and excessive query volume. Those codes describe the query path, so verify them before treating the sender IP as listed.

Can this replace provider delisting instructions?

No. Use the result as triage evidence, then follow the affected provider's current remediation and removal process. Some lists require fixing the sending source first, while policy lists may require a routing change rather than a removal request.

Glossary:

DNSBL: A DNS-based blocklist that publishes reputation or policy data through DNS answers.
RBL: A common shorthand for reputation blocklists, often used interchangeably with DNSBL in mail operations.
TXT evidence: Provider-published text returned with some positive listings, often used for reason notes, links, or removal guidance.
DoH: DNS-over-HTTPS, a way to send DNS questions over HTTPS to a resolver service.
PBL: Policy Block List, a Spamhaus signal for address space that should not send mail directly.
TTL: Time to live, the cache lifetime attached to a DNS answer.

References:

RFC 5782: DNS Blacklists and Whitelists, IETF.
Spamhaus DNSBL usage FAQ, Spamhaus.
Spamhaus Policy Blocklist FAQ, Spamhaus.
Cloudflare DNS over HTTPS JSON documentation, Cloudflare.
Google Public DNS JSON API for DNS over HTTPS, Google for Developers.
SpamCop Blocking List, SpamCop.