プロダクトチームはメールアドレスのバリデーションサービスを選ぶときに何を評価すべきか

バリデーションを複数の個別のチェックとして定義する

「メールアドレスのバリデーション」は、クライアント側のフォームのチェック、Internet Message Formatの解析、ドメインの存在確認、DNSによるメールルーティングのチェック、SMTPの対話、過去のバウンス情報、使い捨てドメインの分類、入力ミスの候補提示、あるいはその人がアドレスを管理していることの証明を意味することがあります。これらはそれぞれ異なる事実を観測しています。まず、何を判断するのかを文章にしてください。形式が不正な登録時の入力をブロックするのか、入力ミスの可能性を警告するのか、恒久的に失敗したアドレスへの繰り返しの送信を減らすのか、合法的で受信者も想定している目的でインポートしたリストを見直すのか、といったことです。各ベンダーに、valid、invalid、risky、unknown、accept-all、disposable、role-based、temporaryの各結果の裏にある正確な証拠を示すよう求めます。1つの緑のスコアが、構文、サードパーティのレピュテーションデータ、リモートサーバーの一時的な応答を黙って組み合わせたものであってはいけません。生の理由、チェックの時刻、正規化した入力、ポリシーの判断は分けて保持してください。そうすれば、元になる観測結果が変わったふりをせずに、プロダクト側でしきい値を変更できます。

正当なアドレスを拒否しないよう構文を解析する

インターネットのメールアドレスの構文は、Webフォームでよく使われる正規表現よりも広い範囲を許容します。RFC 5322はメッセージのアドレス構文を定義し、SMTPはメールボックスとドメインの形式に転送上の要件を課しています。よく見かける一般消費者向けのパターンしか受け付けない自作の正規表現ではなく、メンテナンスされているパーサーと、入力段階での控えめなチェックを使ってください。ユーザーが入力した元のアドレスは表示と監査のために保持し、正規化はチームが正当性を説明できるルールに限ります。ドメイン名は大文字と小文字を区別しませんが、ローカルパートの扱いはプロバイダーによって異なることがあるため、小文字化や記号の削除によって別々のメールボックスが1つにまとめられてしまうことがあります。プロダクトが国際化アドレスに対応するかどうかを決め、その境界を明確に文書化してください。構文チェックに成功したことが意味するのは、そのアドレスが対応する文法で表現できるということだけです。ドメインがメールを受け付けること、メールボックスが存在すること、その人が所有していること、受信者がメッセージを求めていることは証明できません。バリデーションのベンダーは、珍しいものの対応範囲内のアドレスを確認なしに置き換えるのではなく、構文上の理由を返すべきです。

ドメインとメールルーティングの証拠を確認する

アドレスのドメインをDNSで解決し、使用可能なメールルートとルックアップの失敗を区別します。SMTPの配送では通常、MXレコードと定義されたフォールバックの挙動が使われます。一方、RFC 7505では、ドメインがメールを一切受け付けないことを示すNull MXを公開できます。サービスは、NXDOMAIN、Null MX、有効なMX、暗黙のフォールバック、DNSのタイムアウト、SERVFAIL、DNSSEC関連またはリゾルバーのエラーを、それぞれ別の観測結果として報告すべきです。リゾルバーの一時的な障害を、恒久的なinvalidの判定にしてはいけません。DNSの変更やキャッシュによって結果はすぐに古くなるため、リゾルバーでの確認時刻と最終的な応答を記録しておきます。ドメインレベルで成功しても、特定のメールボックスが存在することの証明にはなりません。有効なMXが何百万ものアドレスを扱っていたり、セキュリティゲートウェイを経由していたり、すべての受信者を受け付けていたり、チェックを後回しにしていたりすることがあります。MXレコードのあるドメインをすべて検証済みの受信者として扱うのではなく、ドメインの証拠を開示するようベンダーに求めてください。

SMTPプローブは不確実でポリシー上の配慮が必要なものとして扱う

