ホーム › 解説記事

ブラックリスト監視の方法｜digとcron・APIで定期チェック

公開 2026-11-03 ／ 更新 2026-11-03 ／ 運営者 中澤祐樹

ブラックリスト監視は、送信に使うIPアドレスとドメインを複数のDNSBLへ定期的に照会し、「前回と結果が変わったときだけ」知らせる仕組みを作るのが基本です。

方法は大きく2つあります。ひとつは dig と cron で動く小さなスクリプトを自分で置く方法、もうひとつは判定サービスのAPIやWebhookに任せる方法です。どちらでも、Spamhaus などでは、公開リゾルバー経由の問い合わせが拒否されて誤った結果になる点と、エラーを示す応答を「掲載」と数えない点が肝心です。

リスト運営者の仕様は2026年11月時点の公式ページに基づいています。変わることがあるため、運用前に各公式ページも確認してください。DNSBLの仕組みそのものはDNSBL（RBL）とはで解説しています。

あなたのドメイン名・IPアドレスが、約345件のブラックリストに載っていないかを無料で確認できます。

監視の前に決めること：対象と照会するリスト

まず、何を監視するかを書き出します。

照会の形式は RFC 5782 で決まっています。IPv4はオクテットを逆順にしてリストのドメイン名を付け（192.0.2.99 なら 99.2.0.192.リスト名）、IPv6は16進数1桁ずつ逆順に並べた32個の要素にします。ドメインはそのままリスト名を後ろに付けます。載っていればAレコード（127.0.0.0/8 の範囲。慣例は 127.0.0.2）が返り、載っていなければ NXDOMAIN です。

リストはひとつに絞らず、受信側でよく使われる複数を見ます。どのリストが何を表すか、返ってきたコードの読み方はDNSBLの返却コードの意味にまとめています。

公開リゾルバー経由では正しく判定できない

自前で監視するときによくある失敗が、Google Public DNS（8.8.8.8）やCloudflare（1.1.1.1）などの公開リゾルバー経由で照会してしまうことです。Spamhausの公式FAQは次のように説明しています。

公式FAQの推奨は自前のDNSリゾルバーを用意することです。公開リゾルバーを使うしかない場合の選択肢として、Spamhausは Data Query Service（DQS）への移行も案内しています（無料で使える範囲は公式で確認してください）。どのリゾルバーで引いているかは、FAQが紹介している dig txt whoami.fastly.net で確かめられます。

また RFC 5782 は、リストは試験用に 127.0.0.2 を必ず載せ、127.0.0.1 は載せないと定め、利用側はこの試験用エントリを定期的に確かめるべきとしています。Spamhausの例では 2.0.0.127.zen.spamhaus.org を引くと 127.0.0.10・127.0.0.4・127.0.0.2 が返り、1.0.0.127.zen.spamhaus.org は NXDOMAIN になるのが正常です。監視スクリプトはまずこれを確かめ、おかしければその回の結果を捨てる作りにします。

方法1：digとcronで作る自前の監視スクリプト

次は、1つのIPv4アドレスを Spamhaus ZEN と SpamCop（bl.spamcop.net。掲載時は 127.0.0.2 を返すと公式に案内）に照会する最小限の例です。IPアドレスやリストは自分の環境に合わせて変えてください。

#!/bin/sh
# 自前のフルリゾルバー（例: 同じサーバーの unbound）に問い合わせる
RESOLVER=127.0.0.1
IP=192.0.2.10
ZONES="zen.spamhaus.org bl.spamcop.net"
REV=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

q() {
  out=$(dig +time=3 +tries=1 @"$RESOLVER" "$1" A) || { echo ERR; return; }
  case "$out" in
    *"status: NOERROR"*) a=$(printf '%s\n' "$out" | awk '$4=="A"{print $5}'); echo "${a:-NX}" ;;
    *"status: NXDOMAIN"*) echo NX ;;
    *) echo ERR ;;
  esac
}

for Z in $ZONES; do
  # テスト用エントリ（127.0.0.2）が掲載コードで引けなければ、この回の結果は信用しない
  case "$(q "2.0.0.127.$Z")" in
    127.255.255.*|NX|ERR) echo "$Z ERROR test-entry"; continue ;;
    127.*) ;;
    *) echo "$Z ERROR test-entry"; continue ;;
  esac
  A=$(q "$REV.$Z")
  case "$A" in
    NX)            echo "$Z CLEAN" ;;
    ERR)           echo "$Z ERROR no-answer" ;;
    127.255.255.*) echo "$Z ERROR $A" ;;
    127.*)         echo "$Z LISTED $A" ;;
    *)             echo "$Z ERROR unexpected $A" ;;
  esac
done

ポイントは次のとおりです。

cron では、結果を前回と比べて変化したときだけ通知します。

# 毎時0分に実行し、前回と結果が変わったときだけメールする（例）
0 * * * * /usr/local/bin/dnsbl-watch.sh > /var/tmp/dnsbl.now 2>&1; cmp -s /var/tmp/dnsbl.now /var/tmp/dnsbl.prev || mail -s "DNSBL status changed" you@example.com < /var/tmp/dnsbl.now; mv /var/tmp/dnsbl.now /var/tmp/dnsbl.prev

実行間隔は例です。Spamhausの無料利用は少量・非商用が前提で、多数のIPを頻繁に照会する規模になれば有償の提供形態が必要とされています。監視対象が増えたら、各リストの利用条件を確認してください。FAQは、結果が安定しているか何度か試して確かめることも勧めています。

