Implementing DNSBL lookups from scratch means coding DNS reverse-address queries, querying multiple blacklist zones in parallel, and handling NXDOMAIN vs. real errors without misreporting a clean IP as blacklisted. The IP Reputation & Blacklist Checker API wraps all of that in a single GET — pure Node.js dns/promises, no external API key, seven DNSBL sources in one call.
GET /api/v1/check?ip=<ip> queries Spamhaus ZEN, Barracuda, SORBS, SpamCop, Spamhaus SBL, Spamhaus XBL, and UCEPROTECT Level 1 simultaneously and returns a listed boolean, a listedCount, and a per-blacklist breakdown:
curl --request GET \
--url 'https://ip-reputation-blacklist-checker-api.p.rapidapi.com/api/v1/check?ip=1.2.3.4' \
--header 'x-rapidapi-key: YOUR_RAPIDAPI_KEY' \
--header 'x-rapidapi-host: ip-reputation-blacklist-checker-api.p.rapidapi.com'
Each entry in blacklists contains name, zone, listed (true/false/null for failed lookups), and returnCodes — the raw DNS A-record codes that each DNSBL returns when an IP is listed.
const res = await fetch(
'https://ip-reputation-blacklist-checker-api.p.rapidapi.com/api/v1/check?ip=1.2.3.4',
{ headers: { 'x-rapidapi-key': process.env.RAPIDAPI_KEY, 'x-rapidapi-host': 'ip-reputation-blacklist-checker-api.p.rapidapi.com' } }
);
const { listed, listedCount, blacklists } = await res.json();
For bulk checks, POST /api/v1/check/batch accepts an ips array (max 10) and returns one result object per IP — useful for scrubbing a list of sender IPs before a transactional mail run. Results are cached for 5 minutes, and GET /api/v1/lists returns the full list of active DNSBL zones if you need to inspect what's being queried.
Free tier on RapidAPI: https://rapidapi.com/danieligel/api/ip-reputation-blacklist-checker-api
Do you run DNSBL checks on inbound IPs, outbound sender IPs, or both?
Top comments (0)