DNSBL（DNS Blocklist）とは何ですか？

スパム送信元の IP アドレスを DNS で公開し、受信サーバーがリアルタイムで参照するブロックリスト。Spamhaus が代表的なプロバイダー。

メール配信インフラ

DNSBL（DNS Blocklist）

Q: DNSBL（DNS Blocklist）の概要について教えてください

DNSBL（DNS Blocklist） は、スパム送信や不正利用が確認された IP アドレスを DNS ベースのリストで公開し、メールサーバーがリアルタイムで参照して受信拒否を判断する仕組みです。RFC 5782（2010 年）で DNSBL のクエリ形式と応答仕様が文書化され、RFC 6471（2012 年）で運用上のベストプラクティスが整理されています。

Q: DNSBL（DNS Blocklist）の確認方法について教えてください

特定の IP アドレスが DNSBL に掲載されているかを確認するには、dig コマンドで直接クエリを送信します。

2026年2月26日更新

概要

DNSBL（DNS Blocklist） は、スパム送信や不正利用が確認された IP アドレスを DNS ベースのリストで公開し、メールサーバーがリアルタイムで参照して受信拒否を判断する仕組みです。RFC 5782（2010 年）で DNSBL のクエリ形式と応答仕様が文書化され、RFC 6471（2012 年）で運用上のベストプラクティスが整理されています。

DNSBL は 1990 年代後半にスパム対策の手段として生まれました。当初は RBL（Realtime Blackhole List）と呼ばれていましたが、現在は DNSBL（DNS Blocklist）が標準的な呼称です。DNS プロトコルをクエリインフラとして再利用する設計により、メールサーバーは追加のプロトコルを実装することなく、SMTP 接続の受け付け時にリアルタイムでブロックリストを参照できます。

主要な DNSBL プロバイダーとして、Spamhaus、Barracuda（BRBL）、SpamCop があります。Spamhaus の ZEN は SBL（手動確認済みスパム送信元）、CSS（自動検出されたスパム送信元）、XBL（マルウェア感染ホスト）、PBL（メール送信を想定しない IP 範囲）の 4 つのリストを統合した複合 DNSBL で、1 回のクエリで全リストを検索できます。

仕組み

DNSBL の参照は送信元 IP のオクテットを逆順にして DNS クエリを送るだけのシンプルな構造で、応答コードの値でリストの種類を判別します。

クエリの流れ

DNSBL の参照は、通常の DNS クエリと同じ仕組みで動作します。受信サーバーが SMTP 接続を受け付けたとき、送信元 IP アドレスを使って DNSBL に問い合わせます。

送信元 IP アドレスのオクテットを逆順に並べる（例: 192.0.2.99 → 99.2.0.192）
DNSBL のドメイン名を末尾に付与する（例: 99.2.0.192.zen.spamhaus.org）
この名前に対して A レコードの DNS クエリを送信する
応答がある場合（127.0.0.x が返る）、その IP はリストに掲載されている
応答がない場合（NXDOMAIN）、その IP はリストに掲載されていない

# 送信元 IP: 192.0.2.99
# DNSBL: zen.spamhaus.org

クエリ名: 99.2.0.192.zen.spamhaus.org

応答あり (127.0.0.2) → リスト掲載 → 受信拒否
応答なし (NXDOMAIN) → リスト未掲載 → 受信許可

IP アドレスのオクテットを逆順にするのは、逆引き DNS（in-addr.arpa）と同じ理由です。DNS の名前空間は右側がルートに近い階層構造のため、ネットワーク部（上位オクテット）を右側に配置することで、IP アドレスブロック単位でのゾーン委任が可能になります。

応答コード（127.0.0.x）

DNSBL の応答は 127.0.0.0/8（ループバックアドレス）の範囲を使います。RFC 5782 では、実際のネットワーク通信に使われることのないこのアドレス範囲を応答に利用することで、誤って IP アドレスとして扱われた場合の副作用を防いでいます。

応答の具体的な値はプロバイダーごとに定義されます。Spamhaus ZEN の場合、以下のように分類されます。

応答コード	リスト	意味
`127.0.0.2`	SBL	手動で確認されたスパム送信元
`127.0.0.3`	CSS	自動検出されたスパム送信元
`127.0.0.4` - `127.0.0.7`	XBL	マルウェア感染ホスト・オープンプロキシ
`127.0.0.9`	DROP / eDROP	ハイジャックされた IP ブロック
`127.0.0.10`	PBL（Spamhaus 登録）	メール送信を想定しない動的 IP 範囲
`127.0.0.11`	PBL（ISP 登録）	ISP が自主登録した非メール送信 IP 範囲

127.0.0.2（SBL）と 127.0.0.10（PBL）では対処方法が異なります。 SBL はスパム行為の停止と原因の根絶が求められるのに対し、PBL は ESP（Email Service Provider）経由でメールを送信する運用に切り替えるだけで解決します。

RFC 5782 では、DNSBL はテスト用エントリとして 127.0.0.2 に対する応答を必ず含むこと、127.0.0.1 には応答を返さないことが規定されています。

