メール ブラックリスト チェック：検索ツールが教えてくれないこと

メール ブラックリスト チェックでIPアドレスを照会すると、緑と赤の行が並んだ表が返ってきます。この表が答えるのは、狭い1つの質問だけです。「このアドレスは、今この瞬間に公開DNSブラックリストのどれかに載っているか」。メールがGmail、Outlook、社内ゲートウェイに受け入れられるかどうかは、この表からは分かりません。両者を同じ問題として扱うことが、障害対応を長引かせる最大の原因の一つです。

この記事では、チェックが実際に何を問い合わせているのか、dig で自分で実行する方法、「問題なし」と「問い合わせが拒否された」を見分ける結果コード、そして手作業をやめて監視に組み込む方法を説明します。

ブラックリストの確認はDNS問い合わせにすぎない

すべてのDNSブラックリスト（DNSBL）は同じ仕組みで動きます。IPv4アドレスのオクテットを逆順にし、リストのゾーンを末尾に付けて A レコードを問い合わせます。RFC 5782 がこの規約を定めています。192.0.2.99 を bad.example.com に照会する場合、問い合わせ名は 99.2.0.192.bad.example.com になります。掲載されていれば 127.0.0.0/8 の範囲の応答が返り、掲載されていなければレコードは返りません。

仕組みはこれで全部です。IPを貼り付けるだけのWebツールも、裏では数十のこの問い合わせを並列に実行し、結果を整形しているだけです。

# 203.0.113.25 が Spamhaus ZEN に掲載されているか
dig +short 25.113.0.203.zen.spamhaus.org A

# ドメインベースのリストは逆順にせず、そのままドメインを問い合わせます
dig +short example.com.dbl.spamhaus.org A

出力が空であれば掲載なしです。127.x.x.x の応答は掲載ありを意味し、末尾のオクテットから、どのサブリストに一致したかが分かります。自分で管理するマシンから自前のリゾルバを使って実行すれば、スクリプト化、ログ記録、アラートができます。

確認すべきはWebサイトのIPではなく、メールを送っているIP

最初によくある間違いは、誤ったIPを調べることです。マーケティングサイト、API、送信用のメールリレーは、多くの場合それぞれ別のアドレスです。重要なのは、実際にメールボックスへ届いたメッセージの Received ヘッダーに記録されているIPです。

共有インフラのESPから送っている場合、そのIPはあなたのものではなく、掲載もあなたの責任ではありません。専用IPで送っている場合は、その範囲を以前使っていた相手が何をしたかも含めて、すべてあなたの問題になります。

送信IPは、ダッシュボードの設定値ではなく、実際に届いたメッセージから取得してください。そのうえで3つを別々に確認します。送信IP、エンベロープと From のドメイン、そしてトラッキングや配信停止のホストを含む、本文のリンク先のすべてのドメインです。URIBL や SURBL のようなURIベースのリストは、本文中のリンク先を評価します。そのため、IPがきれいでも、掲載済みのドメインへリンクするメールは守られません。

「問題なし」が、公開リゾルバでは拒否の偽装かもしれない

これは一般的なチェックページがほとんど触れない落とし穴です。Spamhaus は、公開リゾルバやオープンリゾルバ経由の問い合わせには回答せず、その旨を掲載ではなく戻りコードで示します。Spamhaus は 127.255.255.254 をエラーコードとして説明しています。これは評判の結果ではなく、メールを拒否する根拠に使ってはいけません。

ここから2つの帰結があります。スクリプトが127.xの応答をすべて「掲載あり」と読むと、クラウドのリゾルバで拒否された問い合わせに対して、存在しない掲載のアラートが鳴ります。逆に、使える応答がないことを「問題なし」と読むと、拒否は空の応答や NXDOMAIN としても表れるため、実際の掲載を静かに見逃します。

解決策は、独自の再帰リゾルバと正しい逆引きDNSを持つホストから実行するか、Spamhaus が公開ミラーの利用者に案内している無料のクエリサービスを使うことです。そのうえで、リゾルバを信頼する前にゾーンを検証してください。RFC 5782 では、IPv4のリストに 127.0.0.2 のエントリが必要で、127.0.0.1 のエントリは存在してはいけないと定められています。次のコマンドで確認できます。

