A blacklist monitor asks the public DNS blocklists whether an IP address has been listed, twice a day, and tells you the moment one says yes — while there is still time to request delisting.
No card required · 50 monitors free · No time limit
Every check in this workspace. Failing monitors sort to the top.
Each feature earns its place by making the client relationship easier to protect: fewer surprises, clearer proof, and faster explanations when something changes.
A blacklisted mail server answers pings, serves HTTPS and passes every uptime check you own. Nothing is down. Mail is simply being rejected at the far end, and the first anyone hears of it is a client asking why their invoices bounced. This is the one check that asks the question directly.
A clean address and a query the list refused look identical from the outside — both come back as nothing. So a refusal, a timeout, or an answer from the wrong place is recorded as unknown, never as clean, and a check where no list answered is not recorded at all. The dashboard shows the last real answer and its age rather than a reassuring tick.
A listed address is perfectly reachable, so it never counts against the uptime figure you hand a client. It shows amber, alerts every channel on the monitor, and says what the fix is: request delisting, not restart the server.
Most checks have two answers. This one has three, because "we could not find out" is a real and dangerous state: it looks exactly like good news.
Shown as “Not listed”
At least one blocklist gave a definitive answer and none of them listed the address. The check records how many lists answered, and names any that could not be reached.
Shown as “Blacklisted”
One or more lists returned a listing. The alert names them so you can go straight to the delisting form. The address is still reachable, so this never touches the uptime percentage — it is a reputation problem, not an outage.
Shown as “Nothing answered”
No blocklist gave a usable answer — refused, timed out, or answered from somewhere it should not have. That says something about the check, not about your client, so no result is written at all. The monitor keeps its last real answer and shows how long ago it was.
Only the middle state alerts. The third is logged for us, loudly, because a monitoring product that quietly stops monitoring is worse than one that was never installed.
Add the signal once, then let alerts, history, and reports build automatically.
A bare IP or a hostname — 203.0.113.10 or mail.client.com. Hostnames are resolved at every check, so a server that moves is followed.
Twice a day on Solo and Team, four times on Enterprise. Blacklists move over hours, not minutes, and the lists themselves rate-limit by query volume.
The alert names each list that responded, so you can go straight to that list’s delisting form.
Two reasons, neither of them our server capacity. The blocklist operators rate-limit and licence by query volume, and being refused would degrade the feature silently — a refused query is indistinguishable from a clean answer unless you read the return codes carefully, which we do. And a listing is a slow event: it lasts hours to days, and delisting takes hours. A one-minute check would tell you nothing a twice-daily check misses.
A set of public DNS blocklists that permit our queries, currently seven, each verified to be answering before it is used. We deliberately exclude lists that charge for delisting — telling you that your client is listed somewhere that wants a payment to fix it is not a service. The list set is configuration, so it grows without a release.
It is recorded as unreachable and named as such, and the check reports how many lists actually answered. If no list answers at all, nothing is written: the monitor keeps its last real result and the timestamp that goes with it. A green tick for a check that never happened is the one outcome this feature refuses to produce.
Yes. The name is resolved at each check and every public address it points to is checked, so a mail server that moves is followed automatically. Private and loopback addresses are refused — no public blacklist has an opinion about 192.168.1.1, so a monitor on one could never report anything true. Blacklist monitors need a paid plan; the Free plan covers HTTP monitors only.
Combine uptime, SSL, domains, incidents, alerts, teams, and reports into one maintenance workspace.
An API monitor calls one endpoint with the method, headers, JSON body and auth y…
Push-based heartbeat monitoring for backups, syncs, exports, and scheduled tasks…
A DNS monitor asks a resolver for one record type — A, AAAA, CNAME, MX or TXT — …
Track every client domain expiry date and receive timely warnings before a renew…
Automatic incident detection, response notes, status updates, and reports so cli…
A keyword monitor loads one URL and searches the HTML the server returned for a …
Monitor SSL certificates and receive warnings well before they expire, so client…
Give maintenance clients transparency with a professional, automatically updated…
Invite your team, assign roles, and collaborate on monitoring, alerts, and repor…
Fifteen channels: chat, mobile push, on-call paging, or your own webhook. Mainte…
Start with blacklist monitoring and build client trust with real data. Free, no credit card required.
Create free accountNo card required · 50 monitors free · No time limit