If your email deliverability suddenly collapses, there are roughly five reasons it could have happened. Four of them you can audit statically—DMARC, SPF, DKIM, and content heuristics. The fifth is harder to see: your sending IP or domain has landed on a Real-time Blocklist (RBL / DNSBL), and some receiving mail server is using that list to reject or quarantine your mail.
There are hundreds of RBLs. Most don't matter. Maybe 30 do. And the two or three that matter most (Spamhaus in particular) carry enough weight that being on one of their lists is the difference between 95% inbox and 20% spam-folder.
The problem is that checking an IP against 30 RBLs by hand is miserable. Each list has its own DNS zone (zen.spamhaus.org, b.barracudacentral.org, dnsbl.sorbs.net, etc.), each returns its own return-code semantics, and you have to construct and send the reverse-IP lookup correctly for every one. MXToolbox's bulk blacklist check costs $149/month. Spamhaus Technology sells an API but it's enterprise-gated. The free web tools are one-IP-at-a-time.
We built the NexGenData Email RBL Checker because we manage 80+ sending IPs across our own and clients' infrastructure and needed to check them all, daily, for roughly pocket change. This post walks through the 30 blocklists it queries, how reputation scoring works, how to handle the classic false positives (the 8.8.8.8 open-resolver case is a great teaching example), and how to run it with cURL or Python.
What RBLs Actually Do (and Why They Matter)
A DNSBL (DNS Blocklist, sometimes "RBL" for the original "Realtime Blackhole List") is a DNS zone that returns A records for IPs or domains the operator has classified as abusive. Example: to check whether 192.0.2.10 is on Spamhaus ZEN, a mail server does this query:
dig +short 10.2.0.192.zen.spamhaus.org
If no answer, the IP is clean on that list. If there's a response (typically 127.0.0.x), the IP is listed, and the specific return code tells you which sublist (ZEN aggregates SBL, XBL, PBL, and CSS).
Mail servers around the world query these lists at SMTP receive time. If your IP is listed, the receiving server rejects your mail—often with a 5xx permanent failure that generates a bounce, which in turn feeds back into your sending platform's suppression list.
Being on an RBL isn't an abstract reputation metric. It's the literal mechanism by which your mail gets rejected at the network level.
Which RBLs Actually Matter
Not all 200+ RBLs are equally important. A rough taxonomy:
- Must-monitor (cause actual rejection at major receivers): Spamhaus ZEN, Spamhaus DBL, Barracuda, UCEPROTECTL1, SpamCop, SORBS aggregated
- Important but less universal (cause rejection at subsets of receivers): SpamRats, Mailspike, PSBL, URIBL, SURBL
- Informational / regional (don't cause rejection but indicate risk): Composite Blocking List (CBL, now part of XBL), DroneBL, Team Cymru's bogons/malware lists
- Noise or historical (listed by almost no receivers, frequent false positives, or defunct): Most of the long tail, including some that shut down years ago but still have running DNS
The actor queries 30 lists, weighted toward the Must-Monitor and Important tiers, skipping the noise. The exact 30 are enumerated below.
The 30 RBLs the Actor Queries
| RBL Zone | Operator | Category | Notes | |----------------------------------|--------------------|----------------|--------------------------------------| | zen.spamhaus.org | Spamhaus | IP, aggregated | SBL+XBL+PBL+CSS combined zone | | dbl.spamhaus.org | Spamhaus | Domain | Domain blocklist (for sender domains)| | sbl.spamhaus.org | Spamhaus | IP | Spam sources | | xbl.spamhaus.org | Spamhaus | IP | Exploited hosts | | pbl.spamhaus.org | Spamhaus | IP | Policy: dynamic ranges | | b.barracudacentral.org | Barracuda | IP | Major receiver-side list | | dnsbl.sorbs.net | SORBS | IP, aggregated | Multiple sub-zones | | spam.dnsbl.sorbs.net | SORBS | IP | Spam sources only | | problems.dnsbl.sorbs.net | SORBS | IP | Misconfigured / abusive | | dnsbl-1.uceprotect.net | UCEPROTECT | IP | Level 1: direct sources | | dnsbl-2.uceprotect.net | UCEPROTECT | IP | Level 2: neighborhoods (risky) | | dnsbl-3.uceprotect.net | UCEPROTECT | IP | Level 3: whole ASNs (very risky) | | bl.spamcop.net | SpamCop | IP | User-reported spam | | all.spamrats.com | SpamRats | IP | RATS spam sources | | dyna.spamrats.com | SpamRats | IP | Dynamic IP RATS | | noptr.spamrats.com | SpamRats | IP | No reverse DNS | | bl.mailspike.net | Mailspike | IP | Reputation, major EU receiver use | | z.mailspike.net | Mailspike | IP | Zero tolerance | | psbl.surriel.com | PSBL | IP | Passive spam block list | | ix.dnsbl.manitu.net | Manitu | IP | NiX Spam aggregator | | dnsbl.dronebl.org | DroneBL | IP | Compromised hosts / botnets | | cbl.abuseat.org | CBL (Spamhaus) | IP | Composite blocking list | | truncate.gbudb.net | GBUdb | IP | Truncate-aggressive sources | | dnsbl.cobion.com | Cobion | IP | IBM-origin, enterprise receiver use | | dnsbl.justspam.org | JustSpam | IP | Spam source reports | | ubl.unsubscore.com | Lashback | IP | Bypassed-unsubscribe signal | | korea.services.net | Korean KISA | IP | APAC regional receiver relevance | | multi.uribl.com | URIBL | Domain | URIs in message bodies | | multi.surbl.org | SURBL | Domain | Domains appearing in spam | | bogons.cymru.com | Team Cymru | IP | Unallocated / bogon ranges |
Thirty zones, seven operators, spanning IP blocklists, domain blocklists, and URI blocklists. Enough coverage that if you're listed somewhere that's affecting real-world delivery, the actor will see it.
How the Scoring Works
Raw "you're on N lists out of 30" isn't useful as a single metric. A domain listed only on UCEPROTECT Level 3 (whole-ASN) might be completely fine in practice. A domain listed on Spamhaus ZEN is definitely not fine.
The actor computes a reputationScore (0-100, higher is worse) and a simple grade:
| Weight | Zone | Reasoning | |--------|------------------------------------------------|---------------------------------| | 30 | Spamhaus ZEN / SBL / XBL / CSS | Highest receiver adoption | | 20 | Barracuda | Major receiver coverage | | 15 | Spamhaus DBL (for domain checks) | Domain-level, high adoption | | 12 | SpamCop, Mailspike Z, CBL | Significant receiver coverage | | 8 | UCEPROTECT-1, SORBS spam, SpamRats | Regional/specific adoption | | 5 | Everything else in the IP/domain tiers | Informational / low impact | | 3 | UCEPROTECT-2/3, bogon lists | Context signals, not decisive |
A score of 0 is clean everywhere. A score over 30 means you're on at least one heavyweight list and should treat it as an incident. Scores 5-15 usually indicate an informational listing worth investigating but not panicking about.
Grades: A = 0-4 (clean), B = 5-14 (minor listings), C = 15-29 (investigate), D = 30-59 (heavy reputation damage), F = 60+ (don't send mail from this IP until remediated).
The 8.8.8.8 False-Positive Teaching Example
Here's a classic one. Someone checks 8.8.8.8 (Google's public DNS) against a stack of RBLs and sees it's listed on several. "Google's DNS is a spammer?" No. 8.8.8.8 is an open resolver. Some DNSBLs list open resolvers (and occasionally open relays) because those are abuse vectors, not because the IP sends spam.
This is a legitimate listing for what the RBL says it lists, but it is not a signal that mail from that IP would get rejected, because:
- No mail server should be sending SMTP from 8.8.8.8—that's a DNS server.
- Receiving mail servers don't query open-resolver lists to decide whether to accept mail.
The actor handles this by distinguishing between sender-reputation lists (which would cause mail rejection) and infrastructure-signal lists (which are informational). Listings on infrastructure-signal lists don't contribute to the reputationScore.
Concretely, 8.8.8.8's output looks like:
{
"target": "8.8.8.8",
"type": "ip",
"reputationScore": 0,
"grade": "A",
"listings": [
{
"zone": "truncate.gbudb.net",
"listed": true,
"category": "infrastructure_signal",
"weight": 0,
"note": "Open resolver, not a mail-sender signal"
}
],
"summary": {
"listedCount": 1,
"listedOnHeavyweight": false,
"actionable": false
}
}
Listed, but actionable: false. No panic required.
This kind of interpretation is what turns a raw RBL dump into something useful.
Related guides on NexGenData
Explore more tools and guides in this category:
- Public Registry Data Tools - full directory - WHOIS, RDAP, DNS, DMARC, RBL, and other open-data registry tooling
- Bulk Domain WHOIS Lookup - API Alternatives to Whois.com (2026) - bulk WHOIS lookup alternatives to Whois.com
- DNS Propagation: Why 15 Resolvers Matter - why 15 resolvers matter for DNS checks
- DMARC/SPF/DKIM Bulk Auditor for $0.005 Per Domain - DMARC/SPF/DKIM auditing for $0.005/domain
Try It: Single IP with cURL
curl "https://api.apify.com/v2/acts/MXK7SHIIhrJ7ntLtr/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
-X POST \
-H 'Content-Type: application/json' \
-d '{
"targets": ["192.0.2.10"],
"includeDomainLists": false,
"includeInfrastructureSignals": true
}'
Clean-IP response:
[
{
"target": "192.0.2.10",
"type": "ip",
"reputationScore": 0,
"grade": "A",
"listings": [],
"notListedCount": 30,
"summary": {
"listedCount": 0,
"listedOnHeavyweight": false,
"actionable": false
}
}
]
Listed-IP response:
[
{
"target": "203.0.113.55",
"type": "ip",
"reputationScore": 42,
"grade": "D",
"listings": [
{
"zone": "zen.spamhaus.org",
"listed": true,
"category": "heavyweight",
"weight": 30,
"returnCode": "127.0.0.3",
"returnCodeMeaning": "SBL - spam source",
"removalUrl": "https://www.spamhaus.org/query/ip/203.0.113.55"
},
{
"zone": "bl.spamcop.net",
"listed": true,
"category": "major",
"weight": 12,
"returnCode": "127.0.0.2"
}
],
"summary": {
"listedCount": 2,
"listedOnHeavyweight": true,
"actionable": true,
"primaryIssue": "Listed on Spamhaus SBL (spam source)"
}
}
]
The removalUrl for Spamhaus points directly to the delisting tool. That's the action you'd take next.
Bulk Mode: Check an Entire Sending Infrastructure in Python
My most common use: a daily sweep of every sending IP I care about.
import os
from apify_client import ApifyClient
client = ApifyClient(os.environ["APIFY_TOKEN"])
# All my sending IPs across SendGrid, Mailgun, self-hosted, and client setups
sending_ips = [
"198.51.100.10", "198.51.100.11", "198.51.100.12",
"203.0.113.20", "203.0.113.21",
# ... 70+ more
]
# Your own sending domains if you want DBL/URIBL/SURBL checks too
sending_domains = [
"mail.example.com",
"send.example.com",
# ... more
]
run = client.actor("nexgendata/email-rbl-checker").call(run_input={
"targets": sending_ips + sending_domains,
"includeDomainLists": True,
"includeInfrastructureSignals": False,
})
results = list(client.dataset(run["defaultDatasetId"]).iterate_items())
# Any heavyweight listings = immediate action
actionable = [r for r in results if r["summary"]["actionable"]]
if actionable:
print(f"URGENT: {len(actionable)} targets with actionable listings:")
for r in actionable:
print(f" {r['target']} (grade {r['grade']}, score {r['reputationScore']})")
print(f" {r['summary']['primaryIssue']}")
else:
print(f"All {len(results)} targets clean on heavyweight lists.")
# Full report for all non-clean
problematic = [r for r in results if r["listings"]]
for r in problematic:
print(f"\n{r['target']} - grade {r['grade']} (score {r['reputationScore']})")
for l in r["listings"]:
print(f" [{l['category']}] {l['zone']}"
+ (f" -> {l.get('returnCodeMeaning', '')}" if l.get('returnCodeMeaning') else ""))
Run that on cron daily. Wire the "actionable" branch to Slack or PagerDuty. That's the core workflow.
Node.js: On-Demand Check in a Support Tool
Internal support tools benefit from a "check this customer's sending IP" button. Node/Express pattern:
app.post("/api/check-reputation", async (req, res) => {
const { target } = req.body;
const apiRes = await fetch(
`https://api.apify.com/v2/acts/MXK7SHIIhrJ7ntLtr/run-sync-get-dataset-items?token=${process.env.APIFY_TOKEN}`,
{
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
targets: [target],
includeDomainLists: true,
}),
}
);
const [result] = await apiRes.json();
res.json({
grade: result.grade,
score: result.reputationScore,
actionable: result.summary.actionable,
listings: result.listings.map(l => ({
list: l.zone,
category: l.category,
meaning: l.returnCodeMeaning,
removalUrl: l.removalUrl,
})),
});
});
Now your support team can check a customer's IP reputation in one click rather than navigating to MXToolbox and pasting.
Real Use Cases I Use This For
1. Daily Sweep of Sending Infrastructure
Every morning at 06:00 UTC the actor runs against my full IP + domain list. If any heavyweight listing appears, Slack alert. Most days: zero alerts. When a listing does appear, I know within hours, not days-later-when-customers-complain.
2. Onboarding Checks for Agency Clients
New client onboarding includes running their sending IPs and domains through the actor. About 15% of agency onboardings reveal pre-existing listings the client didn't know about. That's a concrete first-week deliverable.
3. Post-Migration Verification
When a customer migrates from an old ESP to a new one (or from SendGrid to Mailgun or self-hosted), you want to confirm the new IPs have clean reputation before routing production traffic through them. Actor check, clean score, ship it.
4. Supporting a Deliverability Incident
A customer complains "my emails aren't arriving at Gmail." Run their sending IP and domain through the actor. If listed on Spamhaus, you have the root cause and the removalUrl in one response. If not listed, you can confidently say "not RBL-related" and move on to other possibilities (DMARC alignment, content, authentication failures) without wasting an hour.
5. Sales Pre-qualification for Deliverability Services
If you sell deliverability services, running a prospect's public sending IPs through the actor lets you show up to the sales call with "here's what's currently listed and we can help you fix it." Concrete value, pre-demo.
Pricing: About $0.01 Per Target
| Tool | Price | Bulk API | Notes | |----------------------------|-----------------|----------|-------------------------------| | MXToolbox (Monitoring) | $149+/mo | Paid tier| UI-first | | HetrixTools (RBL Monitor) | $8-50+/mo | Limited | Paid tiers for monitoring | | Spamhaus Technology | Enterprise | Yes | Gated, priced for enterprise | | Free web tools (MXToolbox lookup, etc.) | Free | No | One-target, manual | | NexGenData RBL Checker | ~$0.01/target | Yes | Scripted, bulk, scored |
80 IPs checked daily is about $0.80/day = $24/month. Way cheaper than MXToolbox, and you own the workflow.
Answering the Common Questions
Q: Why 30 and not "all of them"? A: Most of the long tail of RBLs either have near-zero receiver adoption (being on them doesn't cause rejection), are defunct, or have such high false-positive rates that listings are noise. The 30 selected are the ones that, in my experience and in published sender-reputation research, actually influence real delivery.
Q: Can it check both IPs and domains in one call? A: Yes. Mix them freely in the targets array. The actor detects each entry's type and runs the appropriate set of zones (IP lists for IPs, DBL/URIBL/SURBL for domains).
Q: What about IPv6? A: Supported. The actor constructs the reverse-lookup name correctly for IPv6 per RFC 5782. Note that IPv6 coverage across RBLs is less complete than IPv4; Spamhaus and Mailspike are the most consistent for IPv6.
Q: Does it submit delisting requests automatically? A: No. Each RBL operator has its own delisting process, and automating that blindly is risky (and some operators explicitly forbid it). The actor returns the removalUrl where applicable so you can kick off the process manually with full context.
Q: How fresh is the data? A: Each check is a live DNS query at run time. No caching on the actor side. The answers are as fresh as the RBL zone itself, which for most zones means sub-minute freshness.
Q: Will the actor's queries themselves get me listed? A: No. The actor does standard DNS lookups at reasonable rates. DNSBL operators are used to reputation-checking tools doing exactly this.
Related NexGenData Actors for a Full Deliverability Stack
Sender reputation is one of four pillars of email delivery. Here's the full stack:
- Email DMARC Auditor — DMARC, SPF, DKIM bulk audit across your sending domains. If auth is broken, RBL status won't save you.
- DNS Propagation Checker — Confirm that your mail-related DNS changes (new SPF, new MX) are propagated across 15 resolvers globally before cutting over.
- Google Cache Viewer — Historical snapshots of sender domains when investigating how a reputation issue developed.
- Website Performance Monitor — If your click-tracking domains are slow, engagement metrics suffer, which feeds back into sender reputation.
Wired together, these four actors are a full replacement for MXToolbox + Valimail + whatsmydns + Spamhaus lookups, for a small fraction of the combined cost.
Try It
One IP, right now:
curl "https://api.apify.com/v2/acts/MXK7SHIIhrJ7ntLtr/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
-X POST \
-H 'Content-Type: application/json' \
-d '{"targets": ["your.sending.ip"]}'
Or the UI for a list paste: apify.com/nexgendata/email-rbl-checker.
Apify's free tier includes $5 in credits—that's ~500 RBL checks, plenty to sweep your sending infrastructure and see where you stand today.
Want more tools like this? NexGenData ships Apify actors that replace overpriced deliverability SaaS—subscribe to the newsletter for new releases and deliverability playbooks.
Publish your own actors on Apify and earn alongside me: apify.com.
Resources:
Top comments (0)