Blacklist monitoring: DNS blocklist checks

What this screen is

The sidebar calls it Blacklist. The screen itself is headed Blacklist Monitoring, and it answers a single question: are the sender domains your tracked newsletters arrive from currently listed on a domain reputation blocklist?

Once a week Newsletrix takes every distinct sender domain in your collected newsletters and asks three domain-based blocklists (Spamhaus DBL, SURBL and URIBL) whether it is listed. The table shows the latest verdict per domain per zone, with four count tiles above it. Every answer is dated, and History on any row lists that domain's answers newest first.

The domain list is not something you maintain. It comes from the mail you actually received, one row per domain part of a sender address. You cannot add, remove or rename a domain here. If a sender has never emailed your tracking address, it does not exist on this screen.

Plenty is out of scope. IP reputation, connecting IPs, reverse DNS and inbox placement are never tested. Opens and clicks are absent too, because Newsletrix receives these emails as an ordinary subscriber. A clean row means clean on three specific domain lists at one moment, and nothing more.

Treat it as a weekly snapshot. Refresh reloads the screen without running a new check, so between two Sunday runs a listing that appears or clears stays invisible here.

Open it when

• A brand you track suddenly stops landing in your inbox and you want to know whether their domain got blocklisted.
• You are writing a competitive deliverability report and need a defensible listed or clean status per sender domain.
• You just added a batch of new senders to tracking and want to know which of them already carry a reputation problem.
• Your own sending domain is among the tracked senders and you want a weekly third-party read on it.
• The Errors / Unchecked tile is non-zero and you want to see which domains never got a usable answer.

Screen anatomy

One column, top to bottom. The header carries the last run date, four count tiles sit under it, and everything else lives in a single card holding the search box and the domain table. Numbers on the mock match the walk-through underneath it.

1. Domains tracked How many distinct sender domains appear in your collected newsletters. This is the denominator for the three tiles beside it, and the row count of the table below.
2. Clean Domains that were checked and came back with no listing and no error anywhere. Shown in green.
3. Listed Domains flagged by at least one of the three zones on the most recent check. Shown in red. Any number above zero is worth looking at the same day.
4. Errors / Unchecked Shown in amber, and it is a sum of two different problems: domains where a zone gave no usable answer, and domains that have never been checked at all. The screen does not split them for you.
5. Search domain A narrow text box above the table. It filters the rows already on screen by matching text anywhere in the domain name. It does not change the tiles.
6. Sender domains table One row per domain. It carries the number of newsletters you have from that sender, three independent verdicts in a fixed column order (Spamhaus DBL, SURBL, URIBL), the freshness of those verdicts and the History button. Rows are ordered by newsletter volume, highest first.
7. Page header and Last run The title, and a sub-line naming the three zones and ending with the timestamp of the most recent check across your domains. If no check has ever run, it reads a plain dash.
8. Refresh An outline button top right. It reloads the tiles and the table without starting a new check, and it is greyed out while the screen is still loading.
9. History A small button at the end of every row. It opens a dialog listing the last 50 checks recorded for that domain across all three zones.
10. Loading and empty states A spinner replaces the table body while results load. With no data at all the table area explains that no sender domains have been found yet, and that results appear once newsletters have been collected and the weekly check has run. With a search term that matches nothing, it reads "No domains match your search."

Every panel explained

Domains tracked

The size of the reputation surface being watched on your behalf.

How it is calculated. One entry per distinct sender domain across the newsletters you have collected, so a domain that has sent you two hundred emails still counts once. When a workspace is selected at the top of the sidebar, only newsletters delivered to tracking addresses carrying that label are counted.

How to read it. As a count of domains, not brands. Two brands sending from the same domain count once. One brand sending from both news.brand.com and mail.brand.com counts twice, and each is checked independently, so the same company can be clean on one row and listed on another.

Clean

How many of your domains passed every zone that answered on the last run.

How it is calculated. Clean is a residual rather than a direct count. Total domains minus listed minus error minus never-checked, floored at zero. The three badges on a row are what put a domain in one of those buckets, and the worst badge wins. One Listed anywhere makes it listed, one Error anywhere makes it an error.

How to read it. Clean means no listing and no error on the latest check. It is a statement about three lists at one point in time.

Listed

How many domains are flagged by at least one of the three zones.

How it is calculated. One Listed badge anywhere on the row is enough for the domain to count here. Listed also outranks Error, so a row carrying both counts as Listed and never lands in the Errors tile.

