【ITニュース解説】I trusted SMTP 250 OK for 50 emails. 12 bounced. Why?

メールアドレスの検証は、表面上は単にアドレスが「有効か無効か」を判断するシンプルな作業に見えるかもしれない。しかし、実際には多くの開発者が信頼しがちな「SMTP 250 OK」という応答は、メールが実際に受信者に届くことを保証するものではない、という重要な警告が提示されている。

ある開発者は、50件のメールアドレスに対し、事前に検証スクリプトを使ってSMTPプロトコルで接続を試み、全て「250 OK」という応答を得た。この応答は、SMTPサーバーが一時的にそのメールを受け取る用意があることを意味する。しかし、実際にこれらのアドレスにメールキャンペーンを送信したところ、「250 OK」と判断されたアドレスのうち12件、つまり全体の24%がハードバウンス（不達）となった。この高い不達率は、「250 OK」という応答が、単なる「天気予報」のような一時的な状況報告に過ぎず、メールの確実な配信を保証するものではないことを強く示唆している。

この問題の深掘りのため、筆者はEmail Validator APIという外部サービスを利用して test@gmail.com というアドレスを検証した。APIからの応答には、"valid": true、"mx_found": true といった、アドレスが形式的に有効であることを示す情報が含まれる一方で、"smtp_verified": null、"is_catch_all": null、"is_greylisted": null、"is_trusted_identity": null といった、不明な点については正直に「null」を返す項目も含まれていた。多くのメール検証ツールが、これらの不明な点を安易に「有効」と判断しがちな中で、このAPIが「わからないことをわからないと報告する」透明性は、誤った判断を避ける上で非常に重要である。

「250 OKは契約ではなく握手だ」という言葉が示すように、SMTPサーバーが「250 OK」を返したとしても、その後のメール配信が成功するとは限らない。これには複数の理由がある。

まず、グレーリスティングが挙げられる。これは、受信側のメールサーバーが、未知の送信元IPアドレスからの最初のメールを一時的に拒否し、正規のメールサーバーが再試行するのを待つ仕組みだ。一時的な検証プローブでは、4xx系の拒否応答を受け取って失敗と判断してしまうか、再試行で250 OKを得たとしても、それが最終的な配信を保証するものではない。

次に、キャッチオール・ドメインの存在だ。これは、特定のドメインが、存在しないメールアドレス宛てのメールであってもすべて受け入れるように設定されている場合を指す。このようなドメインは、どんなユーザー名に対しても「250 OK」を返すが、実際にはそのメールは受信者に届かず、ブラックホールに消えたりスパムフォルダに振り分けられたりすることがある。

また、ロールエイリアスも問題となる。test@、info@、support@、admin@ といったアドレスは、ディレクトリ上には存在し、SMTPサーバーは「250 OK」を返すことが多い。しかし、これらは共有メールボックスや転送設定であることが多く、特定の個人がアクティブにメールを読んでいるとは限らない。エイリアスが使われていなかったり、転送先が機能していなかったりすれば、メールは配信されない。

さらに、受け取り後のフィルタリングも原因の一つだ。大規模なメールプロバイダーでは、SMTPプロトコルで「250 OK」を返してメールを受け取った後、内部で機械学習を活用したスパムフィルタリングや不正検出を実行し、その結果としてメールを拒否したり、サイレントに破棄したりすることがある。この場合、「250 OK」は送信済みだが、実際には配信されていない。

メールボックスの状態変化も考慮すべき点だ。メールアドレスの検証を行った時点と、実際にメールを送信する時点との間に時間差があると、その間にユーザーがアカウントを削除したり、受信ボックスの容量を超過したり、管理者がアカウントを無効にしたりすることがある。この状態変化により、検証時には有効だったアドレスが、送信時には無効になっていることがある。

最後に、信頼できるアイデンティティの欠如も無視できない。単に構文が正しく、MXレコードが存在し、SMTPが受け入れるアドレスであっても、それが使い捨てのアドレスであったり、過去に情報漏洩（breach）に関わったアカウントであったりする可能性がある。このようなアドレスは、詐欺や悪用に使われるリスクが高く、ビジネス上は「信頼できる」とは言えない。

これらの理由から、開発者は単に「このメールは有効か？」という問いではなく、「このメールはどの程度のリスクがあるか、そして何のために使うのか？」という、より深く多角的な問いに焦点を当てるべきだ。

メールアドレス検証の際には、以下のような複数のアプローチを組み合わせることが推奨される。

• 構文検証: 最も基本的なチェックで、メールアドレスの形式的な誤りを検出する。これは入力フォームの段階で修正を促すことで、不達メールの発生を未然に防ぐ最も安価な方法となる。
• MXレコードチェック: そのドメインがメールを受信するサーバーを持っているかを確認する。ただし、MXレコードの存在だけで配信を保証するものではない。
• SMTP検証: SMTPサーバーに実際に接続し、メールアドレスを受け入れるか確認する。結果が「null」の場合は「不明、さらなる証拠が必要」と解釈し、安易に「有効」と判断しないことが重要である。
• ロール検出: info@ や test@ のようなロールアドレスを特定し、これらをキャンペーンから除外したり、手動レビューの対象にしたりする。
• フリーメールとプロバイダーIDの検出: アドレスがgmail.comのようなフリーメールサービスであるか、またどのプロバイダーを使っているかを識別する。B2Bのリードでは、企業ドメインのアドレスとフリーメールアドレスでは行動パターンが異なることが多いため、セグメンテーションに役立つ。
• 情報漏洩ステータス: そのメールアドレスが過去に情報漏洩の被害に遭っているかを確認する。これは詐欺のリスクを判断する重要なシグナルとなる。情報がない場合は「情報漏洩なし」ではなく、「確認できなかった」と正直に報告するAPIが望ましい。
• グレーリスティングとキャッチオール検出: これらの挙動を検出し、そのアドレスのSMTP検証結果が不確実である理由を理解する。グレーリスティングの場合は後で再試行を検討し、キャッチオールの場合はSMTPだけでは検証不能と判断する。
• 複合的な信頼度スコア: 個別の検証結果を統合し、そのメールアドレスの全体的な信頼度を示すスコアやフラグを利用する。ただし、情報が不完全な状態で生成された複合フラグは誤解を招く可能性があるため、すべての情報が揃っている場合にのみ利用すべきだ。

実践的には、メールの検証を「アドレス取得時」「リストインポート前」「メール送信直前」という複数のフェーズで実施することが有効である。特に、送信直前のチェックは、検証と配信の間の時間差を最小限に抑えるため、最も信頼性の高いシグナルを提供する。

結論として、メール検証はリスクをスコアリングするプロセスであり、単なる「有効／無効」の二元的な判断を下す「門番」ではない。SMTP 250 OKだけを最終的な合格のサインとして扱うようなシステムは、不達メールを「前もって予約している」ようなものだと言えるだろう。スコアが75のような中間的な値を示すアドレスに対しては、削除するのではなく、そのリスクに応じて慎重にセグメント分けし、対応を検討することが求められる。例えば、スコア95で信頼できるアイデンティティが確認できるアドレスは優先リストに入れ、スコア45で使い捨てかつ情報漏洩の多いアドレスはブロックするといった判断が可能になる。中間層のアドレスについては、二段階認証を求めるか、優先度の低いキャンペーンで試すかなど、運用に応じた判断が必要となる。この不確実性こそが、現代のメール検証の現実なのである。