GLOBUS.App

DNS Blacklist Check API — DNSBL Lookup for Developers

DNS Blacklist Check API DNSBL Lookup for Developers

What Are DNS Blacklists?

A DNS-based Blackhole List (DNSBL Lookup) is a real-time database of IP addresses known to send spam, host malware, operate open proxies, or otherwise behave maliciously on the internet. Mail servers, firewalls, and anti-abuse systems query these lists during connection handling to decide whether to accept, reject, or throttle traffic from a given source. The check mechanism is elegantly simple: the querying system performs a DNS lookup for a reversed form of the target IP against the blacklist’s domain — if a record resolves, the IP is listed.

Dozens of independent DNSBL operators maintain their own lists — among the most widely referenced are Spamhaus, SORBS, Barracuda, and URIBL — each with different listing criteria, update frequencies, and removal processes. An IP may be clean on one list and flagged on several others simultaneously, which is why checking against multiple blacklists in a single operation matters.

The DNS Blacklist Check API by GLOBUS.studio automates this multi-list lookup in a single request, returning a consolidated result in plain text or JSON format. The average latency of 800ms reflects the real cost of querying multiple external DNS blacklists in parallel — an operation that cannot be meaningfully accelerated at the client side.

API Endpoint and Parameters

GET https://api.globus.studio/v2/dnsbl?ip={address}&format={format}
  • ip — the IPv4 address to check against DNS blacklists
  • format — response format: json or plain

Full parameter reference and live testing are available on the DNS Blacklist Check API documentation page.

Request and Response Examples

Clean IP — JSON

GET /v2/dnsbl?ip=8.8.8.8&format=json

{
  "ip": "8.8.8.8",
  "listed": false,
  "blacklists": []
}

Listed IP — JSON

GET /v2/dnsbl?ip=1.2.3.4&format=json

{
  "ip": "1.2.3.4",
  "listed": true,
  "blacklists": ["zen.spamhaus.org", "bl.spamcop.net"]
}

Plain Text Response

GET /v2/dnsbl?ip=1.2.3.4&format=plain

Listed: zen.spamhaus.org, bl.spamcop.net

Common Use Cases

Email Server Deliverability Monitoring

A mail server’s sending IP is its most critical deliverability asset. The moment that IP appears on a major blacklist — Spamhaus ZEN, SpamCop, or Barracuda — outbound email begins bouncing or landing in spam folders across a large share of recipients. Automated DNSBL Lookup on a scheduled basis (hourly for high-volume senders) provide early warning before a listing causes measurable damage to campaign performance or transactional email delivery. The API’s JSON response makes it straightforward to build alerting logic: if listed is true, trigger a notification to the postmaster immediately.

Inbound Connection Filtering

Applications that accept user-submitted content — comments, form submissions, file uploads, API registrations — can check the submitter’s IP against DNSBL lists as part of the request processing pipeline. An IP listed on multiple blacklists is a strong signal of automated or malicious traffic and can be silently rejected, rate-limited, or flagged for manual review without exposing the rejection reason to the requester.

WordPress Anti-Spam and Security Plugins

WordPress comment spam, contact form abuse, and brute-force login attempts frequently originate from IPs that are already listed on DNSBL databases (DNSBL Lookup). A security plugin can call the API via wp_remote_get() during the pre_comment_approved or authenticate hooks, scoring the incoming IP against blacklist results before WordPress processes the request further. Combined with a transient cache keyed on the IP, the 800ms lookup cost is paid once per IP and then served from cache for subsequent requests — keeping the site responsive under sustained attack traffic.

New Server Provisioning Checks

When a new cloud instance or dedicated server is provisioned, its public IP may have been previously assigned to a bad actor and still carry blacklist entries from that prior use. Running a DNSBL check immediately after provisioning — before configuring email or any outbound service — identifies inherited reputation problems early enough to request a different IP from the provider before any infrastructure is built around it.

SaaS Onboarding Risk Assessment

SaaS platforms that allow users to connect their own sending infrastructure — SMTP relays, outbound webhooks, email service configurations — can validate the submitted IP or domain as part of the onboarding flow. A blacklist hit at setup time prompts the user to investigate and resolve the issue before the integration goes live, preventing reputation problems from propagating into shared platform infrastructure.