dig +short 2.0.0.127.zen.spamhaus.org A   # 127.x の応答が必要
dig +short 1.0.0.127.zen.spamhaus.org A   # 何も返らないことが必要

両方とも何も返らなければ、リゾルバの経路が壊れているか、拒否されています。その状態で得た結果は、読む前に直してください。

配信障害の多くはブラックリストの問題ではない

ブラックリストを調べる前に、受信サーバーが実際に何を返したかを確認してください。掲載による拒否と、メールボックス事業者側の評判による拒否では、表示される文言が違います。そして、公開リストにはメールボックス事業者側の評判は表示されません。

Google の送信者向けドキュメントは、この点について明確です。550 5.7.1 は、送信IPが停止リストに入っていることを意味する場合があり、多くは共有IPの評判の低下が原因です。一方 5.7.26 は認証の失敗を示します。大量送信者には、SPF、DKIM、DMARC、送信IPの正引きと逆引きの両方の有効なDNS、TLS、そして Postmaster Tools で見た迷惑判定率 0.30% 未満が求められます。Gmail の送信者要件 は、推奨目標として 0.10% を挙げています。

これは作業の順序として読んでください。バウンス文言がDNSBLを名指ししていれば、掲載の問題です。評判、認証、レート制限に関する文言であれば、ブラックリストの照会は「問題なし」と返すことが多く、その確認に1時間を費やすことになります。

• DNSBLのゾーンやURLが書かれている場合: 特定のリストに掲載されています。照会を実行し、そのリストの削除ページを使ってください。

• 550 5.7.1 で IP reputation とある場合: 事業者側の評判の問題で、多くは共有IPです。Postmaster Tools と、送信量と苦情率の推移を確認してください。

• 5.7.26 の場合: 認証に失敗しています。SPF、DKIM、DMARC のアラインメントを確認してください。

• 4.7.28 やレート制限の文言の場合: 現在の評判に対して送信が速すぎます。送信を絞り、徐々に戻してください。

1回限りのWebチェッカーを監視に使わない

単発の照会で分かるのは、実行した瞬間の状態だけです。掲載は一時的なことが多く、その多くは自分で引き起こしたスパイクの後に現れます。大量インポート、再許可のための一斉送信、スパムの中継に悪用されたフォームなどが原因です。

「100のブラックリストから削除します」と課金するサービスは、そのリストの多くにはない問題を売っています。一般的な一括チェックに並ぶリストの多くは、主要なメールボックス事業者への影響がごくわずかです。削除も通常は無料で、各事業者のページからセルフサービスで行えます。赤い行をすべて追いかけると、実際の受信者が参照する2つか3つのリストに使うべき時間が失われます。

送信量に基づいてリストに優先順位を付けてください。バウンスに現れる受信ドメインを見て、それらの受信側が公開で使っているリストを特定し、それを監視します。それ以外は、月次で確認すれば十分なノイズです。

チェックを閾値付きの定期ジョブにする

実用に耐える最小構成は次のとおりです。実際のリゾルバを持つホストから実行し、まずゾーンを検証し、掲載あり、掲載なし、問い合わせ拒否の3つの結果を区別します。

import socket

def dnsbl(ip: str, zone: str) -> str:
    rev = ".".join(reversed(ip.split(".")))
    try:
        answer = socket.gethostbyname(f"{rev}.{zone}")
    except socket.gaierror:
        return "not_listed"
    if answer.startswith("127.255.255."):
        return "refused"   # エラーコードであり、評判の結果ではない
    return f"listed:{answer}"

# 信頼する前にゾーンを確認します（RFC 5782 のテストエントリ）
assert dnsbl("127.0.0.2", "zen.spamhaus.org").startswith("listed")
assert dnsbl("127.0.0.1", "zen.spamhaus.org") == "not_listed"

送信IPごと、送信ドメインごとに15分から60分おきに実行し、結果をタイムスタンプ付きで記録してください。アラートを出すのは not_listed から listed へ変わったときだけにします。refused は別にアラートを出してください。それは評判が変わったことではなく、監視が見えなくなっていることを意味します。

