Blacklist Checker (DNSBL/RBL)

{{ 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

Email reputation checks happen in the narrow gap between a connecting mail server and a receiving mail system's decision to accept, reject, defer, or score a message. DNS-based blocklists, commonly called DNSBLs or RBLs, publish sender-address reputation and policy signals through DNS so mail systems can make that decision before the full message is handled. A positive answer is a clue about the sender address, not a complete explanation of a delivery failure.

The word blacklisted hides several different meanings. Some lists flag abuse from compromised hosts, open proxies, botnets, or spam-like sending. Others publish policy data for residential, dynamic, or customer address space that should not deliver mail directly to third-party MX servers. A policy listing often calls for authenticated relay through an ISP or mail provider, while an abuse listing usually calls for cleanup before delisting.

Common DNSBL situations and practical meaning
Situation	What it may mean	Common mistake
Compromised sender	Malware, an open proxy, an abused account, or another source of unwanted mail is tied to the IP.	Requesting removal before fixing the sender can lead to relisting.
Policy-listed address	The IP range is not intended to send unauthenticated mail directly to outside MX servers.	Treating the listing as proof that the host is infected.
Resolver warning	The lookup path, public resolver, or query volume may be blocked by the provider.	Reading a resolver-only response as a sender reputation result.
Clear selected lists	The selected DNSBLs did not return a positive answer for the checked address at that moment.	Assuming inbox delivery is guaranteed.

Hostnames make reputation checks less direct. A mail hostname can resolve to several IPv4 addresses, and some sending platforms also use IPv6. One address can be listed while another is clear, and many DNSBLs still only support IPv4. Useful triage keeps each resolved address, selected list, DNS answer, TXT note, and resolver result separate so the affected sender can be found without guessing.

DNSBL lookup flow from sender IP to reversed query, provider answer, and resolver-aware interpretation — DNSBL checks depend on the transformed query name, the provider's return code, optional TXT evidence, and the resolver path that carried the query.

Resolver choice matters because blocklist providers may limit public resolvers, high-volume lookup paths, or resolvers without suitable identity. A provider-specific resolver warning can look like an address answer unless it is interpreted with the provider's documented code meanings. For Spamhaus, several 127.255.255.x answers describe query problems rather than confirmed sender listings.

A clean blocklist run still leaves other delivery checks open. SPF, DKIM, DMARC, sending rate, message content, bounce history, recipient rules, and provider reputation systems can all affect placement after the selected DNSBLs return no positive answers.

How to Use This Tool:

Use the checker as a first-pass evidence run for the sender address that appears in mail logs or outbound routing records. A hostname is useful when you need resolution included, but a literal sender IP is usually the cleanest input for incident triage.

Enter the sender address in Host or IP. Use an IPv4 address, IPv6 address, or mail hostname such as mail.example.com.
Choose Catalog preset before running the check. Default mail triage gives a seven-list first pass, Core reputation snapshot keeps the run shorter, IPv6-capable only avoids IPv4-only lists, and All implemented lists runs the full catalog.
Select the DNSBL catalog manually only when a provider-specific follow-up requires a smaller or wider set than the preset.
The catalog selection changes which lists are queried, not how a returned code is interpreted.
Leave Fetch TXT evidence on when you need provider notes for a ticket, audit note, or delisting review. Turn it off for a faster first pass when listing reasons are not needed yet.
Enable Resolve IPv6 (AAAA) for hostname checks when dual-stack outbound mail is possible. If it stays off, IPv6-only sending paths are not checked for that hostname.
Skipped IPv6 rows can be expected when a broad preset includes lists that only support IPv4 lookups.
Run the check and read the summary badge before scanning individual rows. A result such as Source remediation, Policy block detected, or Resolver follow-up points to the first operational path.
Open Action Plan for the next step, then use DNSBL Results for return codes, TXT evidence, TTL, response time, resolver label, and the exact lookup target.
Use Target Impact, Outcomes by List, and Response Time only after the table has usable rows. They show whether listings cluster on one resolved IP, one DNSBL provider, or a slow resolver path.
Recheck after fixing a sender, changing routing, or confirming resolver warnings. If the page reports No usable IP addresses found, correct the hostname or paste the literal sender IP from the SMTP log.

Interpreting Results:

The headline count is a count of positive list-target rows, not a count of bad servers. A hostname that resolves to two addresses and is checked against seven lists can produce fourteen rows, and only one affected row may explain the delivery problem. Use Target Impact to identify the IP before changing outbound routing or opening a provider ticket.

DNSBL result statuses and interpretation checks
Status	Meaning in this run	Verification cue
`Listed`	The selected DNSBL returned one or more usable address answers for that IP.	Read the return code, response tags, TXT evidence, and provider guidance before requesting removal.
`Clear`	No positive answer was returned for that exact list, IP, time, and resolver path.	Do not treat this as proof that all mail will be delivered.
`Error`	The lookup failed, returned a DNS status without a usable answer, or matched a resolver-limited provider code.	Repeat the check from an allowed resolver or the provider lookup page.
`Skipped`	The selected list does not support the address family being checked.	Use an IPv6-capable preset for IPv6 senders or expect skipped rows with mixed presets.

Action Plan is the safest first read when rows are mixed. Abuse or compromise signals belong to source cleanup. Policy signals point toward authenticated relay or smarthost routing. Resolver warnings need confirmation before the sender is blamed.

TXT evidence can help with removal requests, but it should not override the returned A code or the provider's current lookup page. When evidence is missing, terse, or contradictory, verify the affected IP directly with the provider and compare it with the resolver path used by the mail infrastructure.

Technical Details:

DNSBLs follow the DNSxL pattern described in RFC 5782. An IP address is transformed into a DNS name under the provider's zone, and the provider publishes DNS answers that represent listing state. The returned address value is a signal code, not a host to connect to. Optional TXT records can add human-readable context, but the A answer is the primary machine-readable result.

IPv4 and IPv6 use different name transformations. IPv4 reverses the four octets. IPv6 expands the address to 32 hexadecimal nibbles, reverses those nibbles, and appends the list zone. Unsupported address families are not queried because an IPv4-only DNSBL cannot answer meaningfully for an IPv6 sender.

Lookup Core:

Core DNSBL lookup mechanics
Stage	Rule	Evidence exposed
Target preparation	Literal IP addresses are checked directly. Hostnames are resolved to A records and, when enabled, AAAA records.	`Resolver Path` records query type, DNS status, resolver label, and answer count.
Query name	IPv4 uses reversed octets. IPv6 uses reversed nibbles. The transformed address is appended to each selected DNSBL zone.	`DNSBL Results` keeps every IP-list pair separate.
Positive answer	A usable A answer normally means listed, except when a provider-specific answer is known to describe a query problem.	The row shows the return code, response tags, action lane, and provider link when available.
No positive answer	No usable listing answer, including the common not-found case, is treated as clear for that exact row.	The row stays `Clear` while resolver timing is still retained.
TXT evidence	TXT records are requested only after a positive listing when evidence collection is enabled.	`Evidence` contains provider notes or a TXT lookup failure message.

The implemented 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. The presets choose subsets of that catalog; they do not normalize provider policies or make one provider's return code mean the same thing as another provider's code.

Spamhaus Return Codes:

Spamhaus code handling used for DNSBL triage
Return code	Interpretation	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, account, or upstream abuse condition before requesting removal.
`127.0.0.10`	PBL policy signal for address space that should not send mail directly to third-party MX servers.	Route outbound mail through an authenticated 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 provider lookup page before treating the sender as listed.

TTL and response time describe the DNS transaction, not the reputation problem. TTL is the cache lifetime attached to the DNS answer. Response time is the measured duration for the resolver path during the current run. Repeated checks can differ because of caching, provider rate limits, resolver failover, or short-lived DNS failures.

The lookup does not send test mail, inspect message content, authenticate a domain, or check SPF, DKIM, DMARC, or recipient-specific reputation systems. Its technical value is narrower: it preserves the selected DNSBL answers and separates listing, policy, skip, and resolver-warning cases so the next operational step is easier to choose.

Privacy and Accuracy Notes:

The check uses public DNS-over-HTTPS resolvers from the browser. The entered hostname, literal IP-derived lookup names, selected lists, and timing can be visible to those resolver services during the run. The page does not inspect message bodies or attachments.

Use a literal sender IP when the hostname is sensitive and mail logs already show the address that connected.
Avoid confidential internal hostnames or investigation targets if sending derived DNSBL query names to public resolvers is not acceptable.
Provider access limits can turn a lookup into a resolver-warning result rather than a sender reputation result.
For blocking, routing, or delisting decisions, confirm important rows from the resolver path used by the production mail system or from the affected provider's lookup page.

Worked Examples:

Policy-listed sender IP

An SMTP log shows outbound mail leaving from 203.0.113.45. If a Spamhaus row returns 127.0.0.10, the result is treated as a policy block rather than proof of malware. The next step is to route mail through an authenticated relay or provider smarthost, then verify the provider's own guidance.

Hostname with one affected address

A hostname check 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 expected skipped rows from IPv4-only lists. The follow-up belongs to the IPv6 sending path, not to the hostname as a single object.

Resolver-limited Spamhaus answer

A Spamhaus row returns 127.255.255.254. The row is classified as resolver follow-up, so changing mail routing would be premature. Recheck the same sender IP from an allowed resolver or on the provider lookup page before opening a delisting task.

No usable hostname address

A mistyped mail name produces No usable IP addresses found. Correct the hostname or paste the literal sender IP from the SMTP log, then run the check again and confirm that DNSBL Results contains rows before reading the charts.

FAQ:

Does a clear DNSBL result mean my email will reach the inbox?

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, sending history, rate limits, recipient policy, and reputation systems outside the selected catalog.

Why can one hostname produce many rows?

A hostname can resolve to multiple addresses. Each resolved address is checked against each selected DNSBL, and unsupported address-family combinations are marked as skipped.

Why are some IPv6 rows skipped?

Only DNSBLs marked as IPv6-capable are checked for IPv6 addresses. In the implemented 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 notes for a ticket, incident record, or removal review. Leave it off for a faster first pass because TXT evidence is requested only after a positive listing answer.

Why does Spamhaus sometimes need resolver follow-up?

Spamhaus publishes special return codes for query problems such as public resolver use or excessive query volume. Those codes describe the lookup path, so they should be verified 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 signals through DNS answers.
RBL: A common mail-operations shorthand for real-time blocklists, often used loosely for DNSBLs.
DNSxL: The broader RFC term for DNS-based blacklists and whitelists that share similar query structure.
TXT evidence: Provider-published text returned with some listings, often used for reason notes or removal guidance.
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.
DNS-over-HTTPS: A way to send DNS questions over HTTPS to a resolver service.

References:

RFC 5782: DNS Blacklists and Whitelists, RFC Editor, February 2010.
Spamhaus DNSBL usage FAQ, Spamhaus.
Policy Blocklist (PBL), Spamhaus.
Using JSON for DNS over HTTPS, Cloudflare Docs.
JSON API for DNS over HTTPS, Google for Developers.
SpamCop Blocking List, SpamCop.