方法2：DNSBLチェッカーのAPIでまとめて判定する

リゾルバーの用意や返却コードの解釈を自分で抱えたくない場合は、判定をサービス側に任せる方法があります。ここでは当サイトのAPI（v1）について、サーバー側の実装で確認できた仕様だけを書きます。利用ガイドは /api-docs、APIキーの発行は会員ページ /account です。会員登録はメールアドレスだけで、メールで届くログインリンクでログインします。

認証と上限

バッチ判定

POST /api/v1/batch に targets（ドメイン名・IPアドレスの配列）を送ります。

curl -X POST https://dnsblchecker.com/api/v1/batch \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"targets":["example.com"]}'

未判定の対象があれば 202 と batch_id が返るので、GET /api/v1/batch/{batch_id} を status が done になるまで数秒おきに取得します。結果の例（抜粋。数値やリスト名は説明用で、実際の判定結果ではありません）は次のとおりです。

{
  "batch_id": 1, "status": "done", "created": "2026-11-03 09:10:41", "count": 1, "pending": 0,
  "results": [
    {
      "target": "example.com", "type": "domain",
      "status": "done", "verdict": "listed",
      "checked_at": "2026-11-03 09:12",
      "lists_checked": 80, "listed_count": 1, "error_count": 4,
      "listed_on": [
        { "list": "ZapBL RHSBL", "zone": "rhsbl.zapbl.net", "response": "127.0.0.2" }
      ]
    }
  ]
}

Webhook監視

POST /api/v1/monitors に target と callback_url を登録すると、登録した対象を1日1回、キャッシュを使わずに新しく判定し（最初の判定は登録から1日ほどのうちに行われます）、初回（monitor.initial）と判定が listed／clean の間で変わったとき（monitor.status_changed）だけ、そのURLへJSONをPOSTします。

curl -X POST https://dnsblchecker.com/api/v1/monitors \
  -H "X-API-Key: $DNSBL_API_KEY" -H "Content-Type: application/json" \
  -d '{"target":"example.com","callback_url":"https://your-app.example/hooks/dnsbl"}'

通知の考え方：頻度・複数リスト・誤検知

鳴りすぎる監視は、やがて誰も見なくなります。

頻度

複数リストの扱い

誤検知と一時的な応答

掲載を検知したあとの動き方

  1. 結果を確かめる：リスト運営者自身の照会ページでも掲載を確認し、リスト名・時刻・表示された理由を記録します。
  2. 原因を直す：乗っ取り、フォームの悪用、感染、逆引き（PTR）の設定などを確認します。原因が残ったまま申請しても、再掲載されやすくなります。
  3. 各リストの手順で申請する：解除するかどうかの判断は各リスト運営者にあり、申請しても解除が約束されるわけではありません。共有IPのように自分で管理していないIPは、サーバー会社やプロバイダーに連絡します。
  4. 監視で解除を確かめる：受信側の独自フィルターもあるため、clean に戻ったあとも届き方を見守ります。

単発で状況を確かめたいときはブラックリストチェッカーで調べられます。原因の切り分けや申請が自力では難しいときは、相談窓口もご利用ください。届かないときの全体の流れはブラックリストでメールが届かないときの対処にまとめています。

自分での対応が難しいときは

解除申請の代行・コンサルティング・ご相談を受け付けている事業者を紹介しています（料金は 5万円〜）。解除はリスト運営元の判断で行われ、お約束するものではありません。

相談窓口へ

当サイトは掲載事業者から紹介料を受け取ることがあります。 運営者情報

よくある質問

8.8.8.8 で調べたら「載っていない」と出ました。安心してよいですか？

いいえ。Spamhausの公式FAQによると、公開リゾルバー経由では多くの場合 NXDOMAIN（未掲載）が返るため、載っていても未掲載に見えることがあります。自前のリゾルバーで照会するか、リスト運営者の照会ページで確認してください。

127.255.255.254 が返ってきました。掲載されたのですか？

いいえ。公開リゾルバーなどからの問い合わせを示すエラーコードで、掲載を意味しません。監視ではエラーとして記録し、掲載の通知は出さないようにします。

APIのバッチ判定を毎日呼べば、それで監視になりますか？

バッチは30日以内の判定結果があればそれを返すため、毎日の最新状態とは限りません。checked_at を確認するか、毎日新しく判定する Webhook 監視（POST /api/v1/monitors）を使ってください。

監視で掲載を見つけたら、すぐ解除申請すべきですか？

先に原因を直してください。原因が残ったまま申請しても、再掲載されやすくなります。解除の判断は各リスト運営者にあります。

参考にした公式ページ

本文の事実関係は、公開時点で次の公式ページに基づいて確認しています。仕様や運用は予告なく変わるため、重要な判断の前に各公式ページをご確認ください。

関連記事

DNSBLの返却コードの読み方：127.0.0.2の意味とエラー

DNSBLの返却コード（127.0.0.x）の読み方をRFC 5782と各リストの公式情報で解説。127.255.255.x、NXDOMAIN・SERVFAILの違いも。

Spamhausとは？解除方法をZEN・PBL・XBL・SBL・DBL別に解説

Spamhaus（ZEN）に載ったときの調べ方と解除手順。返却コードの意味、ツールで結果が違う理由、リスト別の対処を公式情報で解説。

メールが届かない・ブラックリスト解除の手順と原因の調べ方

送信メールが届かない・拒否されるときの確認順を解説。エラーコードの読み方、ブラックリストの調べ方、解除申請の正しい手順と再掲載の防ぎ方。

記事一覧を見る →