원시 DNS에서 하나의 컬로 IP가 블랙리스트에 있는지 확인하는 방법 (DNSBL)

작성자

카테고리:

← 피드로
DEV Community · CodeLong888 · 2026-07-29 개발(SW)

Your emails start bouncing, or a website suddenly challenges every request from your server. Very often the reason is boring: your IP landed on a DNSBL and you did not know.

A DNSBL (DNS-based blackhole list) is a reputation database you query over plain DNS. Mail servers do this on every incoming connection. Spamhaus, SpamCop, Barracuda and a dozen others each run their own list, their own criteria, and their own delisting process.

The raw mechanic (it is just DNS)

To check an IP against a list, you reverse its octets and query them as a subdomain of the list’s zone. Checking 127.0.0.2 against SpamCop looks like this:

$ nslookup -type=A 2.0.0.127.bl.spamcop.net

Name:    2.0.0.127.bl.spamcop.net
Address:  127.0.0.2

Enter fullscreen mode Exit fullscreen mode

If the name resolves (typically to something in 127.0.0.0/8), the IP is listed. If you get NXDOMAIN, it is clean on that list. 127.0.0.2 is the standard test address that every DNSBL keeps permanently listed, which is why the query above always “hits” and is a handy way to confirm your resolver can reach a list at all.

That last part matters more than people expect. Some lists, Spamhaus in particular, refuse queries coming from big public resolvers like 8.8.8.8 or 1.1.1.1. You can query them and get nothing back, conclude “clean”, and be wrong. If you script your own checker, query through your own resolver and treat “no answer” as unknown, not clean.

Checking a dozen lists with one request

Checking one list tells you little. An IP that is clean on SpamCop can be listed on UCEPROTECT or PSBL. To do it properly you loop over 10 to 15 zones, handle each list’s return-code semantics, and handle the resolver problem above.

Or you let one endpoint do it. I run a free, keyless API that fans out the DNS queries server-side:

$ curl "https://hackmyip.com/api/blacklist?ip=1.1.1.1"

Enter fullscreen mode Exit fullscreen mode

{
  "success": true,
  "data": {
    "ip": "1.1.1.1",
    "total_lists": 12,
    "total_checked": 10,
    "unavailable_count": 2,
    "listed_count": 0,
    "clean": true,
    "status": "CLEAN",
    "results": [
      { "name": "Barracuda", "zone": "b.barracudacentral.org", "listed": false, "status": "not_listed" },
      { "name": "SpamCop", "zone": "bl.spamcop.net", "listed": false, "status": "not_listed" },
      { "name": "Spamhaus ZEN", "zone": "zen.spamhaus.org", "listed": false, "status": "unavailable" }
    ]
  }
}

Enter fullscreen mode Exit fullscreen mode

(Response trimmed; the real one returns all 12 lists: Spamhaus ZEN, Barracuda, SpamCop, Spam Eating Monkey, UCEPROTECT L1, Composite Blocking List, Invaluement, PSBL, Mailspike, Truncate, WPBL, and Suomispam.)

One honest detail I want to point out because most checkers get it wrong: notice total_checked: 10 versus total_lists: 12, and "status": "unavailable" on Spamhaus in that run. When a zone cannot be reached from the edge location serving your request, the API says so instead of silently reporting “clean”. If you build on top of this, treat unavailable as “check this one another way”, not as a pass.

There is also a browser version of the same check at hackmyip.com/blacklist if you just want to paste an IP and look, and the full endpoint list lives in the API docs. No key, no signup, CORS enabled, so you can call it from a frontend too.

If your IP is actually listed

  1. Fix the cause first. A listing almost always has a reason: a compromised machine on your network, a web form being abused to send mail, an open relay, or a neighbor on the same shared IP range. Delisting without fixing the cause gets you relisted fast.
  2. Then go to each list’s own delisting page. There is no central authority; every list has its own form and its own rules.
  3. Some lists age entries out automatically after the abuse stops, others keep you until you ask. Recheck after a day or two.

If you are on a cloud provider or CGNAT, you may simply have inherited a previous tenant’s reputation. Same playbook applies, and it is a good argument for checking an IP before you build anything mail-related on it.

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다