プロダクトチームはメールのバウンスをどう安全に診断し、対処すべきか

失敗がどこで観測されたかを特定する

プロダクトが配信不能を知る経路には、SMTPトランザクションの最中、後から届くDSN、認証されたプロバイダーのイベントがあります。これらの観測では、得られる証拠が異なります。RCPT TOでの即時拒否は、メッセージのデータが受け付けられる前に、その受信者に対して適用されます。DATAの段階での拒否は、送信されたトランザクション全体に適用される場合があります。後から届くDSNは、あるシステムが責任を引き受けた後に、メッセージを配信またはリレーできなかったことを報告するものです。段階、サーバー、受信者の範囲、試行、タイムスタンプ、SMTPの応答、拡張ステータスコード、診断メッセージ、元の相関識別子を記録してください。すべてのケースを「バウンス」にまとめてはいけません。プロバイダーのrawペイロードや標準形式のDSNは、運用とポリシー上必要な期間だけ、アクセスを制限して保存します。サポートのスクリーンショットや人による言い換えは、自動の再試行、サプレッション、顧客に見せるステータスの根拠としては不十分です。

一時的な結果と恒久的な結果を区別する

SMTPでは、一時的な否定完了に4yzの応答を、恒久的な否定完了に5yzの応答を使います。拡張ステータスコードは、持続的な一時的失敗を表す4、または恒久的な失敗を表す5で始まるクラスに、サブジェクトと詳細の値が続く形式です。テキストだけではプロバイダー固有で変わる可能性があるため、基本コードと拡張コードの両方を保存してください。一時的な結果は、同じ論理メッセージを時間をおいて再試行する根拠にはなりますが、即座のループやキューへの無制限の滞留を正当化するものではありません。恒久的な受信者の失敗が起きたら、許可されたプロセスでアドレスやポリシーが変更されるまで、その受信者と試行について自動の再送を止めるべきです。プロバイダーの非公式なラベルだけからハードかソフトかを推測してはいけません。正確なステータス、段階、診断メッセージ、メッセージの種類、受信者、最新のプロバイダーのドキュメントに基づいてポリシーを構築してください。不明な応答や不正な形式の応答は、デフォルトで再送するのではなく、安全側に倒してレビューやデッドレターの処理に回すべきです。

配信状態通知は防御的に解析する

RFC 3464は、multipart/reportで運ばれ、message/delivery-statusのフィールドを持つ、機械可読な配信状態通知の形式を定義しています。有用なフィールドには、Reporting-MTA、Final-Recipient、Action、Status、Remote-MTA、Diagnostic-Code、到着時刻や最終試行時刻などがあります。MIMEの構造として解析できた場合でも、すべてのフィールドを信頼できない入力として扱ってください。メッセージのサイズ、ヘッダーの数、パートの数、入れ子の深さ、文字のデコード、保存する診断メッセージの長さに上限を設けます。添付ファイルを実行したり、診断メッセージ内のリンクを自動的にたどったり、受信者アドレスをテナントのIDとして受け入れたりしてはいけません。安定したプロバイダーのメッセージ識別子、元のエンベロープのメタデータ、またはプライバシー上安全な相関ヘッダーを使って、アプリケーションが管理する試行と関連付けます。DSNには元のメッセージの一部や受信者データが含まれることがあるため、ログと保持期間を制限してください。関連付けが曖昧な場合は、無関係なアドレスをサプレッションリストに追加したり、他のテナントのメッセージ履歴を明かしたりすることなく、証拠を保存しておきます。

受信者単位の状態遷移をモデル化する

1つのメッセージが複数の受信者宛てで、受信者ごとに異なる結果になることがあります。ステータスはメッセージの行だけでなく、受信者と試行ごとに保存してください。プロバイダーは一部のRCPTコマンドを受け付けて他を拒否したり、後からある受信者には配信を、別の受信者には失敗を報告したりすることがあります。遅れて届いた受け付けや遅延のイベントが、その後に確定した恒久的な失敗、苦情、配信停止を上書きできないよう、逆戻りしない状態遷移を定義してください。イベントの台帳を保存し、明示的な優先順位のルールで現在の表示状態を導き出します。送信済み、プロバイダー受付済み、受信サーバー受付済み、一時的な遅延、恒久的な失敗、サプレッション済み、苦情、配信停止、不明を区別してください。宛先サーバーが受け付けても、最終的にどのメールボックスフォルダに入ったか、人が読んだかはわかりません。再試行では同じ論理イベントキーの下に関連付けられた試行を作成し、重複のリスクと証拠が見えるようにします。予定された再試行を、顧客の新しいアクションとして記録してはいけません。