ブラックリストより先に変化するシグナルと組み合わせてください。Postmaster ダッシュボードの苦情率、受信ドメインごとのバウンス率、時間あたりの遅延率は、掲載が現れる前に動きます。送信を止めるべきかどうかを教えてくれるのは、これらの数値です。すでにログとメトリクスを監視基盤に送っているなら、照会結果も単なる時系列データの1つとして扱えます。

問題の所在によって、この流れに合うツールは4つあります。

Postmark はトランザクションメール専用のサービスです。パスワードリセットのメールが、他人のニュースレター一斉送信と送信経路を共有することがありません。掲載が共有インフラの隣人に由来するなら、トランザクションとマーケティングの送信を分けることが構造的な解決策になります。

Resend は開発者向けの選択肢で、API がシンプルで、計装する対象も小さく抑えられます。チームが結局のところ独自の配信性チェックをスクリプト化するつもりなら、価値があります。

SendGrid は大量送信での実績が最も長く、専用IPを提供しています。つまり、評判も、そしてブラックリストへの露出も、自分だけのものになります。専用IPが求めるウォームアップと監視の体制を用意できないなら、選ばない方が無難です。

Better Stack は定期ジョブ側を担うツールです。上のスクリプトに対して、稼働監視に近いチェック、アラート、オンコール通知を提供するため、新しい掲載がログファイルではなく人に届きます。

Customer.io は、この理由から別の配信プロバイダーと組み合わせて使われることが多いイベント駆動のレイヤーです。行動トリガーとメッセージのロジックは1か所に置き、配信は別の場所で行います。そのため、フローを書き直さずに配信側を入れ替えたり分割したりできます。そのぶん、観測しなければならないシステムが1つ増えるという代償があります。

掲載されたら、削除申請の前に原因を直す

原因を直さずに削除を申請すると、効果は数日で終わります。同じ動作をするアドレスが戻ってくれば、リストの運営者は再び掲載し、繰り返しの掲載を強化して扱うこともあります。

次の順序で進めてください。

1. 掲載されたIPからの送信を停止するか絞ります。悪質なトラフィックが続けば、掲載期間が延び、新しい掲載も加わります。

2. リスト運営者の掲載記録を読みます。多くは根拠を示しています。スパムトラップへのヒット、急増、リレーの悪用報告などです。

3. 原因を特定します。フォームのエンドポイントにオープンリレーの悪用がないか、最近のリストインポートを確認し、直近1週間で送信を始めた新しい連携を見直してください。

4. 原因を直したうえで、運営者自身の削除手続きを使います。静かな期間の後に掲載を自動的に失効させるリストもあります。

5. 送信量を減らして再開し、最も反応の良い受信者から送ります。1週間は苦情率と遅延を見守ってください。

逆引きDNSの欠如は、繰り返し起きる要因の一つです。Google は送信者要件に有効なPTRレコードを挙げており、逆引きのない送信IPは、コンテンツが評価される前から多くの受信側に信頼性が低いと見なされます。

配信フローはリストではなく、シグナルを中心に組む

プロダクトがアクティベーション、請求、セキュリティのメールを送っているなら、掲載はそれらのフローにとって可用性の障害です。そのように扱ってください。トランザクションメールをマーケティングの送信量から切り離された経路で送り、トリガーのレイヤーが配信状態を把握できるようにします。そうすれば、止まったアクティベーションメールをアプリ内の案内に切り替えられます。

ブラックリストのイベントは、メッセージの行き先を変えるべきであり、ライフサイクルのロジックが動くかどうかを変えてはいけません。ベンダーを別のものにする場合でも、この分離はぜひ真似してください。

今週やるべき三つのこと

効果の大きい順に3つあります。第一に、ゾーン検証と独立した refused 状態を持つ定期照会を、自前のリゾルバを持つホストから実行することです。第二に、バウンスを受信ドメインごとに集計し、自分の送信にとってどのリストが重要かを把握することです。第三に、バウンス文言から始まり削除手順で終わる運用手順書を書くことです。そうすれば、オンコールの担当者が場当たり的に対応せずに済みます。

送信ドメインのうち、1日掲載されても気づかないものはどれでしょうか。