Fraud and Abuse Pre-Screening

DNSBL listings correlate strongly with botnet membership, compromised hosts, and open proxies — all infrastructure commonly used in payment fraud, account takeover, and credential stuffing campaigns. Adding a DNSBL check (DNSBL Lookup) to a fraud scoring pipeline provides a fast, low-cost signal that is independent of behavioral analysis and session history. An IP listed on multiple high-confidence blacklists can immediately elevate a transaction’s risk score without waiting for pattern-matching logic to accumulate evidence.

Hosting Provider and ISP Monitoring

Network operators and managed hosting providers responsible for large IP ranges need continuous visibility into which addresses in their inventory carry blacklist entries. Scripted DNSBL polling across the IP range — batched and parallelized — builds an up-to-date reputation map that informs abuse desk prioritization, customer notifications, and proactive delisting requests before affected customers file support tickets.

Integration Examples

cURL

curl "https://api.globus.studio/v2/dnsbl?ip=1.2.3.4&format=json"

JavaScript (Fetch API)

const res  = await fetch('https://api.globus.studio/v2/dnsbl?ip=1.2.3.4&format=json');
const data = await res.json();

if (data.listed) {
  console.warn('IP is blacklisted on:', data.blacklists.join(', '));
} else {
  console.log('IP is clean');
}

PHP

$ip       = '1.2.3.4';
$url      = "https://api.globus.studio/v2/dnsbl?ip={$ip}&format=json";
$response = json_decode(file_get_contents($url), true);

if ($response['listed']) {
    echo 'Listed on: ' . implode(', ', $response['blacklists']);
} else {
    echo 'Clean';
}

Python

import requests

data = requests.get(
    'https://api.globus.studio/v2/dnsbl',
    params={'ip': '1.2.3.4', 'format': 'json'}
).json()

if data['listed']:
    print('Blacklisted on:', ', '.join(data['blacklists']))
else:
    print('Clean')

WordPress (PHP) — Cached DNSBL Check

function globus_dnsbl_check( $ip ) {
    $cache_key = 'dnsbl_' . md5( $ip );
    $cached    = get_transient( $cache_key );
    if ( false !== $cached ) {
        return $cached;
    }
    $response = wp_remote_get(
        'https://api.globus.studio/v2/dnsbl?ip=' . rawurlencode( $ip ) . '&format=json'
    );
    $data = json_decode( wp_remote_retrieve_body( $response ), true );
    set_transient( $cache_key, $data, HOUR_IN_SECONDS );
    return $data;
}

// Usage in a comment or login hook:
$result = globus_dnsbl_check( $_SERVER['REMOTE_ADDR'] );
if ( ! empty( $result['listed'] ) ) {
    wp_die( 'Your IP address has been flagged. Please contact the site administrator.' );
}

Node.js — Monitoring Script

const fetch = require('node-fetch');

const ips = ['1.2.3.4', '5.6.7.8', '9.10.11.12'];

async function checkAll(ips) {
  const results = await Promise.all(
    ips.map(ip =>
      fetch(`https://api.globus.studio/v2/dnsbl?ip=${ip}&format=json`)
        .then(r => r.json())
    )
  );
  results
    .filter(r => r.listed)
    .forEach(r => console.warn(`BLACKLISTED: ${r.ip} →`, r.blacklists.join(', ')));
}

checkAll(ips);

Understanding the 800ms Latency

Unlike the sub-5ms endpoints in the GLOBUS.studio API suite, the DNSBL checker (DNSBL Lookup) has an average latency of 800ms — and for good reason. Each check requires the API to query multiple independent DNS blacklist operators across the internet, wait for their authoritative DNS servers to respond, and aggregate the results before returning. This is irreducible network I/O; no amount of server-side optimization can make external DNS queries faster than the speed of light and the round-trip time to geographically distributed nameservers.

For most use cases this latency is entirely acceptable: DNSBL checks are not called on every page view but at specific control points — form submissions, account registrations, inbound connections, or scheduled monitoring jobs. The transient caching pattern shown in the WordPress example above is the right approach for any high-traffic integration: pay the 800ms cost once per IP per hour, serve every subsequent check from cache in microseconds.

Test all response states and review the full field reference on the DNSBL Lookup API documentation page.

GLOBUS.App

GLOBUS.studio