メール / メール運用
バウンスメールとは
Bounce mail。配送できなかったメールについて送信側へ返る失敗通知です。
用語集内のカードを見るこの記事で学べること
バウンスメールを、定義だけで終わらせず、現場で出てくる場面、確認材料、見落としやすい点、関連語とのつながりまで順に確認できます。
- バウンスメールを読むときの前提
- 一時失敗と恒久失敗を分ける
- 原因を分類する
- Return-Pathと利用者通知を見る
- 変更証跡と引き継ぎ
実務メモ
SMTP応答、Return-Path、元メールを同じチケットで残す
どこで効くか
バウンスメールは宛先不明、容量超過、受信側拒否、DNS不備、ポリシー拒否などの配送失敗調査で効きます。利用者に届いた通知だけでなく、MTAログと送信サービスのイベントも見ます。
残す証跡
証跡にはバウンス本文、SMTPステータスコード、拡張ステータス、応答文、元メールのMessage-ID、宛先、Return-Path、送信時刻、相手MTA、MTAログを残します。
避けたい誤解
5xxは恒久失敗、4xxは一時失敗が多いですが、応答文や相手サービスの実装で扱いが変わります。宛先ミス、認証失敗、レピュテーション低下を同じ原因として扱うと対応を誤ります。
まず確認すること
- バウンス原文とSMTP応答を保存する
- 一時失敗か恒久失敗か分類する
- Return-Pathと送信サービスログを確認する
バウンスメールを読むときの前提
バウンスメール（Bounce mail）は、配送できなかったメールについて送信側へ返る失敗通知です。宛先不明、容量超過、受信側拒否、DNS不備、ポリシー拒否など、失敗理由を利用者や管理者へ伝える材料になります。
実務では、SMTPステータスコード、拡張ステータス、応答文、Message-ID、送信元MTA、相手MTA、Return-Path、再送有無、キュー滞留、SPF/DKIM/DMARC判定を合わせて確認します。
証跡には、バウンス本文、元メールのMessage-ID、送信時刻、宛先、SMTP応答、MTAログ、Return-Path、確認時刻を残します。
一時失敗と恒久失敗を分ける
SMTPの4xxは一時失敗として再送されることが多く、5xxは恒久失敗としてバウンスになることが多いです。ただし、相手MTAやサービスの実装により扱いが異なるため、コードだけでなく応答文も読みます。
利用者から「送れない」と言われたとき、すぐに宛先間違いと決めず、再送中か、最終失敗か、送信側キューに残っているかを確認します。
- SMTPステータスコードと応答文を保存する。
- 4xx/5xxと再送有無を分ける。
- 最終バウンス化した時刻を確認する。
原因を分類する
バウンス原因は、宛先不存在、メールボックス容量、受信側ポリシー、添付サイズ、DNS/MX不備、TLS必須失敗、SPF/DKIM/DMARC失敗、レピュテーション低下などに分かれます。
応答文には相手先固有の説明やURLが含まれることがあります。翻訳や要約だけでなく、元の応答を残すとエスカレーションしやすくなります。
- 宛先、容量、ポリシー、DNS、認証で分類する。
- 相手MTAの応答文を原文で残す。
- 同じ宛先ドメインで再現するか確認する。
Return-Pathと利用者通知を見る
バウンスはエンベロープFromやReturn-Path側へ返るため、利用者が見ているHeader Fromへ戻るとは限りません。委託送信SaaSでは、サービス側のイベントログにだけ失敗が残ることがあります。
問い合わせ対応では、利用者に届いたバウンス、送信サービスの失敗ログ、MTAログを突合します。通知が利用者に届かない構成なら、運用側で監視が必要です。
- Return-Pathとバウンス戻り先を確認する。
- 送信SaaSのイベントログを確認する。
- 利用者へ通知される範囲を記録する。
変更証跡と引き継ぎ
バウンス対応では、対象メール、宛先、時刻、SMTPステータス、相手MTA、分類、一次対応、再送要否、利用者連絡、戻し条件を残します。繰り返す場合は送信元評価やDNS設定も見直します。
引き継ぎでは、メール基盤管理者、アプリ所有者、SaaS所有者、関連語としてSMTPステータスコード、メールキュー、再送、エンベロープFromを残すと確認しやすくなります。
- バウンス原文と分類をチケットに残す。
- 再送するか設定修正を待つか判断する。
- 頻発時は送信元評価と認証結果を確認する。
関連語
同じ主要カテゴリの用語
メールの学習順
同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。