メール配信エラーDSN・バウンスの分類｜恒久・一時エラーと再送停止を揃える運用

メール配信エラーを安全に処理するには、配信サービスの「ハードバウンス」「ソフトバウンス」という表示だけで判断せず、受信者ごとのDSNに含まれるAction、Status、Diagnostic-Codeを保存し、恒久停止、一時保留、内容修正、経路調査へ正規化します。特に、5.x.xだからすべて宛先削除、4.x.xだから無条件に再送、という一律処理は避けます。

RFC 3464では、DSNのActionはfailed、delayed、delivered、relayed、expandedのいずれかで、受信者ごとに記録されます。Statusは2.x.xが成功、4.x.xが持続的な一時失敗、5.x.xが恒久失敗を表します。ただし、4.x.xでも再送を打ち切った時点ではAction: failedになり得ます。再送可否はステータスの先頭数字だけでなく、Actionと診断内容を組み合わせて決める必要があります。

実務では、5.1.1のような存在しない宛先は受信者単位で直ちに抑止し、4.2.2のような一時的な容量不足は配信基盤の再試行へ任せます。5.3.4のようなメッセージ側の問題や5.7.1のようなポリシー拒否は、宛先を無効扱いにせず、本文サイズ、認証、送信経路、レピュテーションを調査します。配信サービス独自の分類は、この共通ルールへ変換し、元の値も残します。

---

本記事のポイント

1. SMTP応答は配送中のコマンド応答、DSNは配送結果を受信者単位で伝える機械可読の通知です。両者を同じ配信イベントへ関連付けます。
2. 判断はAction、拡張ステータスコード、診断文、再試行履歴を組み合わせ、宛先、メッセージ、送信経路のどこを直すか分けます。
3. 配信サービスのhard、soft、undeterminedなどの名称は共通分類へ変換し、抑止、保留、解除、再送の証跡を残します。

---

DSNとSMTP応答の違いを受信者単位で整理する

SMTP応答は、送信側と受信側のメールサーバーが接続し、送信元、宛先、本文をやり取りする途中で返す応答です。RFC 5321では4yzを一時的な否定応答、5yzを恒久的な否定応答とし、4yzは同じ要求を再度行えば成功する可能性があるため再試行し、5yzは同じ要求をそのまま繰り返すべきではないとしています。

DSNはDelivery Status Notificationの略で、配送成功、遅延、失敗などを機械可読形式で通知するメッセージです。1通を複数宛先へ送った場合でも、DSNには受信者ごとのFinal-Recipient、Action、Status、必要に応じてDiagnostic-Codeが入ります。したがって、同じ送信メッセージのうち一人だけが失敗したときに、送信全体や同じ会社ドメインをまとめて停止してはいけません。

Action: delayedは、まだ配送できていないものの、報告したメールサーバーが再試行を続ける状態です。Action: failedは、その受信者への配送を断念した終端状態です。RFC 3464は、4で始まる一時失敗コードでも、数日間の再試行後に断念した場合はAction: failedになり得ると説明しています。つまり、4.x.xを見て新しいキャンペーンから即時再送すると、元のキューの再試行と重複するおそれがあります。

取得値	意味	運用で使う場面	注意点
SMTP応答	配送セッション中の応答	接続、宛先受理、本文受理のどこで拒否されたかを調べる	配信サービスが要約して原文を残さない場合がある
Action	delayed、failedなど配送側が行った処理	再試行中か、すでに断念したかを分ける	4.x.xでもActionがfailedなら元の配送は終了している
Status	2.x.x、4.x.x、5.x.xの拡張ステータス	成功、一時失敗、恒久失敗と原因領域を共通分類する	受信事業者が独自コードや汎用コードを返すことがある
Diagnostic-Code	報告MTAが返した詳しい診断	存在しない宛先、容量、サイズ、認証、ポリシーなどを判別する	メールアドレス等を含み得るため保管権限と期限を決める
配信サービス分類	hard、soft、permanent、transientなど	サービス固有イベントを共通分類へ変換する	名称だけを正本にせず、生コードと原文も保持する

拡張ステータスコードを「どこを直すか」で分類する

RFC 3463の拡張ステータスコードは3つの数字で構成されます。先頭は結果のクラス、中央は原因領域、末尾は詳細です。中央が1ならアドレス、2ならメールボックス、3ならメールシステム、4ならネットワークやルーティング、5なら配送プロトコル、6なら内容や媒体、7ならセキュリティやポリシーに関する状態です。配信担当者に必要なのは数字の暗記ではなく、修正対象を切り分けることです。

