バウンスメールとは
バウンスメールは、宛先不明や容量超過などで配送できなかったことを知らせる返送メールです。「bounce」は跳ね返るという意味で、メール運用では配送不能通知を広く指します。
標準化された通知形式はDSN（Delivery Status Notification／デリバリー・ステータス・ノーティフィケーション）です。機械が読める宛先別の状態と、人が読める説明、必要に応じて元メッセージの一部をMIMEでまとめます。
送信ボタンを押したこと、送信サーバーが受け取ったこと、相手のサーバーが受け取ったこと、相手が読んだことは別々です。バウンスが扱うのは主に配送過程の状態です。
拒否が分かる時点は二通りある
相手サーバーがSMTPの会話中に5xxで拒否すれば、直前の送信サーバーはその場で失敗を知ります。利用者の送信アプリが直接その応答を受けていれば、画面にエラーが出て、別の返送メールを作らない場合もあります。
いったん250応答でメッセージを受理したサーバーが、その後のローカル配送に失敗した場合は、受理した側がDSNを生成します。したがって、同じ「届かなかった」でも、失敗した場所と通知を作った主体が異なります。
通知の状態欄を読む
どの受信者についての状態かを示す。複数宛先なら項目も分かれる。
failed、delayed、delivered、relayed、expandedなど、実行された処理を示す。
2.x.x、4.x.x、5.x.xで成功、一時的問題、恒久的失敗の大分類と詳細を示す。
相手サーバーが返したSMTP応答や製品固有の補足が記録される。
DSNを作ったメール転送エージェントを示す。
ある場合は元メッセージの識別子。必須ではなく、これだけで真正性は証明しない。
4xxは再試行、5xxはそのままでは再試行しない
SMTPの4xxは一時的な失敗です。混雑、受信側の一時障害、容量不足、レート制限などが候補で、送信側サーバーは一定期間キューへ保持して再試行します。期限まで成功しなければ最終的な失敗通知になります。
5xxは恒久的な失敗を表し、宛先不存在、方針による拒否、受け入れ不能な内容など、その条件のまま繰り返しても成功しないことを示します。ただし数字だけで利用者の修正方法が一意に決まるわけではなく、拡張状態コードと診断文を読みます。
空の逆方向経路が通知の連鎖を止める
DSNのSMTP エンベロープは、通常、MAIL FROM:<>という空の逆方向経路を使います。その通知自体が配送不能になっても、さらに別のDSNを返さないためです。保存後のReturn-Pathも空の山括弧になります。
通知先は元メールのエンベロープFromです。画面に見えるFromやReply-Toとは限りません。この区別が、配送管理用のアドレスへ集約する仕組みを可能にします。
送っていないメールのバウンスが届くこともある
攻撃者が他人のアドレスを逆方向経路へ偽装し、受信側が受理後に通知を作ると、無関係の人へ大量のバウンスが届きます。これをbackscatter（バックスキャッター）と呼びます。通知が届いた事実だけでは、自分の端末やアカウントが送信した証拠になりません。
一方、アカウント乗っ取りや設定ミスの可能性も残ります。送信済み、ログイン履歴、メールサーバーの送信ログ、Message-ID、時刻、認証結果を照合します。バウンスを装うフィッシングメールもあるため、通知内のリンクからログインしません。
相手へ伝えるときは必要な診断だけを残す
管理者へ相談する場合は、失敗した時刻、宛先ドメイン、Action、Status、Diagnostic-Code、Reporting-MTAを共有します。元本文、他の受信者、認証用トークン、内部ホスト名、個人情報は、問題の切り分けに必要な範囲へ減らします。
「もう一度送る」前に、一時エラーか恒久エラーか、どの宛先だけが失敗したか、通知が本物の配送記録と結び付くかを確認します。
配送状態通知の確認資料：RFC 3461（SMTP DSN Extension）、RFC 3464（DSN Message Format）、RFC 3463（Enhanced Mail System Status Codes）、RFC 5321（SMTP）