How to read it. Treat any non-zero value as a same-day task. Search for the domain, see which zone flagged it, then open History for the provider's own text, which usually carries a delisting URL.

Errors / Unchecked

Domains that came back with no usable answer, plus domains nobody has asked about yet.

How it is calculated. Two counts added together on screen. The first is rows carrying at least one Error badge and no Listed badge. The second is rows whose three zone columns all read Not checked. A listed domain never appears here, even when one of its other zones errored.

How to read it. A high number almost always means one of two things: the providers are refusing the lookups, or those domains have not been through a weekly run yet. Neither says anything about the reputation of the domains themselves.

Sender domains table

The working surface of the screen, and the only place the individual verdicts appear.

How it is calculated. One row per sender domain, and the Newsletters column counts how much mail you have from it. Rows are sorted by that count, highest first, then alphabetically by domain. The three zone columns always appear in the same order (Spamhaus DBL, SURBL, URIBL), each showing that domain's latest verdict. Last checked is the newest of the row's three timestamps, or a dash when there is none.

How to read it. Read a row left to right. How much mail you have from this sender, then three independent verdicts, then how old those verdicts are. A row whose Last checked date is much older than the header's Last run date got no result in the latest run, usually because it is one of the domains that is never looked up, or because it only started arriving after that run.

Zone status badges

Each of the three zone columns holds one of four states.

How it is calculated. A zone that has never answered for that domain reads Not checked. Once it answers, a listing reads Listed, no listing reads Clean, and an unusable answer reads Error. Each provider decides for itself what counts as a listing, so the three columns can disagree about the same domain on the same day.

How to read it. Clean means the zone answered and the answer was not a listing. Not checked means that zone has not answered for that domain yet.

Check history

The raw log behind one domain, opened from the History button on its row.

How it is calculated. The dialog lists the checks for that one domain, newest first, capped at 50. You only ever see domains that appear in your own newsletters, and the selected workspace applies here as well. Detail carries the error message on an Error line, the provider's own text on a listing, which normally includes the delisting URL, and the words "Not listed" on a clean line.

How to read it. Reading down the list tells you when a listing started and when it cleared. Fifty rows across three zones is roughly sixteen weekly runs, so about four months of history for a domain that is checked on every zone every week.

Metric definitions

Filters and controls

Some things are deliberately absent, so you can stop looking for them. There is no date range picker, no brand selector and no status filter. Column headers do not sort, nothing exports to CSV or PDF, and no button runs a check on demand. The screen only ever shows the result of the last weekly check.

How to use it

1. Read the Last run date first Everything below it is as old as that timestamp. If it says Sunday and today is Friday, you are looking at a five-day-old picture, and that is normal.
2. Triage with the tiles Listed above zero is the only tile that needs action today. Errors / Unchecked above zero is a question about the checks, not about the senders. Clean plus Listed plus Errors / Unchecked always adds up to Domains tracked.
3. Find the affected rows The table is ordered by how much mail each sender has sent you, so type part of the domain into the search box rather than scrolling. Read the three zone badges left to right and note which provider flagged it.
4. Open History on that row The log shows when the listing first appeared, which is what tells you whether it is new or long-standing, and the Detail column usually holds the provider's delisting URL for a genuine listing.
5. Act with the provider, then wait a week Delisting happens on Spamhaus, SURBL or URIBL directly, never inside Newsletrix. The badge here only changes after the next Sunday run, so allow up to seven days before you re-check.
6. Sanity-check a wall of Errors If a whole column is amber, the provider is refusing the checks rather than the domains being bad. That one is ours to fix, so raise it with support instead of contacting the senders.

Limits and caveats

• Domains only. No IP reputation, no connecting-IP or reverse DNS checks, no inbox placement testing. A clean row is not a deliverability guarantee.
• Three zones only. Spamhaus DBL, SURBL and URIBL are checked and every other blocklist is not, so Clean means clean on those three.
• Weekly cadence. The status on screen can be up to seven days stale, and a listing that appeared and cleared between two runs never shows up at all.
• Clean is a residual, so it inherits any counting quirk from the other three buckets instead of being verified on its own.
• Errors / Unchecked merges two conditions that need different responses, and the tile alone cannot tell you which one you have.
• Some domains are never looked up at all. Anything shorter than four characters, without a dot, with a leading or trailing dot or whitespace, or ending in .local, .localhost, .internal, .test, .invalid or .example. They still appear in the table, permanently marked Not checked.

FAQ

Related screens