代表的な状態	基本判断	止める単位	確認と復旧
failed / 5.1.1 宛先が存在しない	恒久エラー	該当メールアドレスだけを直ちに抑止	入力元とCRMを確認し、本人の別アドレスが確認できた場合だけ新規登録する
delayed / 4.2.2 メールボックス容量不足	一時エラー	新規再送を起動せず、配信基盤のキューへ任せる	期限内の配送結果を待ち、回復しない場合は一時保留へ移す
failed / 4.2.2 再試行後に断念	一時要因だが元配送は終了	該当宛先を期限付き保留	同じ内容を直ちに連投せず、次回配信前に直近の失敗回数と成功履歴を確認する
failed / 5.3.4 メッセージが大きすぎる	内容・システム側の恒久エラー	宛先を無効化せず、該当メッセージを停止	添付、HTML、画像サイズを直し、少数の試験宛先で再確認する
failed / 5.7.1 ポリシーまたはセキュリティ拒否	経路調査が必要	同一送信元や同一ドメイン向け配信を必要範囲で保留	SPF、DKIM、DMARC、送信IP、レピュテーション、受信側ポリシーを確認する
コード不明・診断欠落	未判定	自動削除せず調査キューへ	配信サービスのイベント原文、SMTPログ、受信事業者の公式コード表を確認する

5.x.xは「同じ要求をそのまま再実行しても解決しにくい」という意味であり、必ずしも「宛先が無効」という意味ではありません。5.1.1なら受信者単位の抑止が妥当ですが、5.3.4はメッセージの修正、5.7.1は認証やポリシーの調査が中心です。逆に4.x.xでも、同じ宛先で長期間繰り返し、毎回failedで終わるなら、営業やマーケティングの新規配信を一時保留し、復旧条件を明示します。

送信ドメインの認証異常が疑われる場合は、SPFのDNSルックアップ監視、DKIMセレクタと署名鍵の更新手順、DMARC集計レポートの読み方を合わせて確認します。宛先エラーの問題と送信基盤全体の問題を同じ抑止処理へ混ぜないことが重要です。

再送と抑止を7ステップで運用する

RFC 5321では、配送できないメールはキューへ入れ、送信側が一定間隔で再試行します。一般的な再試行間隔は少なくとも30分、断念までの時間は少なくとも4〜5日が必要とされます。ただし、これはSMTPクライアントの配送戦略です。メール配信担当者が同じ受信者へ新しい送信ジョブを30分ごとに作る指示ではありません。マネージド配信サービスを使う場合は、そのサービスのキューと再試行結果を正本にします。

1. イベントを受信者単位で保存する。配信ID、メッセージID、受信者ID、発生時刻、Action、Status、Diagnostic-Code、配信サービスの分類、試行回数を保存します。メールアドレスを分析用データへ広く複製せず、必要なら受信者IDへ置き換えます。
2. 元の値を失わずに正規化する。hardやPermanentをそのまま社内分類にせず、宛先恒久、宛先一時、内容修正、認証・ポリシー、経路・システム、未判定へ変換します。変換ルールの版も記録します。
3. Actionで配送の途中と終了を分ける。delayedなら既存キューの再試行中、failedなら元配送は終了です。4.x.xか5.x.xだけを見て処理を決めません。
4. 停止単位を決める。5.1.1は該当アドレス、5.3.4は該当コンテンツ、5.7.1の増加は送信元や配信経路というように、影響範囲を必要最小限にします。会社ドメイン全体や取引先レコード全体の一括削除は避けます。
5. 再送の所有者を一つにする。配信基盤が再試行中なら、マーケティング側の自動再送を起動しません。元配送がfailedになった後も、原因が変わらないまま同じメッセージを送り直さず、解除条件と次回確認日を決めます。
6. 抑止と解除を記録する。抑止理由、対象範囲、判断時刻、判断ルール版、解除条件、解除者、復旧テストを一つの履歴へ残します。CRMのメール利用可否と配信サービスの抑止リストがずれないよう同期結果も確認します。
7. 集計でルールを見直す。受信事業者、送信ドメイン、送信IP、キャンペーン、ステータス分類ごとの件数と割合を監視します。特定のコードが急増したら宛先品質だけでなく、認証、内容、配信速度、受信側障害を調べます。

DSN対応が完了するのは、エラーを受け取った時ではなく、受信者単位の状態、再送期限、抑止理由、復旧確認を同じ配信イベントで説明できた時です。

配信サービスごとの分類差を共通ルールへ変換する

配信サービスは、RFCのフィールドに加えて独自の分類を返します。たとえばAmazon SESの通知では、bounce typeとしてPermanent、Transient、Undeterminedを持ち、受信者ごとのstatusやdiagnosticCodeも保持します。別のサービスではhard、soft、blocked、invalidなどの名称を使うことがあります。同じ言葉でも判定条件や粒度が一致するとは限りません。

共通データモデルには、サービスが返した生の分類と社内の正規化分類を分けて保存します。正規化に使う優先順位は、受信者単位のAction、拡張ステータス、診断文、サービス分類、再試行履歴の順にします。値が欠けている場合は推測で恒久抑止せず、未判定へ送ります。

