この用語をシェア
バウンスメールとは
バウンスメール（Bounce Mail）は、配送失敗したメールの送信者への通知です。NDR（Non-Delivery Report）やDSN（Delivery Status Notification）とも呼ばれます。受信側メールサーバーまたは中継サーバーが、メール配送に失敗した場合、送信者に対してエラー内容を通知します。
バウンスメールの種類
ハードバウンス（Hard Bounce）
恒久的な配送失敗で、再送信しても成功しないケース：
- 存在しないアドレス: User unknown（550 5.1.1）
- 無効なドメイン: Domain not found（550 5.1.2）
- 受信拒否: Recipient rejected（550 5.7.1）
- メールボックス無効: Mailbox unavailable（550 5.2.1）
ソフトバウンス（Soft Bounce）
一時的な配送失敗で、再送信により成功する可能性があるケース：
- メールボックス満杯: Mailbox full（452 4.2.2）
- サーバー一時停止: Server temporarily unavailable（450 4.4.1）
- メッセージサイズ超過: Message too large（552 5.3.4）
- Greylisting: Temporary failure（450 4.7.1）
バウンスメールの構造
典型的なバウンスメール
From: MAILER-DAEMON@mail.example.com
To: sender@example.com
Subject: Undelivered Mail Returned to Sender
This is the mail system at host mail.example.com.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
: host mx.example.com[192.0.2.100] said:
550 5.1.1 : Recipient address rejected:
User unknown in local recipient table (in reply to RCPT TO command)
自社メールサーバー運用への応用
バウンス処理設定（Postfix）
# main.cf
# バウンス通知先
bounce_notice_recipient = postmaster
2bounce_notice_recipient = postmaster
# バウンス保持期間
bounce_queue_lifetime = 5d
maximal_queue_lifetime = 5d
# バウンスメールサイズ制限
bounce_size_limit = 50000
バウンス率の監視
高いバウンス率は、以下の問題を示唆します：
バウンス処理の自動化
# バウンスメール分析スクリプト例
# /var/log/mail.log からバウンス抽出
grep "status=bounced" /var/log/mail.log | \
awk '{print $7}' | \
sort | uniq -c | sort -rn
バウンスアタック対策
Backscatter問題
偽装送信者アドレスによるスパム送信により、無関係な第三者にバウンスが届く問題：
Postfixでの対策
# main.cf - 受信時検証
smtpd_recipient_restrictions =
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
reject_unverified_recipient,
permit
DSN（Delivery Status Notification）の技術仕様
バウンスメールは、RFC 3461/3464で標準化されたDSN（Delivery Status Notification）形式で送信されるのが一般的です。DSNには、機械可読なmessage/delivery-statusパートが含まれ、配送失敗の理由をステータスコード（例: 5.1.1）で構造化して記録します。
Content-Type: message/delivery-status
Reporting-MTA: dns; mail.example.com
Final-Recipient: rfc822; recipient@example.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 User unknown
この構造化データにより、送信側システムはバウンス理由をプログラムで自動解析し、リスト管理システムに反映できます。
メリット・デメリット
メリット
- 配送状況の可視化: 送信者が配信失敗を即座に把握できる
- リスト衛生の維持: 無効アドレスを機械的に検出・除外できる
- トラブルシューティング: エラーコードから原因（認証失敗、容量超過等）を特定できる
デメリット
- Backscatter（誤配送）のリスク: 送信者アドレスが詐称されたスパムに対してバウンスを返すと、無関係な第三者に届いてしまう
- 情報漏洩の可能性: エラーメッセージに内部のユーザー一覧情報が含まれる場合、攻撃者にアカウント存在有無を推測されるリスク（ユーザー列挙攻撃）
- 処理負荷: 大量送信時のバウンス処理はサーバーリソースを消費する
類似の配送失敗通知方式との違い
| 方式 | 通知タイミング | 形式 | 主な用途 |
|---|---|---|---|
| バウンスメール（DSN） | 配送失敗の直後 | RFC 3464準拠のメール | 送達失敗の即時通知 |
| FBL（Feedback Loop） | 受信者が「迷惑メール報告」をした時 | ARF（Abuse Reporting Format） | 受信者の苦情を送信者にフィードバック |
| VERP | バウンス受信時 | エンベロープFromにID埋込 | バウンスと送信先の一意な紐付け |
大規模配信システムでは、DSNによるバウンス検知に加えて、Gmail・Yahoo!・Microsoftなどが提供するFBLに登録し、開封後の「迷惑メール報告」も合わせて監視することが推奨されます。
実務での活用シーン・導入時の注意点
2024年以降のGmail・Yahoo!送信者ガイドラインでは、月間5,000通以上を送信する送信者に対してスパム報告率0.3%未満の維持が求められており、バウンス率とスパム報告率の両方を監視する体制が実務上ほぼ必須になっています。自社Postfixサーバーで大量配信を行う場合は、VERPを使った個別バウンス追跡と、DSNの自動パースによるリスト管理の自動化を組み合わせることが2026年時点のベストプラクティスです。またBackscatter対策として、存在しないユーザー宛のメールは受信時（SMTP応答時）に拒否し、受理後にバウンスを生成しない設計にすることが強く推奨されます。
関連ブログ記事
まとめ
バウンスメールは、配送失敗の通知機能として重要ですが、適切な処理が必要です。自社メールサーバーでは、ハードバウンスの即時処理、ソフトバウンスの再送管理、バウンス率の監視により、メール配送の品質を維持できます。バウンスアタック対策として、受信時の厳格な検証が重要です。
AIエンジニアとしての実務経験
バウンスメール処理で最も重要だったプロジェクトは、AI生成ニュースレター配信システムでのバウンス管理でした。数万件の配信先に対し、バウンス率を2%以下に抑えないとIPレピュテーションが低下するという厳しい条件がありました。
まず、バウンスメールを自動解析するPythonスクリプトを開発しました。DSN（Delivery Status Notification）のRFC形式を解析し、SMTPステータスコード（5xx/4xx）からハードバウンス/ソフトバウンスを自動分類。ハードバウンスのアドレスは即座にサプレッションリストに追加し、再送信を防止しました。
興味深かったのは、バウンスメッセージの解析にLLMを活用したことです。SMTPエラーコードだけでなく、エラーメッセージのテキストを分析して、「メールボックス満杯」「一時的な障害」「恒久的に無効」を判別しました。特に日本語のエラーメッセージの解析精度が向上し、ソフトバウンスの適切な再送タイミング判断に役立ちました。
バウンスメールの最新動向（2025年）
- VERPアドレス: Variable Envelope Return Pathによるバウンス追跡の標準化
- FBL（Feedback Loop）: 大手プロバイダーとの苦情フィードバック連携の普及
- AI解析: バウンスメッセージの自然言語処理による自動分類
- リアルタイム検知: Webhook通知によるバウンス即時対応
- Backscatter対策: 受信時拒否の徹底によるバウンス生成抑制
よくあるトラブルと失敗例
- バウンス無視: ハードバウンスアドレスへの再送信でIPレピュテーション低下。即時サプレッション必須
- Backscatter加担: 偽装メールにバウンス返信して第三者に迷惑。受信時検証強化
- キュー肥大化: ソフトバウンスの再送でキューが膨張。
maximal_queue_lifetime設定 - バウンス率未監視: 知らないうちに5%超えてブラックリスト登録。定期的なモニタリング
- DSN解析ミス: エラーコードの誤解釈でソフトバウンスをハードバウンス扱い
- ダブルバウンス: バウンスメールのバウンスが発生しループ。
double_bounce_sender設定
権威ある外部リソース
2025-2026年の最新動向
バウンス管理の自動化が進み、Amazon SESやSendGridなどのメール配信サービスがバウンス処理・リスト管理を自動化しています。VERP（Variable Envelope Return Path）による正確なバウンス追跡が標準となっています。
Gmail/Yahoo!の送信者要件でバウンス率の監視が厳格化され、バウンス率が高い送信者は配信制限を受けるようになっています。定期的なリストハイジーンが必須です。
AIによるバウンス予測が実用化され、送信前にバウンスリスクの高いアドレスを検出・除外する技術が普及しています。
外部リンク
関連用語
よくある質問（FAQ）
Q. バウンスメールとは？
メール配信失敗時に返送される通知です。ハードバウンス（永続的エラー）とソフトバウンス（一時的エラー）の2種類があります。
Q. ハードとソフトの違いは？
ハードバウンスは宛先不存在等の永続的失敗、ソフトバウンスは容量超過等の一時的失敗です。ハードバウンスはリストから即削除してください。
Q. バウンス率を下げるには？
リストのクリーニング、ダブルオプトイン導入、SPF/DKIM/DMARC設定、PTRレコード設定が効果的です。2%以下を維持しましょう。
Q. DSNとは何ですか？
DSN（Delivery Status Notification）は、RFC 3461/3464で標準化された配送状態通知の形式で、機械可読なステータスコードを含むバウンスメールの標準フォーマットです。
Q. Backscatterを防ぐには？
存在しない宛先へのメールをキューに受理してからバウンスするのではなく、SMTP受信時（RCPT TOコマンド時点）で550エラーを返して拒否することで、詐称された送信者へのバウンス誤配送を防げます。