TXT レコードによる詳細情報

A レコードの応答に加えて、多くの DNSBL プロバイダーは TXT レコードで掲載理由の詳細を提供します。TXT レコードには、掲載理由の説明や解除手続きへのリンクが含まれます。

# A レコード: リスト掲載の有無と分類
99.2.0.192.zen.spamhaus.org.  A  127.0.0.2

# TXT レコード: 掲載理由の詳細
99.2.0.192.zen.spamhaus.org.  TXT  "https://www.spamhaus.org/sbl/query/SBL..."

メールサーバーでの処理

受信サーバーは DNSBL の応答に基づいて、以下のいずれかの処理を選択します。

SMTP セッションを 550 で拒否する（接続時ブロック）
メールを受け入れたうえでスパムスコアに加算する（スコアリング）
ヘッダーにタグを付与してフィルタリングに使う

接続時ブロックは送信者への影響が大きいため、単一の DNSBL だけで拒否するのではなく、複数のリストの結果やスパムスコアと組み合わせて判断するのが一般的です。Postfix や Sendmail などの MTA では、DNSBL を reject_rbl_client や dnsbl_sites のパラメーターで設定します。

設定例

Postfix で DNSBL を参照して受信拒否する設定と、複数 DNSBL を併用する構成例を示します。

Postfix での DNSBL 設定

Postfix で Spamhaus ZEN を参照する設定例です。main.cf に以下を追加します。

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org=127.0.0.[2..11],
    permit

=127.0.0.[2..11] を指定することで、SBL・CSS・XBL・PBL の全リストでの掲載を拒否対象にします。PBL（動的 IP）だけを除外したい場合は、応答コードの範囲を =127.0.0.[2..9] に限定します。

複数 DNSBL の併用

信頼性を高めるために、複数の DNSBL を併用する構成も一般的です。

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client b.barracudacentral.org,
    reject_rbl_client bl.spamcop.net,
    permit

この構成では、いずれかの DNSBL に掲載されていれば拒否されます。誤検知（false positive）のリスクを考慮し、信頼性の高いプロバイダーのみを選定してください。 マイナーな DNSBL はメンテナンスが停止されたまま全 IP をブロックするケースが過去に報告されています。

確認方法

特定の IP アドレスが DNSBL に掲載されているかを確認するには、dig コマンドで直接クエリを送信します。

# Spamhaus ZEN で確認（IP: 192.0.2.99）
dig +short 99.2.0.192.zen.spamhaus.org

# Barracuda BRBL で確認
dig +short 99.2.0.192.b.barracudacentral.org

# SpamCop で確認
dig +short 99.2.0.192.bl.spamcop.net

応答が返れば掲載されており、NXDOMAIN（応答なし）であれば掲載されていません。掲載理由の詳細を確認するには、TXT レコードを問い合わせます。

# TXT レコードで掲載理由を確認
dig +short TXT 99.2.0.192.zen.spamhaus.org

複数の DNSBL を一括で確認するシェルスクリプトの例です。

IP="192.0.2.99"
REVERSED=$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}')

for BL in zen.spamhaus.org b.barracudacentral.org bl.spamcop.net; do
  RESULT=$(dig +short "$REVERSED.$BL")
  if [ -n "$RESULT" ]; then
    echo "LISTED on $BL: $RESULT"
  else
    echo "CLEAN on $BL"
  fi
done

外部の視点からも確認したい場合は、Labee Dev Toolbox の IP API を使うと、外部の視点から見た結果を取得できます。

curl "https://labee.dev/api/ip?ip=192.0.2.99"

レスポンスの data.ptr フィールドに逆引き結果のホスト名が返ります。

{
  "success": true,
  "data": {
    "ip": "192.0.2.99",
    "type": "IPv4",
    "isPrivate": false,
    "ptr": "mail.example.com"
  },
  "error": null,
  "meta": { "responseTime": 35 }
}

PTR レコードが未設定の場合は ptr が null になります。PTR が設定されていない IP アドレスは DNSBL への掲載リスクが高く、受信サーバーが PTR 未設定を独自に拒否条件とするケースもあります。

メール認証全体の設定状況は、Mail Auth API でも確認できます。

curl "https://labee.dev/api/mail-auth?domain=example.com"

レスポンスは次の形式で返ります。

{
  "success": true,
  "data": {
    "spf": {
      "record": "v=spf1 include:_spf.google.com ~all",
      "exists": true
    },
    "dkim": {
      "record": null,
      "exists": false,
      "selector": "default"
    },
    "dmarc": {
      "record": "v=DMARC1; p=reject; rua=mailto:dmarc@example.com",
      "exists": true
    },
    "bimi": {
      "record": null,
      "exists": false
    }
  },
  "error": null,
  "meta": { "responseTime": 120 }
}

data.spf、data.dkim、data.dmarc、data.bimi の各フィールドでドメインの認証レコードを一括確認できます。DNSBL は IP アドレスレベルの判定であり、ドメイン認証とは別のレイヤーですが、SPF・DKIM・DMARC の設定不備は送信者レピュテーションの低下を招き、結果として DNSBL への掲載リスクを高めます。