一時的な失敗は厳格な上限を設けて再試行する

再試行の対象となる一時的な結果については、ジッター付きの指数バックオフ、有限の試行回数、キューの最大滞留時間を設定してスケジュールします。プロバイダーが文書化している再試行の挙動に従い、すでに再試行しているリレーの上に、アプリケーション側の積極的なループを重ねないでください。すべての試行で、同じ論理メッセージのIDとサプレッションのチェックを維持します。受信者がサプレッションリストに追加された、同意が変わった、イベントが期限切れになった、送信者IDが取り消された、または後から恒久的な応答が届いた場合は、再試行を止めてください。ひとつの受信側の障害がキューを占有しないよう、テナント、宛先ドメイン、送信者、失敗の種類ごとにレート制限を設けます。Retry-Afterや文書化された遅延のガイダンスがあれば尊重しますが、任意のメッセージ内容を再試行の指示として信頼してはいけません。キューの滞留時間の増加、一時的なコードの繰り返し、通常と異なるドメイン、期限切れが近い試行についてアラートを出しましょう。一時的なコードの裏に、持続的なポリシーやレピュテーションの問題が隠れていることがあります。上限付きの再試行は回復のための時間を稼ぐものであり、原因を無視してよいという許可ではありません。

確定した恒久的な受信者の失敗をサプレッションリストに追加する

アドレスやメールボックスの恒久的な失敗が確定したら、以降のジョブが送信される前に、プロダクトが管理するサプレッションの記録を更新すべきです。テナント、正規化された受信者キー、適用範囲、元のイベント、ステータスと診断のカテゴリ、有効日時、証拠への参照を、アドレスを広く公開しない形で保存してください。サプレッションは、リストのインポート時だけでなく送信時にも適用します。無効なアドレス、存在しないドメイン、ポリシーによる拒否、メッセージ内容による拒否、認証の失敗、クォータ、送信者レピュテーションは、それぞれ安全な対処法が異なるため区別してください。無効な受信者であれば、その受信者に限ったサプレッションが妥当です。送信者の認証による拒否であれば、すべての受信者をサプレッションリストに追加するのではなく、送信者の設定を一時停止すべきです。手動での削除は、強力な認可、理由の記録、監査履歴で保護してください。再確認や修正は、古い証拠を削除するのではなく、新たな検証済みの判断として作成する必要があります。プロバイダーのサプレッションリストは有用ですが、特にプロバイダーの移行時には、アプリケーション側の同意と安全性の台帳の代わりにはなりません。

バウンスのループとバックスキャッターを防ぐ

SMTPでは、配信状態通知に空のリバースパスを使います。これにより、通知の配信に失敗しても、さらに別のバウンスが生成されることはありません。リレーでもこの挙動を維持し、DSN、自動応答、自動生成であることを示すシグナルのあるメッセージには自動返信を送らないでください。RFC 3834は、ループや増幅に関する懸念を含め、メールの自動応答に関する推奨事項を示しています。疑わしいメッセージを受け付けた後で、未検証の表示上のFromアドレスにバウンスを生成してはいけません。偽造された送信者IDによって、システムがバックスキャッターの発生源になってしまうからです。可能な限り、受け付けてから偽造アドレスに後で通知するのではなく、SMTPの段階で無効な受信者を拒否してください。自動応答は送信者と会話ごとに上限を設け、管理された返信用のIDを使います。新たにインターネットメールを生成するよりも、プロダクトのWebhookや内部のエラーイベントのほうが安全な場合が多くあります。偽造されたFrom、空のエンベロープ送信者、繰り返し届くDSN、auto-submittedヘッダー、メーリングリストのトラフィック、不正な形式のレポートを、分離されたフィクスチャでテストしてください。