一部のサービスは、メッセージコンテンツを送信せずに受信者の処理を観察するのに十分なトランザクションを実行するため、宛先SMTPサーバーに接続します。RFC 5321はコマンドと応答を定義していますが、リモートシステムは検証コマンドを無効にしたり、最初はすべての受信者を受け付けたり、プローブを拒否したり、ターピットしたり、グレイリスティングしたり、レート制限を設けたり、接続IPによって動作を変えたり、メッセージ受け付け後まで受信者のバリデーションを遅らせたりできます。`RCPT TO`に対する`250`レスポンスは、ある時点の1台のサーバーからの証拠であり、そのメールボックスが監視されていることや、後の本番メッセージを受け付けることの証明ではありません。`4xx`レスポンスは一時的であり、通常は無効ではなく不明または後で再試行とすべきです。`5xx`レスポンスが恒久的なアドレスの判断を支持するには、正確なコマンド段階と診断情報が必要です。ベンダーが責任を持って自らを識別しているか、トラフィックを制限しているか、サーバーポリシーを尊重しているか、実際のエンベロープIDを使用しているか、プローブインフラが顧客のレピュテーションまたは不正利用の問題を引き起こさないようにしているかを確認してください。

説明可能な結果と慎重な自動化を求める

ベンダーを組み込む前に、社内の結果モデルを定義します。有用な項目には、構文の状態、ドメインの状態、MXの状態、Null MX、SMTPの観測結果、拡張ステータス、accept-allの証拠、使い捨てまたは役割アドレスの分類、入力ミスの候補、信頼度、チェック時刻、データソースがあります。`unknown` と `temporary` は正式な結果として扱ってください。登録数を増やしたいからといってvalidに、コードを単純にしたいからといってinvalidに変換してはいけません。強制的なブロックは、構文として成立しない、Null MXのドメインである、プロダクトのポリシー上、現在も繰り返し恒久的に失敗している、など、プロダクトが意図して承認した証拠に限ります。入力ミスの可能性には、警告や確認を使います。あいまいなケースでは、プロダクトの通常の確認フローで所有を確認するか、管理された形で最初の送信を許可してその結果を処理します。どのルールで判断したかをログに残しますが、サポート、不正対策、プライバシー、受信者の安全に関わる運用で本当に必要な範囲を超えて、アドレスの履歴を保存しないでください。

管理された期限付きのデータセットで精度を測定する

正解をチームが合法的に知ることができるテストセットを作ります。所有するドメインのアドレス、管理されたメールボックス、明示的に存在しない受信者、Null MXのドメイン、キャッチオールのドメイン、対応範囲内のUnicodeのケース、構文のエッジケース、一時的な応答を返すよう設定したサーバーなどです。各ベンダーを同時に実行し、ラベルだけでなく理由コードも保存します。誤ったブロック、誤った受け入れ、unknownの割合、レイテンシー、結果の変動、DNSやSMTPの一時的な障害から回復するまでの時間を測定します。購入したアドレスやスクレイピングしたアドレスでは絶対にテストしないでください。ドメインの構成、受信側のポリシー、プローブのレピュテーション、時期、アドレスの古さが観測結果に影響するため、限られたサンプルから普遍的な精度の割合を主張することは避けてください。ベンダーが文書化している鮮度の期間が過ぎたあとと、管理された形でドメインを変更したあとに、結果を再確認します。検証期間は判断の有用性と運用上の挙動を確認するためのものであり、迷惑メールのトラフィックを生み出すためのものではありません。

バリデーションを同意や送信者レピュテーションと切り分ける

構文的に有効で、稼働中のメールボックスにルーティングされるアドレスであっても、連絡してよいとは限りません。GoogleとYahooの送信者ガイドラインは、受信者による選択、購読時の期待、苦情の抑制、送信ドメイン認証、リストの衛生管理を重視しています。どのバリデーションAPIも、許可を作り出したり、インポートしたアドレスがメッセージを求めていたことを証明したり、誤解を招くコンテンツを修正したり、受信者が苦情を申し立てたときにレピュテーションを守ったりすることはできません。同意の取得元、メッセージの種類、配信設定、サプレッション、過去の配信履歴は、バリデーションとは独立して保存してください。送信時には、古い緑のバリデーション結果よりも、受信者の安全と許可に関するチェックを優先すべきです。ベンダーが今は配信可能と判定しているからといって、配信停止した、苦情を申し立てた、または恒久的にバウンスしたアドレスを再び有効にしないでください。逆に、一時的なバリデーション結果によって、確認済みの所有や正当な業務のワークフローが消されるべきではありません。バリデーションは文書化された判断への入力の1つであり、受信側のポリシーや責任ある送信の慣行を免除するものではありません。