よくある問題

DNSBL 関連のトラブルでは、自社 IP の掲載、PBL による正規メールの拒否、解除後の再掲載が頻繁に発生します。

自社の IP が DNSBL に掲載されていた

DNSBL への掲載に気づくきっかけは、多くの場合メールの配信失敗です。バウンスメールに 550 5.7.1 Service unavailable; client host [x.x.x.x] blocked using zen.spamhaus.org のようなエラーメッセージが含まれている場合、DNSBL が原因です。

対処手順は以下のとおりです。

dig コマンドまたは Spamhaus の Reputation Checker でどのリストに掲載されているかを特定する
掲載理由を確認する（TXT レコードまたはプロバイダーの検索ページ）
原因を解消する（スパム送信の停止、マルウェアの駆除、オープンリレーの修正など）
プロバイダーの解除申請フォームから削除をリクエストする

原因を解消しないまま解除申請を出しても、再掲載されます。 Spamhaus の SBL は ISP からの解除申請を受け付けますが、スパム行為が継続していると判断された場合、申請は却下されます。

PBL に掲載されているが自社サーバーからメールを送りたい

PBL（Policy Blocklist）は、ISP の動的 IP 範囲やエンドユーザー向け IP を対象としたリストです。自宅サーバーや動的 IP のVPS からメールを送信しようとすると、PBL に掲載されていて拒否されるケースがあります。

PBL は「スパムを送った」という事実ではなく、「メール送信に適さない IP 範囲」というポリシーに基づく掲載です。対処方法は 2 つあります。

固定 IP を持つ VPS やクラウドインスタンスに移行し、PBL の解除申請を行う
SendGrid、Amazon SES、Postmark などの ESP 経由でメールを送信する

解除後すぐに再掲載される

DNSBL からの解除後に短期間で再掲載される場合、根本原因が解消されていません。以下を確認してください。

サーバーにマルウェアや不正なスクリプトが残っていないか
Web アプリケーションのフォームがスパム送信に悪用されていないか
同一 IP ブロック内の別のユーザーがスパムを送信していないか（共有ホスティングの場合）
メーリングリストの配信先にスパムトラップが含まれていないか

特定の DNSBL だけに掲載される

DNSBL プロバイダーごとに掲載基準が異なるため、1 つの DNSBL にだけ掲載されるケースがあります。SpamCop はユーザー報告ベースで掲載されるため、少数の苦情でもリスト入りする場合があります。一方、Spamhaus SBL は手動調査を経て掲載されるため基準が厳格です。

影響の大きさは受信側が参照している DNSBL に依存します。Spamhaus ZEN は世界中のメールサーバーで広く利用されているため、SBL への掲載は配信率に大きな影響を与えます。

IPv6 アドレスの DNSBL 参照

IPv6 の DNSBL クエリでは、128 ビットアドレスを完全展開してニブル単位で逆順に並べます。IPv4 と比べてクエリ名が長くなりますが、仕組みは同じです。

# IPv6: 2001:db8::1 の Spamhaus ZEN クエリ
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.zen.spamhaus.org

IPv6 対応の DNSBL はまだ IPv4 ほど普及していませんが、IPv6 でメールを送信する場合は IPv6 側のレピュテーションも確認してください。

送信者レピュテーションとの関係

DNSBL は送信者レピュテーションを構成する要素の 1 つです。メールの配信率に影響する要因は DNSBL だけではなく、以下の要素が総合的に評価されます。

DNSBL の掲載状況
SPF・DKIM・DMARC の認証結果
FCrDNS（正引き確認済み逆引き DNS）の成否
バウンス率とスパム苦情率
送信パターン（急激な送信量の増加など）

DNSBL に掲載されていなくても、SPF や DMARC の設定不備があると受信拒否される場合があります。逆に、認証設定が整っていても DNSBL に掲載されていれば拒否されます。メール配信の信頼性は、これらの要素を全て満たすことで確保されます。

実際のドメインで確認してみる

登録不要、無料です。ドメイン名を入れるだけで外部からの見え方を確認できます。

無料で試す

DNSBL（DNS Blocklist）

概要

仕組み

クエリの流れ

応答コード（127.0.0.x）

TXT レコードによる詳細情報

メールサーバーでの処理

設定例

Postfix での DNSBL 設定

複数 DNSBL の併用

確認方法

よくある問題

自社の IP が DNSBL に掲載されていた

PBL に掲載されているが自社サーバーからメールを送りたい

解除後すぐに再掲載される

特定の DNSBL だけに掲載される

IPv6 アドレスの DNSBL 参照

送信者レピュテーションとの関係

実際のドメインで確認してみる

関連用語

SPF（Sender Policy Framework）

DMARC（Domain-based Message Authentication, Reporting and Conformance）

逆引き DNS（Reverse DNS）

PTR レコード（Pointer Record）

FCrDNS（正引き確認済み逆引き DNS）

IPv4（Internet Protocol version 4）

IPv6（Internet Protocol version 6）