メールの不達（バウンス）管理

2026 2/04

2026年2月4日 2026年2月4日

本記事について

本記事は、2024年2月に社内で実施した勉強会の内容をもとに、社外公開用テックブログ向けに加筆・再構成したものです。
記載の内容は執筆当時の情報であり、現在の仕様やベストプラクティスと異なる可能性があります。
実装にあたっては、必ず最新の公式ドキュメントをご確認いただくようお願いいたします。

背景

時折、「メールがユーザーに届いているか確認したい」「届いていない場合に何らかの対応を取りたい」といったご相談を受けることがあります。
本記事では、システム側で対応可能な範囲と、その対応方針の例を整理します。

対象について

“メールが届く”とは

1.受信側メールサーバが、メールを正常に受け付けていること
2.受信側メールサーバが、ユーザーが確認できる受信トレイにメールを振り分けること

なお、(2) については、送信側システムから確認する手段がないため、本記事では対象外とします。

実際には、「迷惑メールフォルダに振り分けられる」「受信側メールサーバによって破棄される」などの理由で、メール自体は正常に送信されていたとしても、ユーザーが確認できないケースも存在します。

バウンスメールとは

バウンスメールとは、受信側のメールサーバがメールを正常に受け付けなかったことを通知するメールです。

バウンスメールには、以下のような情報が含まれます。
・バウンスが発生した日時
・バウンスを返したメールサーバ
・SMTPエラーコード
・バウンスの理由

一般的なバウンスメールの種類

種類	概要	原因例
ソフトバウンス	一時的な理由による配信エラー	受信者のメールボックスが一杯メールサイズが大きすぎる受信側のサーバーがダウンしている
ハードバウンス	恒久的な理由による配信エラー	メールアドレスが存在しないメールアドレスが不正

エラーコード（SMTPステータスコード）例

450	Requested mail action not taken: mailbox unavailable	相手先のメールボックスが利用できない（ロックされているなど）ため、処理が実行できない。
451	Requested action aborted: local error in processing	処理中にエラーが発生したため、要求された処理が失敗した。※多くの場合、受信側のサーバエラーが原因で発生。
452	Requested action not taken: insufficient system storage	システムストレージ容量が不足なため、要求された処理は実行できない。
500	Syntax error, command unrecognized	文法に間違いがある、もしくは1行に対する文章が長すぎる。
501	Syntax error in parameters or arguments	パラメータまたは引数の文法に誤りがある。
502	Command not implemented	指定されたSMTPコマンドが実装されていない。
503	Bad sequence of commands	SMTPコマンドの発行順序が間違っている。
504	Command parameter not implemented	指定されたSMTPコマンドのパラメータが実装されていない。
550	Requested action not taken: mailbox unavailable	宛先のメールボックスが存在しない、もしくはメールボックスが利用できないため、要求された処理は実行できない。
551	User not local; please try [forward-path]	受信者が存在しないため、[forward-path]で示されたアドレスへの転送を試す必要あり。
552	Requested mail action aborted: exceeded storage allocation	相手先のメールボックスの容量超過のため、要求された処理が実行できない。
552	Requested action not taken: mailbox name not allowed	相手先のメールボックスの名前が不適切なため、要求された処理が実行できない。
554	Transaction failed	メール転送処理に失敗もしくは、SMTPサービスが存在しない（接続開始時の応答の場合）。

ベアメールブログ, メールのエラーコード（SMTPステータスコード）の意味と対策：https://baremail.jp/blog/2021/02/25/1020（2024年2月閲覧）

バウンス率が高い場合の影響

メールがバウンスし続けると、ISPが送信元を危険と見なし、メールの受信拒否を行う可能性が高まります。

さらにバウンスし続けると、ブラックリストに登録される可能性が高まります。ブラックリストに登録されると、他のISPでもメールが受信拒否される可能性が高まりますのでご注意ください。

また、SendGridではユーザの送信状況をモニタリングしており、バウンス率が非常に高いなど異常な状態だと判断された場合は、アカウント停止などの措置をとることがあります。日頃からバウンスメールに対する対処を行い、クリーンな状態をキープすることを強く推奨します。
株式会社構造計画研究所,サポート＞よくあるご質問＞トラブル対策＞メールがバウンスし続けると何か問題はありますか： https://support.sendgrid.kke.co.jp/hc/ja/articles/203392195-メールがバウンスし続けると何か問題はありますか（2024年2月参照）

目安として、AWS SESではハードバウンス率を5%未満に抑えることが推奨されていました。

バウンスに対しての配信サービスの対応

株式会社構造計画研究所,ドキュメント＞チュートリアル＞バウンスを管理する＞バウンス（メールの不達）を管理する：https://sendgrid.kke.co.jp/docs/Tutorials/A_Transaction_Mail/manage_bounces.html（2024年2月閲覧）

	ソフトバウンス	ハードバウンス
発生後のSendGridの挙動	宛先がメールを受け付けない場合、Deferredイベントを発生させる。メールが受け付けられるまで最長72時間自動的に再送を続ける。再送間隔は徐々に長くなる。再送を繰り返しても受け付けられなかった場合、宛先アドレスをブロック（Block）リストに登録して、Blockイベントを発生させる。	宛先アドレスをバウンス（Bounce）リストに登録し再送は行わない。Bounceイベントを発生させる。
メール送信者による再送	特に設定変更なしで可能	バウンスリストに掲載された宛先に送信すると自動的にドロップ（破棄）されるため、再送前にバウンスリストから削除する必要がある。ドロップ時はDropイベントが発生する。

バウンス率を抑えるための事業者側の対応例

AWS公式ドキュメント：
https://docs.aws.amazon.com/ja_jp/ses/latest/dg/success-metrics.html（2024年2月閲覧）
より

ハードバウンスしたアドレスにメッセージを再送信しないでください。ハードバウンスの繰り返しは加算されて、最終的に受信者の ISP から悪い評価を受けることになります。（sendgridはデフォルトでやってくれるが別の配信サービスを使う場合は要確認）
メールリストのレンタルや購入は絶対にしないこと。レンタルや購入したリストには、大量の無効なアドレスが含まれている場合があり、ハードバウンス率が大幅に増える原因となります。さらに、これらのリストには、スパムトラップが含まれている可能性があります。それは違法な送信者を捕まえるために限定的に使用される E メールアドレスです。メッセージがスパムタラップに陥ると、配信率と送信者の評価は決定的に損なわれる場合があります。
リストを最新状態に保つこと。受信者に久しぶりにメールを送る場合は、他の手段 (ウェブサイトのログインアクティビティや購入履歴など) で受信者のステータスを確認します。
お客様のステータスを確認する方法がない場合は、ウィンバックメールの送信を検討する。一般的なウィンバックメールでは、お客様からの連絡が途絶えていることをお客様に伝え、引き続きメールの受信を望む場合は確認の返信をしてもらいます。ウィンバックメールの送信後に、返信がなかったすべての受信者をリストから消去します。