アドレスをアップロードする前にプライバシー、セキュリティ、保持期間を確認する

アドレスのリストは、サービスがスコアしか返さない場合でも、個人情報であり商業上の機密データです。アドレスがどこで処理されるのか、保存されるのか、生の入力と結果がどのくらいの期間残るのか、どのサブプロセッサーが受け取るのか、ネットワーク全体の情報、ベンチマーク、モデルの学習に再利用されるのかを確認してください。フィールドを最小限に抑え、削除、エクスポート、リージョンの制御、テナントの分離に対応した、単一アドレスまたはバッチのインターフェースを優先します。APIキーはシークレットマネージャーに保管し、可能であれば環境やワークロードごとに制限し、コールバックを認証し、アドレスや認証情報が分析ツール、URL、ターミナルの履歴、プロンプト、広範なログに入り込まないようにします。バッチのアップロードには、認可、サイズの上限、マルウェアに対して安全な解析、監査履歴、有効期限が必要です。エクスポート、バックアップ、デバッグのトレース、派生したレピュテーションのデータセットの扱いが説明されていないなら、契約上の削除だけでは不十分です。あるワークスペースが別のワークスペースのバリデーション履歴を照会したり、あるアドレスが別の顧客のデータに含まれているかを推測したりできないことをテストしてください。

APIと離脱の手順を運用システムとして評価する

安定したリクエストID、バージョン管理された理由コード、明確なHTTPエラー、冪等なバッチ作成、ページネーション、項目ごとの状態、レート制限のヘッダー、再試行のガイダンス、Webhookの認証、文書化された最大サイズを求めてください。タイムアウトによってバッチがあいまいな状態に残ることがあるため、クライアントにはやみくもな再送信ではなく突き合わせの仕組みが必要です。結果をどのくらいの期間照会できるか、ベンダーを変更するときに元の入力のハッシュ、正規化した値、証拠、タイムスタンプ、判断をどのようにエクスポートするかを定めます。使用量の単位は注意して確認してください。送信したアドレスごと、ユニークなアドレスごと、完了した結果ごと、再試行ごと、追加情報付きのチェックごとで、費用が変わることがあります。キーのローテーション、失効した認証情報、レート制限、バッチの部分的な失敗、コールバックのリプレイ、完了の遅延、削除、アカウントの解約をテストします。ベンダー固有のラベルがビジネスロジック全体に広がらないよう、プロダクト独自の結果モデルを維持してください。サポート、不正の審査、同意に関する紛争、プロバイダーの移行の際に過去のバリデーションの判断が必要になることがあるため、ポータビリティは重要です。

文書化されたメール機能にSendHQを使用する

SendHQの公開ドキュメントでは、メールの送受信、ドメインの検証、配信イベント、サプレッションについて説明しています。送信前の受信者アドレスのバリデーションエンドポイント、メールボックス所有権の証明、使い捨てアドレス分類器、SMTPプロービングサービスについては説明していません。これらのチェックが必要な場合は、専用のバリデーションサービスを使用してください。SendHQの配信イベントとサプレッションは、試行後の受信者の安全性に役立つ情報を提供できますが、メールボックスの所有権を証明したり、同意、サプレッション、想定受信者の制御に代わったりするものではありません。

よくある質問

出典

• RFC 5321：簡易メール転送プロトコル（SMTP） — RFC Editor
• RFC 5322：インターネットメッセージ形式（Internet Message Format） — RFC Editor
• RFC 7505：メールを受け付けないドメインのためのNull MXリソースレコード — RFC Editor
• RFC 3463：メールシステムの拡張ステータスコード — RFC Editor
• Gmailのメール送信者のガイドライン — Google
• Yahoo送信者向けベストプラクティス — Yahoo Sender Hub
• OWASP 入力バリデーションのチートシート（Input Validation Cheat Sheet） — OWASP Foundation
• SendHQ OpenAPI仕様 — SendHQ