メール バウンス率とは？測定方法・目安・改善策
要約
メール バウンス率とは、受信サーバーが拒否した送信メールの割合です。健全なリストではハードバウンスを1%未満に抑え、2%で調査を始め、5%はインシデントとして扱ってください。Amazon SESは5%以上でアカウントを審査対象にします。率はストリーム、送信元、バウンス種別ごとに分けて集計し、SMTPステータスコードを保存しておくと、リストの問題とレピュテーションの問題を見分けられます。
メール バウンス率は、受信サーバーに拒否された送信メールの割合です。計算式は単純ですが、分母、バウンスの種類、集計期間によって数字が大きく変わります。健全なリストではハードバウンスを1%未満に保ち、2%を超えたら原因を調べ、5%はインシデントとして扱うのが目安です。多くのチームはダッシュボードに出る1つの合算値だけを見ていますが、それでは問題の所在を見落としがちです。
この記事では、まず数字を正しく読む方法を説明し、そのあとで対処法を扱います。
計算式は単純です。分母で意見が分かれます。
バウンス率は、バウンスしたメール数を送信したメール数で割り、100を掛けたものです。ESPによっては送信数ではなく到達数で割るため、同じ件数でも数字が高く見えます。ベンチマークと比較する前に、利用しているプロバイダーがどちらを分母にしているかを確認してください。
たとえばAmazon SESは、ハードバウンスだけを対象に、アカウントから送信した数を基準としてバウンス率を計算します。ソフトバウンスとハードバウンスを混ぜたダッシュボードでは、プロバイダーがあなたを評価する数字より高い値が出てしまいます。
定義を1つに決めて、指標の名前のそばに書いておきましょう。私たちは送信ドメインごとに、24時間と7日間の単位で、ハードバウンス数を送信数で割った値を使っています。チーム内で同じ週の数字が食い違うなら、まず分母を比べてください。
ハード、ソフト、ブロックは別々のシグナルです
ハードバウンスは恒久的な失敗です。アドレスが存在しない、ドメインが名前解決できない、メールボックスが閉鎖されている、といった場合に起きます。SMTPでは、RFC 3463で定義された5.x.x形式の拡張ステータスコードとして返されます。
ソフトバウンスは一時的な失敗です。メールボックスが満杯、サーバーが停止中、メールサイズが大きすぎる、などが該当します。4.x.x形式で返され、適切な送信者は再送します。SMTPコードの分類については、当社の以前の記事でソフトバウンスとハードバウンスの違いとして扱っています。
3つ目は、ダッシュボードでは見えにくい種類です。ブロックは5.x.x形式で拒否されますが、原因はアドレスではなく送信者側にあります。たとえば、IPがブロックリストに載っている、認証チェックに失敗した、コンテンツやレピュテーションのフィルターに引っかかった、といったケースです。ブロックをハードバウンスとして数えると、リストが汚れているように見えますが、実際の問題は送信環境にあります。
「バウンス」という1本の系列だけを表示するレポートは避けてください。3つの系列に分けないと、問題のないリストを掃除することになりかねません。
2026年の良いバウンス率はどのくらいでしょうか？
公開された単一の基準値はありません。これは数字を引用する前に知っておくべき点です。GmailとYahooは迷惑メールの報告率についてはしきい値を公開していますが、バウンスについては公開していません。Googleは一括送信者に対し、Postmaster Toolsで報告される迷惑メール率を0.10%未満に保ち、0.30%には決して達しないよう求めています。詳しくはGoogleの送信者ガイドラインFAQを参照してください。
バウンスについては、ESPの運用経験から導かれた目安を使います。以下は当社が警告レベルとして使っている値で、メールボックスプロバイダーが保証する値ではありません。
ドメインごとに24時間で集計したハードバウンス率と、その対応は次のとおりです。
0.5%未満: エンゲージメントの高い認証済みリストでは通常の範囲です。
0.5%から1%: 注意して、新しいアドレスの取得元を確認します。
1%から2%: 調査し、率が最も高いセグメントの送信を一時停止します。
2%から5%: そのストリームからの一括送信を止め、原因となるインポートやフォームを探します。
5%超: インシデントです。Amazon SESはこの水準のアカウントを審査対象にします。
最後の行は文書化された基準です。Amazon SESのレピュテーションダッシュボードのドキュメントでは、バウンス率が5%以上のアカウントは審査対象になり、10%を超える状態が続くと送信が停止される可能性があると明記されています。他のプロバイダーは別の数値や表現を使っているため、必ずご自身の契約内容を確認してください。
まずセグメントに分けてください。合算値では問題のあるストリームが見えません
アカウント全体で0.8%というバウンス率の中に、トランザクションメールの0.1%と、再エンゲージメント用インポートの6%が含まれている可能性があります。合算値は許容範囲に見えますが、後者が送信ドメインをじわじわと傷つけています。
率はストリーム別、登録元別、受信ドメイン別に計算してください。次の4つの切り口で、ほとんどの問題が見つかります。
ストリーム別: トランザクション、ライフサイクル、一括キャンペーンで同じ数字を共有してはいけません。
登録元別: フォーム、API経由の登録、CSVインポート、パートナーリストでは、アドレスの品質が大きく異なります。
受信ドメイン別: 特定のプロバイダーでだけ急上昇するのは、リストの汚れではなく、そのプロバイダーの拒否ポリシーが原因であることが多いです。
アドレスの経過期間別: 12か月以上前に取得したアドレスは、新しいものよりバウンス率が高くなります。
これは単なるレポートの工夫ではありません。フォームの検証バグを1時間で直すか、健全なリストをパニックで消去してしまうかの違いになります。
もう1つ、他の切り口が揃ったら加えたいのが、送信IPまたはドメインごとの集計です。トランザクション用に専用IPを、キャンペーン用に共有プールを使っている場合、どちらかで急上昇すれば、ログを1行も開く前にどこを調べるべきかが分かります。
プロバイダーのバウンスイベントを取りこぼさずに読む方法
主要なESPは、バウンスをイベントとして提供しています。Webhook、通知トピック、イベントAPIのいずれかです。このフィードを信頼できる情報源として扱い、自分のストアに書き込んでください。ダッシュボードは集計の時点で詳細を失うため、後で原因を調べる際に必要な情報が残りません。
イベントごとに次の項目を保存します。メッセージID、受信者、バウンス種別、拡張ステータスコード、診断テキスト、タイムスタンプです。この6つがあれば、事後分析で出てくる質問のほとんどに答えられます。
{
"event": "bounce",
"message_id": "msg_01H9",
"recipient": "user@example.com",
"bounce_type": "permanent",
"status": "5.1.1",
"diagnostic": "550 5.1.1 user unknown",
"stream": "lifecycle",
"ts": "2026-11-02T09:14:03Z"
}イベントを処理するハンドラーは冪等にしてください。プロバイダーはWebhookを再送することがあり、同じハードバウンスを2回数えると、率が歪むうえに、問題のないアドレスを抑止してしまう可能性があります。キーはプロバイダーのイベントIDとメッセージIDの組み合わせにしましょう。
PostmarkとResendは、イベントでバウンス種別を分けており、メッセージストリーム単位で取得できます。そのため、上記のストリーム別の分割を低コストで実装できます。
最も効果の大きい抑止ルール
最もレバレッジの大きい対策は自動抑止です。ハードバウンスが1回発生したら、そのアドレスへの送信を、プロバイダーのリストだけに頼らず、アプリケーション層で恒久的に止めてください。
多くのESPは、ハードバウンスを自動で抑止します。ただし、プロバイダーを切り替えた場合、2つのプロバイダーを並行して使っている場合、抑止リストを読まないシステムから送信している場合には、抜け穴ができます。正規化したアドレスをキーにした自社のテーブルを持てば、その抜け穴を塞げます。
ソフトバウンスには、単発のイベントではなくカウンターを使います。当社の標準設定では、少なくとも7日間にわたって連続3回ソフトバウンスしたアドレスを抑止します。1週間満杯のままのメールボックスは、ライフサイクルの観点では使われていないのと同じです。
バウンスしたアドレスはユーザーテーブルから削除しないでください。ステータスコードと日付を付けてフラグを立ててください。削除された行からは、同じアドレスが前の四半期に2回バウンスしたことは分かりません。次のCSVから同じアドレスを再インポートしてしまうのを防ぐには、その記録が必要です。掃除したはずのリストがまた汚れる、最も一般的な原因です。
バウンス率が急に上がる原因：よくある順位
率が動いたら、次の順序で原因を探してください。最初の3つで、ほとんどの急上昇を説明できます。
新しいインポート。 イベント、パートナー、古いCRMからのエクスポートによるCSVです。他の何よりも先に、取得元別のバウンス率を確認してください。
検証のない登録フォーム。 gmial.comのようなタイプミスや使い捨てドメインです。送信時の構文チェックとMXチェックで大半を取り除け、残りは確認メールで、ライフサイクルフローの送信として数えられる前に除去できます。
送信環境の変更。 新しいIP、新しいドメイン、またはウォームアップが速すぎた場合です。これらはハードバウンスではなく、ブロックとして現れます。
認証の不具合。 DNSを変更した後にSPF、DKIM、DMARCのアライメントが失敗する場合です。
プロバイダー側の拒否ポリシー。 受信ドメインがフィルターを厳しくした場合です。その受信ドメインでだけ率が上がります。
診断には、急上昇と同じ期間について、ストリームと受信ドメインごとのステータスコードの分布を見ます。5.1.1（ユーザー不明）の増加はリストの問題を示します。5.7.xの増加はポリシー、認証、またはレピュテーションの問題を示します。両者は逆の対処が必要になるため、ステータスコードを保存しておくことが重要です。
私たちがアラートにするもの
日次平均でアラートを出すのは遅すぎます。誤ったインポートは1時間で4万通を送ってしまうことがあります。代わりにローリングウィンドウでアラートを設定します。
いずれかのストリームで、直近1,000通の送信に対するハードバウンス率が1%を超えた場合。
1時間に200通以上送信した受信ドメインのいずれかで、率が5%を超えた場合。
5.7.xのブロック数が、通常のベースラインを明らかに上回った場合。
最初の2つは、人間へのページングではなく、該当ストリームの一時停止に接続してください。調査は後からできます。一時停止こそが、次の10分間のレピュテーションを守ります。
率は、すでに使っている監視基盤、たとえばGrafana、Datadog、または自社のツールにエクスポートしてください。エクスポート後もストリームのラベルを系列に残しておけば、分割した情報が失われません。
経営層への報告では、7日間のウィンドウでのストリーム別ハードバウンス率と、ブロックの件数を使ってください。ソフトバウンスはエンジニアリングのビューに残し、経営層向けのレポートからは外すと混乱を避けられます。アカウント全体の合算値だけを報告するのは避けてください。その数字は、会議の場で誰も説明できない理由で動くからです。
数字を1つだけ求められたら、トランザクションストリームのハードバウンス率を出してください。そこでの失敗はパスワードリセットや請求書の取りこぼしにつながり、インフラが健全かどうかを最も明確に示す数字です。
次の具体的な一歩は小さなものです。直近30日分のバウンスイベントを取得し、ストリームとステータスコードでグループ化して、予想外の行がないかを確認してください。