共通項目	保存する内容	用途
識別	配信ID、メッセージID、受信者ID、事業者、発生時刻	同一配信と受信者ごとの状態を追跡する
生データ	Action、Status、Diagnostic-Code、サービス分類、試行回数	変換ミスや事業者仕様変更を後から確認する
正規化	宛先恒久、宛先一時、内容修正、認証・ポリシー、経路、未判定	複数サービスで抑止と調査を同じ手順へそろえる
処理	抑止、既存キュー継続、期限付き保留、内容修正、経路調査	次の自動処理を一意にする
証跡	ルール版、判断者、処理時刻、解除条件、復旧結果	誤抑止を戻し、監査と改善に使う

Google Workspaceの公式ヘルプには、Gmailが返すSMTPエラーと拡張ステータスコードが掲載されています。受信事業者が公式コード表を公開している場合は、診断文の文字列だけでなく、その表の更新日と意味を確認します。独自コードの意味を固定値として長期間埋め込むと、受信側の変更後に誤分類するため、変換ルールには見直し日を付けます。

到達率の改善では、恒久エラーの宛先を止めるだけでなく、苦情、配信停止、認証失敗を別の信号として扱います。メールリストのクリーニング手順、苦情フィードバックループの監視、ワンクリック配信停止の監視と統合し、同じ受信者へ異なる経路から再登録しない仕組みにします。

誤抑止と無限再送を防ぐ監視指標

失敗件数だけを見ると、同じ受信者への複数回の試行が重複し、障害の規模を過大評価します。受信者単位の終端状態を正本にし、配送成功、恒久抑止、期限付き保留、調査中の件数を分けます。集計の分母と時間窓を固定し、配信量の増減による見かけ上の変化と区別します。

• 恒久失敗率：受信者単位でfailedかつ恒久分類になった件数を、終端状態が確定した受信者数で割ります。
• 一時失敗の回復率：delayedまたは4.x.xを経験した受信者のうち、同じ配信IDで最終的にdeliveredになった割合を見ます。
• 未判定率：コードや診断が欠け、共通分類へ変換できなかった割合です。急増時は配信サービスの仕様変更を疑います。
• 誤抑止の解除件数：正当なアドレスを止め、後から解除した件数と原因を記録します。変換ルールの精度改善に使います。
• 重複再送件数：配信基盤が再試行中なのに別ジョブを起動した件数を監視し、再送の所有者が二重になっていないか確認します。

診断文には受信者アドレス、送信元、ホスト名などが含まれることがあります。分析担当者へ原文を無制限に公開せず、閲覧権限、マスキング、保存期間を決めます。統計用途は受信者IDと正規化分類へ置き換え、原文は原因調査に必要な範囲で保管します。

よくある質問

メールのDSNとSMTP応答は何が違いますか？

SMTP応答は配送セッション中にメールサーバーが返す応答です。DSNは配送結果を機械可読形式で通知するメッセージで、受信者ごとにAction、Status、Diagnostic-Codeなどを持ちます。両者を配信IDと受信者IDで関連付けて使います。

5.x.xの恒久エラーを受けた宛先はいつ抑止しますか？

Actionがfailedで、5.1.1など宛先自体の恒久失敗と確認できた時点で、そのアドレスだけを抑止します。5.3.4のメッセージサイズや5.7.1のポリシー拒否では、宛先を無効化せず、内容や送信経路を修正します。

4.x.xの一時エラーは何回・いつまで再送しますか？

配送基盤のキューが再試行を管理します。RFC 5321は一般的な再試行間隔を少なくとも30分、断念までを少なくとも4〜5日としていますが、受信側の診断や配信サービスの仕様に合わせて設定します。マーケティング側で別の再送ジョブを重ねません。

配信サービスごとに異なるバウンス分類をどう揃えますか？

サービスの生分類、Action、Status、診断文、試行履歴を保存し、宛先恒久、宛先一時、内容修正、認証・ポリシー、経路、未判定へ変換します。変換ルールには版と見直し日を付け、生データを上書きしません。

4.x.xがfailedになっているのは矛盾ではありませんか？

矛盾ではありません。4.x.xは原因が一時的で将来は成功し得ることを示しますが、Action: failedは今回の配送を断念したことを示します。元の配送は終了しているため、原因と直近履歴を確認してから次回配信を判断します。

一つの宛先エラーで会社ドメイン全体を止めてもよいですか？

原則として止めません。5.1.1は該当アドレスだけを抑止します。同一ドメインで5.7.1や接続失敗が急増し、送信経路の問題が疑われる場合に限り、範囲を決めて一時保留し、認証と受信側ポリシーを調べます。

DSNは単なる「届かなかった」という通知ではありません。受信者ごとの状態と原因を、宛先、内容、認証、経路へ切り分けるための証拠です。生の情報を残しながら共通分類へ変換し、再送を一つの基盤へ任せ、抑止と解除を記録すれば、到達率を守りながら正当な宛先を誤って失うリスクを減らせます。