A blacklisting doesn't take your site down. It quietly drops your password resets and order confirmations into spam while your dashboard stays green. Hoppla resolves the monitored hostname to its IPv4 addresses and checks them against 20 public DNS blacklists on every run. Point it at your mail host to cover your sending IP. New listings and delistings reach you on the next run.
203.0.113.10 · 20 DNSBLs · zen.spamhaus.org LISTED · WARNING (newly-listed)
Fictional values. Not a live measurement.
Hoppla resolves your monitored hostname to its current IPv4 address(es) and queries 20 public DNS blacklists to see whether any of them flag you as a spam source. Listed on one or more, the check goes to WARNING. Clean across all 20, it reads OK. It tracks the change in both directions, so you hear about a fresh listing, and a delisting once your appeal clears, on the next run after it happens.
Hoppla resolves your monitored hostname to the IPv4 address(es) it currently points at. Those live IPs are what every blacklist gets queried against. So a DNS change that moves you onto a dirty IP gets caught on the next run, not weeks later.
Each IP is checked against 20 public blacklists: Spamhaus (zen.spamhaus.org), SpamCop, Barracuda, CBL/abuseat, UCEPROTECT, Mailspike, PSBL, DroneBL and more. Lookups run concurrently in non-blocking subprocesses, with a five-second ceiling on the sweep, so a full 20-list check doesn't stall on whichever list is slowest that minute.
One or more listings drops the check to WARNING and names the lists you're on. Clean across all 20 and it reads OK. This check is deliberately advisory. A listing hurts deliverability, it doesn't take your site offline, so it never opens a downtime incident or starts an on-call escalation.
Hoppla compares each run to the last and notifies only on transitions. Newly-listed when an IP appears on a list it wasn't on. Newly-delisted when it drops off. You learn the day you got flagged and the day your removal landed, with no 'still listed' nag every run in between.
One sweep covers the lists that gate inboxes: Spamhaus, SpamCop, Barracuda, CBL, UCEPROTECT, Mailspike, PSBL, DroneBL and more. A Spamhaus listing alone can be the difference between landing and bouncing across a lot of corporate mail filters.
A blacklisting is silent. Your site stays up, your dashboard stays green, and your password-reset emails just stop arriving. Hoppla alerts on the next run after an IP gets newly listed, so you can catch it from a notification instead of a support ticket asking where the email went.
Lookups fire concurrently in non-blocking subprocesses, capped at five seconds, so checking 20 lists isn't 20 timeouts back to back. The sweep stays quick enough to run on your real schedule, not a weekly cron you forget exists.
Signups stall and you can't work out why. Then you find a week of welcome and password-reset emails sitting in spam, because your sending IP landed on Spamhaus. Turn on the DNSBL check for your mail host and a newly-listed alert reaches you on the next run, not after a week of users who never confirmed their accounts.
A client's contact form and order confirmations run off a mail IP you set up months ago and never think about. A neighbor on the shared block starts spamming, the whole range gets listed, and the receipts vanish into junk. Point the DNSBL check at the mail hostname that resolves to that IP and you can hear about it before the client emails asking why customers say they got nothing.
You run mail across dozens of sending IPs for hundreds of clients, and reputation isn't something you eyeball. Restrict each monitor to the lists that matter for its IPs (via the API) and you get a reputation view across the whole estate: which IPs are clean, which just got listed, on which blacklist. Account managers answer 'are any of our sending IPs listed?' from the dashboard instead of a manual lookup.
Shared sending IPs are a reputation liability. One abusive customer can list a whole range and tank deliverability for everyone on it. Sell IP-reputation monitoring across your customer base under your own brand and domain. Newly-listed alerts wear your name, so you can spot a dirty IP and move the offender before clean customers start bouncing, on the same platform you already resell uptime on.
Import the monitors you already run in another tool. What comes across depends on the provider. Run both side by side for 24 hours or 7 days before you switch.
The importer opens in your workspace once you have access.
Get early accessMXToolbox is something you remember to open after the damage is done. Hoppla runs the blacklist sweep on a schedule and alerts on the transition, so a newly-listed IP reaches you as a notification rather than a manual check you have to think to perform. And it lives on the same monitor as your uptime, SSL and DNS checks, not in a separate browser tab.
No, and the split is deliberate. A DNSBL listing hurts email deliverability and sending reputation; it doesn't take your site down. So it raises a WARNING, never a downtime incident: it doesn't start on-call escalation and never shows as an outage on a public status page. It's real and worth acting on, so it still notifies you, just not as a 503 that isn't happening.
It only alerts on changes. Hoppla compares each run to the last and notifies on newly-listed and newly-delisted transitions: an alert when an IP appears on a list, another when it drops off, not a reminder every run. If a particular list is noisy for your IPs, restrict the monitor to a subset via the API and drop it.
Yes, through the API. The default is all 20, but you can restrict a monitor to whatever subset matters for your IPs: keep the heavyweights like Spamhaus and Barracuda, drop the ones that aren't relevant to you. The check then warns only on the lists you chose to watch.
Checks, alerts and status pages in one workspace. Now in early access: join the list for an invite.