| # | Target | DNSBL | Status | Return | Evidence | TTL | Time (ms) | Resolver | Copy |
|---|---|---|---|---|---|---|---|---|---|
| {{ index + 1 }} |
{{ row.ip }}
{{ row.familyLabel }}
|
{{ 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 |
|---|---|---|---|---|
| {{ row.target }} |
{{ row.dnsbl }}
{{ row.status }}
|
{{ row.signal }}
{{ row.meaning }}
|
{{ row.nextStep }} |
| Query | Resolver | Status | Answers | Notes |
|---|---|---|---|---|
| {{ row.query }} | {{ row.provider }} | {{ row.status }} | {{ row.answers }} | {{ row.note }} |
| Target | Family | Listed | Error | Skipped | Coverage note |
|---|---|---|---|---|---|
| {{ row.target }} | {{ row.family }} | {{ row.listed }} | {{ row.error }} | {{ row.skipped }} | {{ row.note }} |
DNS-based blocklists are reputation zones that mail systems query before accepting, scoring, or throttling mail. A single listed outbound IP can be enough to trigger bounces, junk-folder placement, or extra filtering, so operators often need a quick way to see whether a sending host is currently visible on the lists that matter to them.
This checker provides that snapshot for a hostname, an IPv4 address, or an IPv6 address. If you enter a hostname, the tool resolves it to usable addresses first, then tests each chosen DNSBL zone separately and turns the answers into a readable summary, a row-by-row results table, and two charts that show outcome counts and response time.
That separation matters in real mail systems because one hostname can sit behind several outbound addresses. A domain-level check can look fine while one resolved IP is still listed, or an IPv4 address can be clear while its IPv6 counterpart is skipped or listed. By keeping every address and every list visible, the tool helps you decide whether the problem is tied to one address family, one provider list, or the whole sending setup.
A practical use case is a bounce investigation after a new relay starts sending. You can run the relay hostname, keep the default list set for a fast first pass, and immediately see whether the issue is concentrated on one list such as Spamhaus or SpamCop, whether several lists agree, or whether the run mostly shows resolver errors rather than real listings.
The result is still a blocklist snapshot, not a delivery guarantee. Each list has its own listing criteria and removal cadence, and some providers recommend using their data as a scoring signal rather than as an automatic reject rule on its own. The current package also sends the target to public DNS-over-HTTPS resolvers and mirrors non-default inputs into the page address, so avoid using confidential internal hostnames.
The fast path is straightforward: enter the host or IP, run the default scan, and read the summary before opening the detail rows. In the shipped configuration, the quick pass starts with seven selected lists, TXT evidence enabled, and IPv6 hostname resolution turned off. That gives you a lean first answer for ordinary mail troubleshooting without forcing extra AAAA lookups.
| Control | What It Changes | Why You Would Use It |
|---|---|---|
| Host or IP | Sets the literal address to query, or the hostname that is resolved before checking. | Use a hostname when you want to catch every resolved outbound IP, or use one IP when you already know the exact sender. |
| DNSBL catalog | Chooses which reputation zones are queried. | Useful when you want a quick default set, a wider survey, or a smaller list aligned to your environment. |
| Fetch TXT evidence | Adds a TXT query after a positive A response. | Helpful when you want provider-published reason text, policy notes, or removal hints attached to listed rows. |
| Resolve IPv6 (AAAA) | Adds hostname AAAA resolution so IPv6 addresses can be checked too. | Turn it on when the mail host is dual-stack or when you suspect only the IPv6 side is causing trouble. |
The results table is usually the best first stop because it shows the actual target IP, the list name, the returned status, the answer code, any TXT evidence, TTL, and measured lookup time. A listed row means the query returned an A answer from that blocklist zone. A clear row means the tool saw no usable listing answer. Error means the resolver or query path failed, and skipped means the selected list does not support that address family.
The two charts answer different questions. Outcomes by List helps you see whether one list is the outlier or whether several providers are aligned. Response Time shows the average latency per list together with the number of samples behind that average, which is useful when a run feels slow or when intermittent resolver failures might be hiding inside a broader scan.
The tool also gives you several ways to move the result elsewhere. The table can be copied as CSV, downloaded as CSV, or exported as DOCX. Each chart can be saved as PNG, WebP, JPEG, or chart CSV. The JSON tab mirrors the same run state in a structured form, and each row can be copied individually when you only need one listing record for a ticket or abuse report.
When the question is delivery triage rather than long-form analysis, start with a literal IP and the default list set. When the question is broader service health, switch to the hostname, enable IPv6 if relevant, and let the per-address rows show whether only one sending endpoint is carrying the reputation problem.
The package follows the standard DNSBL lookup pattern described in RFC 5782. For IPv4, it reverses the dotted-quad octets before appending the list zone. For IPv6, it expands the address to eight hextets, converts that to 32 hexadecimal nibbles, reverses the nibbles, and then appends the zone. A returned A record is treated as a positive listing signal, while optional TXT lookups collect explanatory strings when the provider publishes them.
Hostname resolution and list lookups run through public DNS-over-HTTPS endpoints. The implementation tries Cloudflare first and falls back to Google if needed, removes duplicate addresses after resolution, and records which provider answered each lookup. If IPv6 resolution is disabled, the hostname branch only uses A records. If a selected DNSBL does not support the address family being checked, the row is marked Skipped instead of being treated as a failure.
| List | Zone | IPv6 Support |
|---|---|---|
| Spamhaus ZEN | zen.spamhaus.org |
Yes |
| SpamCop | bl.spamcop.net |
No |
| SORBS | dnsbl.sorbs.net |
No |
| UCEPROTECT Level 1 | dnsbl-1.uceprotect.net |
No |
| PSBL | psbl.surriel.com |
No |
| SPAMRATS | all.spamrats.com |
No |
| DroneBL | dnsbl.dronebl.org |
No |
| SPFBL | dnsbl.spfbl.net |
Yes |
| HostKarma | hostkarma.junkemailfilter.com |
No |
| Invaluement ivmSIP | ivmSIP.invaluement.com |
No |
Status handling is intentionally conservative. If the DNS response contains an A answer, the row becomes Listed and the first returned value is shown in the Return column. If the DNS status is NXDOMAIN with no answer, the row is treated as Clear. Other nonzero status codes without a usable answer are treated as Error. The displayed TTL comes from the first answer record, and response time is measured per lookup in milliseconds.
The charts and exports are generated from the same normalized run data. The JSON payload includes the original inputs, summary counts, resolved targets, and every detailed row. The outcomes chart groups rows by list into listed, clear, error, and skipped counts. The latency chart computes an average time per list and records how many samples contributed to that average so you can tell whether a number is based on one lookup or many.
One subtle point in DNSBL work is that the returned A value is usually a signal code, not the IP address of a mail server you should connect to. A value such as 127.0.0.x commonly means “this address is listed” with provider-specific interpretation layered on top, and the optional TXT evidence often carries the human-readable part of the message.
This package does not rank the lists or collapse them into a single reputation score. It shows what each selected provider answered, how long the answer took, and whether the query could be performed at all. That is usually the right level of detail for troubleshooting because DNSBL policies differ, list coverage differs, and the operational question is often “which provider says what about which IP right now?” rather than “is this server good or bad in the abstract?”
A Listed row means that the blocklist zone returned an A answer for the exact lookup name the tool built. That is a real positive signal, but it still needs context. Different providers list for different reasons, and the same server can be listed on one service and clear on another without any contradiction because the criteria are not uniform.
The Return value should be read as the list's response code, not as a destination host. Many DNSBLs encode meaning in a small 127.0.0.x-style answer space, and the TXT field, when present, carries the human-readable explanation. If the TXT field is blank, that does not invalidate the listing. It only means the provider did not return extra explanatory text for that row.
Clear is narrower than “safe.” It means the selected list did not currently publish a positive answer for that address under this query path. Mail can still be filtered for other reasons, and a provider can add or remove a listing later. Use repeated checks to compare state over time instead of treating one run as a permanent verdict.
Error and Skipped should not be lumped together. Error usually points to transport failure, timeout, or an unexpected DNS status. Skipped is more specific: the selected list simply does not support the checked IP version. In a dual-stack scan, skipped IPv6 rows can be perfectly normal.
TTL and latency answer different questions. TTL is the cache lifetime attached to the returned answer and can hint at how long a cached result may linger. Latency tells you how quickly the lookup path responded. Neither number predicts when a provider will remove a listing, but both help explain why two checks run minutes apart may not look identical everywhere.
Single-address mail triage. You enter 203.0.113.45 with the default seven lists. If one row shows Listed and the other six show Clear, you have narrowed the issue to one provider's reputation view instead of a broad multi-list event. That usually changes the next step from “rebuild the server” to “read the provider note and follow its removal process.”
Dual-stack hostname review. You enter mail.example.com, enable IPv6 resolution, and keep seven selected lists. If the hostname resolves to one IPv4 address and one IPv6 address, the run can produce 14 checks. Several IPv6 rows may be marked Skipped because not every implemented list supports IPv6, while one IPv4 row may still be listed. That is a strong sign that the problem is tied to one address family rather than to the hostname as a whole.
Post-remediation comparison. After fixing an open relay or cleaning a compromised sender, you rerun the same IP, the same list set, and the same evidence settings later in the day. If a previously listed row becomes clear while TTL and latency remain ordinary, you have a cleaner before-and-after record for operations notes or provider correspondence.
No. It only shows that the selected lists did not currently return a positive DNSBL answer for the checked address. Delivery still depends on content, authentication, recipient policy, and other reputation systems.
Because the hostname may resolve to more than one address. The tool checks each resolved IP against each selected DNSBL, so the total check count is addresses multiplied by lists.
Skipped means the selected list does not support that IP version. In this package, several lists are IPv4-only, so IPv6 rows can be skipped even when nothing is broken.
It holds optional provider-published text attached to a positive listing. Depending on the list, that text may contain reason codes, short explanations, or a hint about where to look next.
Yes. The current implementation resolves names and performs lookups through public DNS-over-HTTPS endpoints, and changed inputs are also reflected in the page address. Avoid sharing links or targets that expose more infrastructure detail than you intend.
Usually no. In DNSBL systems, the returned A value is commonly a code that signals listing status. The IP being evaluated is the original target or the resolved address shown in the Target column.