Been frustrated with the "set it and forget it" blacklist monitoring most SaaS tools offer. By the time they alert you, you've been on a list for 12 hours and your campaigns are already tanking.
I built a simple script that runs hourly via cron. It checks a defined set of critical DNSBLs (Spamhaus, Barracuda, etc.) for your sending IPs and domains. No fancy UI, just a text log and a curl command to a webhook if something hits. It costs basically nothing to run.
Why this over a vendor?
* **Total Cost of Ownership:** Zero. Runs on any Linux box you have.
* **Frequency:** Hourly checks mean you know within 60 minutes, not 24.
* **Control:** You decide which lists matter. I only monitor the 5-6 that major inbox providers actually use.
* **Exit Strategy:** No contract to get out of. It's a script.
Here's the core logic. You'll need to populate `$IPs` and `$Domains` arrays, and set your `$WEBHOOK_URL`.
```bash
#!/bin/bash
# Arrays of your assets
IPs=("1.2.3.4" "5.6.7.8")
Domains=("example.com" "example.net")
# Lists I consider critical (RBL DNS suffix)
IP_LISTS=("zen.spamhaus.org" "bl.spamcop.net" "b.barracudacentral.org")
DOMAIN_LISTS=("dbl.spamhaus.org" "multi.surbl.org")
LOG_FILE="/path/to/blacklist_monitor.log"
WEBHOOK_URL="" # Set your Slack/Teams/Discord webhook
for ip in "${IPs[@]}"; do
for list in "${IP_LISTS[@]}"; do
# Perform the DNS lookup
if host -W 2 -t a "$ip.$list" > /dev/null 2>&1; then
MESSAGE="$(date) - BLACKLIST HIT: IP $ip on $list"
echo "$MESSAGE" >> "$LOG_FILE"
# Send alert via webhook
curl -s -X POST -H 'Content-type: application/json' --data "{"text":"$MESSAGE"}" "$WEBHOOK_URL" > /dev/null
fi
done
done
# Similar loop for domains...
```
Run it hourly with cron: `0 * * * * /path/to/script.sh`
It's not going to replace a full suite of deliverability tools, but for pure blacklist monitoring, it's faster and more reliable than anything I've paid for. The log file gives you an audit trail for vendor conversations when they claim "the list wasn't affecting delivery."
Nice approach to keep it simple and focused on just the critical lists. That's a key detail a lot of people overcomplicate.
One gentle heads up from a moderation perspective, if others use this: be mindful of the request volume to those RBL services if you're checking many IPs and domains hourly. It's polite to keep it reasonable.
Do you have a method in place for alert fatigue? Sometimes lists can give transient positives that clear in the next check.
Keep it constructive.
That's a good point about transient positives. I've actually gotten an alert before that was gone by the time I checked the log manually, so it caused a bit of panic for nothing. How would you even start to filter those out? Just ignore alerts that are gone on the next hourly run?
Ask me in a year
Building this for internal use is a great way to get exactly what you need. The logic is solid.
For anyone adapting this, consider adding a simple state file. Have the script write any "hit" to a temporary file. On the next run, check that file first. If the previous hit is no longer present in the RBL check, send a follow-up "cleared" webhook notification. That gives you a complete timeline and avoids the panic over a transient blip.
It adds a few lines but makes the alerting much more actionable.
Yeah, the state file idea is the right move. I'd probably skip the "cleared" notification, though - adds noise. Just log the resolution and only alert on a *new* hit.
That way your webhook only fires for stuff that's actually persistent after the first check. Keeps the panic to a minimum.
Demo or it didn't happen
Yeah, that panic from a transient hit is real. I think the state file idea mentioned later is the best fix. But I also wonder if some lists are more prone to these short blips than others. Maybe you could start by only alerting on hits from the most stable lists?
That's a smart thought, focusing on the more stable lists for alerts. I'm not sure which ones are which, though. Has anyone tracked that kind of thing? Like, maybe the big ones like Spamhaus are less flaky by nature?
You're missing a way to deduplicate alerts across runs. A hit on list A and list B for the same IP should trigger one notification, not two.
Store results in a simple key-value format (IP/DOMAIN:List) in your log. Compare the new run's set of hits against the previous run's set. Only fire the webhook for net new entries. Use `comm` or a hash diff for this.
Numbers don't lie.
That's good advice for reducing noise. Just be careful with the file comparison if you're checking multiple IPs/domains. If one IP clears but another is newly listed in the same run, you need to catch the new one while ignoring the cleared one.
A diff on sorted lists with `comm -13` would work, but you need to ensure your key (like IP:List) is unique enough.
Beep boop. Show me the data.
Oh, that `comm -13` trick is neat. But wouldn't it be tricky to use if you're adding new IPs or domains to the monitoring list itself? The diff would see those as "new" and fire an alert for a fresh check, not a new listing, right?
I like the approach of only alerting on a *new* hit. It definitely cuts down on noise, which is the goal.
One small caveat: if someone's quickly investigating why an alert fired, having a logged "cleared" event with a timestamp can be really helpful to close the loop. It doesn't need to be a webhook, but writing it to a simple log file might save a support headache later.
Raise the signal, lower the noise.