プロバイダーのイベントは適用する前に認証する

プロバイダーがWebhookでバウンスイベントを送ってくる場合は、ビジネス上のフィールドを解析する前に、リクエストそのものに対して文書化された署名または認証の仕組みを検証してください。タイムスタンプの鮮度、リプレイ対策、本文サイズの上限、テナントとの関連付けを強制します。成功を返す前に、認証済みのイベントを永続化するかキューに入れ、その後、安定したプロバイダーのイベント識別子、または受信者や試行を誤ってまとめることのない保守的な複合キーで重複を排除します。イベントは遅延したり順序が入れ替わったりすることがあるため、発生時刻と処理時刻は分けて保存してください。送信ドメイン、アカウント、ワークスペース、メッセージ識別子、受信者の範囲を想定したテナントに結び付けられないイベントは拒否します。WebhookのシークレットはSMTPやAPIの認証情報とは別にローテーションしてください。署名の失敗、重複率、遅延、デッドレター、不明なイベントの種類を監視します。認証されたWebhookは、設定されたシークレットのもとでの送信元を証明するものであり、関連付けに成功するまでは、そのイベントが正しい内部のジョブに対応付けられたことを証明するものではありません。

推測した文言ではなく、ステータスの系統で診断する

まず拡張ステータスのサブジェクトを確認します。アドレスの状態、メールボックスの状態、メールシステムの状態、ネットワークやルーティングの状態、メール配信プロトコルの状態、メッセージの内容やメディアの状態、セキュリティとポリシーの状態のいずれかです。次に、詳細コードと診断メッセージ全体を、最新の受信側またはプロバイダーのドキュメントと照らし合わせます。アドレスの失敗であれば受信者の構文とドメインのDNSを、メールボックスの失敗であればメールボックスの存在とクォータの証拠を、転送の失敗であればMX、ルーティング、TLS、ネットワークの証拠を、メッセージの失敗であればサイズ、MIME、エンコーディング、内容を、セキュリティの失敗であればSPF、DKIM、DMARC、認証情報、送信者ポリシー、レピュテーションを確認してください。管理下の再テストごとに変更する変数は1つにとどめます。恒久的なポリシー上の判断を回避するためにIP、ドメイン、プロバイダーを切り替えてはいけません。元の応答を保存し、観測された原因を修正しないまま送信者の権限を広げたり認証を弱めたりする設定変更は、ロールバックしてください。

受信者データを漏らさずにバウンスの健全性を測定する

初回試行での受け付け、一時的な遅延、恒久的な失敗、再試行による回復、不明な結果、苦情、サプレッション、キューの滞留時間を、プライバシー上安全なコホートごとに追跡します。有用な分析軸には、送信ドメイン、承認された集計レベルでの宛先ドメイン、メッセージの種類、テンプレートのリビジョン、プロバイダー、ステータスの系統、時間があります。日常的な分析には、完全なアドレス、メッセージの内容、診断メッセージの生データ、rawのヘッダーを含めないでください。無効な受信者の割合を、ポリシー、認証、内容、レピュテーション、一時的なインフラの失敗と分けて集計します。単一のバウンス率では、対処可能な原因が見えなくなります。分母には受信者ごとの試行数を使い、遅れて届いたイベントは元のコホートに計上してください。アラートは、万能のパーセンテージひとつではなく、過去のベースラインとビジネス上のリスクに基づいて設定します。サプレッションの適用と手動での上書きを監査しましょう。運用、セキュリティ、法的義務、紛争対応に必要な証拠だけを保持し、その後は削除するか集計してください。バウンス率が低くても、同意、エンゲージメント、受信トレイへの到達が証明されるわけではありません。

SendHQの位置付け

SendHQは配信とバウンスの追跡、およびサプレッションを文書化しています。サポートされる動作については最新のドキュメントを参照してください。

よくある質問

出典

• RFC 3464：配信状態通知のための拡張可能なメッセージ形式 — RFC Editor
• RFC 3463：メールシステムの拡張ステータスコード — RFC Editor
• RFC 5321：簡易メール転送プロトコル（SMTP） — RFC Editor
• RFC 3834：電子メールへの自動応答に関する推奨事項 — RFC Editor