キャンペーンを送信し、レポートダッシュボードを開くと、他のあらゆる指標が意味をなさなくなるほど高いバウンス率を目にしたとします。リストをインポートした後に数値が急上昇したのかもしれませんし、同じタイミングで送信者レピュテーションのアラートが表示されたのかもしれません。すぐにメールを書き直したり、件名を変更したり、キャンペーンの責任にしたくなるでしょう。
しかし、それは通常、間違った出発点です。高いバウンス率は、単なるコンテンツの問題ではなく、リスト品質とメール到達率の問題であることが少なくありません。メール運用では一般的に、2%未満を健全、2%から5%を警戒領域、5%超を重大とみなします。また、独立したメールのバウンス率ベンチマークによると、適切に管理されたマーケティング用リストでは、通常バウンス率は2%未満に保たれます。
重要なのは、「なぜバウンス率がこんなに高いのか?」だけではありません。「どの種類のバウンスが発生していて、それが現れる前に何が変わったのか?」という問いです。このガイドでは、メールのバウンスとアナリティクスのバウンスを区別し、インフラ、トラフィック、リストの衛生管理、検証をさかのぼって確認することで、実際の障害を修正できるようにします。
数値に気づく瞬間
典型的なメール到達率の朝は、警告を発するダッシュボードの確認から始まります。キャンペーンレポートには18%のバウンス率が表示され、送信者レピュテーションの指標は低下し、Slackのスレッドにはリスト、クリエイティブ、送信プラットフォームについての質問が次々と寄せられます。誰もが次のキャンペーンが配信される前に答えを求めています。
その数値は症状であって、診断ではありません。50,000件の連絡先に送信した際のバウンス率15%と、2,000件の送信で同じ率が発生した場合では、運用上まったく異なる事象を示します。割合からは配信試行に対する失敗の規模はわかりますが、古いレコード、無効なドメイン、一時的なスロットリング、またはレポート上の問題のどれが原因なのかは特定できません。
キャンペーンを変更する前に、まず次の3つの質問を確認してください。
- プラットフォームはどの定義を使用しているか? ダッシュボードが、拒否されたメールメッセージ、再試行後も配信されなかったメッセージ、または追加の操作を伴わないWebサイトセッションのいずれをレポートしているのか確認します。
- 率はいつ変化したか? 現在の送信を、過去のキャンペーン、リストのインポート、フォームの変更、ドメインの変更、送信インフラの変化と比較します。
- どのセグメントで急増したか? 結果を獲得元、アップロードバッチ、ドメイン、国、キャンペーン、受信者タイプ別に分類します。1つのインポートファイルに限定された問題は、すべてのセグメントに影響する問題とは異なる対応を必要とします。
実務上のルール: 受信者サーバーがメッセージを拒否したのか、それとも分析プラットフォームが単一ページのセッションを記録しただけなのかがわかるまで、メッセージを最適化しないでください。
この区別が重要なのは、チームが恐ろしい数値に反応して、役立つ証拠を消してしまうような大規模な変更を行いがちだからです。誤ったキャンペーンを一時停止したり、オーディエンス全体を削除したり、障害モードを特定する前に認証を変更したりすると、診断が難しくなる可能性があります。
一貫した命名およびレポート作成プロセスを使用し、各送信を元データと比較できるようにしましょう。便利なメールチーム向けの測定ガイドを活用すれば、キャンペーン全体で使用する定義、セグメント、レポート項目を標準化できます。
バウンス率が実際に測定するもの
メールにおいて、バウンス率とは受信者のサーバーによって拒否された送信済みメッセージの割合です。受信サーバーは配信不能応答を返し、送信プラットフォームがその結果を記録します。これは、分析プラットフォームがセッション中に訪問者に別のインタラクションがあったかどうかを評価する、Webサイト指標としてのバウンス率とは異なります。
メールのバウンスは、運用上2つのカテゴリーに分かれます。ハードバウンスは、無効または存在しないアドレス、無効化されたメールボックス、配信不能なドメインなど、恒久的な配信失敗を示します。ソフトバウンスは、受信トレイの容量超過、サーバーのタイムアウト、グレーリスティング、スロットリング、一時的なブロックなど、一時的な問題を示します。
ソフトエラーには、もう一段階の解釈が必要です。一時的なソフトバウンスは、受信サーバーが利用可能になったり、再試行を受け入れたりすると解消する場合があります。継続的なソフトバウンスは再試行後も続き、最終的にはメールサービスプロバイダーによって配信不能と扱われる可能性があります。ほとんどのESPはソフトエラーを自動的に再試行するため、最初のイベントと最終的なキャンペーン結果は同一とは限りません。
| バウンスの種類の概要 | トリガー | 解決方法 |
|---|---|---|
| ハードバウンス | 無効なアドレス、存在しないドメイン、無効化されたメールボックス、または受信者による恒久的な拒否 | アドレスを抑制し、取得元を調査して、再度送信されないようにする |
| 一時的なソフトバウンス | メールボックスの容量超過、一時的なサーバーエラー、タイムアウト、グレーリスティング、または短期的なスロットリング | 管理された再試行を許可し、受信サーバーの応答を確認する |
| 継続的なソフトバウンス | 一時的な失敗の繰り返し、または継続するブロック | 抑制する前に、送信者の評判、送信量、認証、受信者の履歴を確認する |
実務的なメール運用のベンチマークでは、総バウンス率が約2%を超えると不健全と見なされ、送信者の評判を守るためには、Salesforceのメールベンチマークに関するガイダンスで説明されているように、1%未満がより堅実な定常状態の目標となります。これらの基準値は、原因を切り分けるための有用なシグナルであって、特定のキャンペーンが1つの理由で失敗したことの証明ではありません。
「バウンス」という言葉が混乱を招くのは、Google Analyticsが別の意味で使用しているためです。Universal Analyticsでは、バウンスを、その後の記録されたインタラクションがないセッションとして扱っていました。GA4ではエンゲージメント率を中心にレポートし、イベントによってセッションがエンゲージドと見なされるかどうかが変わる場合があります。メールマーケティングの基礎を確認する必要がある場合は、まずメール配信における定義とWebサイト分析における定義を分けて考えてください。
BillionVerifyは、1つの問題、つまり不正確なメールデータが企業に損失をもたらすことを解決するために構築された、プロフェッショナルなメール検証サービスです。その役割はこの診断におけるメールデータ側にあり、Webサイトのセッションの解釈にあるのではありません。
技術面および分析面の原因
オーディエンスやクリエイティブが結果を引き起こしたと考える前に、プラットフォームとトラッキング層を確認する必要があります。技術的な不具合によって、実際の配信失敗が発生したり、サーバー応答が誤分類されたり、受信者の行動を変えずに報告指標が水増しされたりすることがあります。
認証と送信インフラ
まず、送信ドメインから確認します。SPFレコードが欠落している、または整合していない場合、DMARCにおけるSPFアライメントに失敗する可能性があります。DKIM署名がないと、別の認証シグナルが失われます。また、ドメインが依然としてp=noneのDMARCポリシーを使用している場合、保護ポリシーを適用せずにレポートだけを収集している可能性があります。これらの状態がすべてのバウンスを自動的に説明するわけではありませんが、信頼性、フィルタリング、そして受信システムによるメールの処理方法に影響を与える可能性があります。
古いESPのレポートでは、SPFのsoftfailがハード失敗として誤表示されることもあります。プラットフォームのラベルを、基盤となるSMTP応答および認証結果と比較してください。ダッシュボードに「ハードバウンス」と表示されていても、受信側の応答が一時的なポリシーまたは認証の問題を示している場合、アドレスを抑制しても根本原因は解決しません。
送信インフラでは、次のような別の失敗要因も発生します。
- 新しいIPのウォームアップ: 送信開始直後に大量のメールを受け取る新しい送信IPは、スロットリングや一時的なブロックを受ける可能性があります。
- 送信量の管理: 突然の急増、短縮された送信時間、繰り返しの再試行は、一時的な問題を悪化させる可能性があります。
- 共有レピュテーション: 共有IPでは、別の送信者による不適切な運用が、受信システムによるトラフィックの評価に影響する可能性があります。
認証レビューの一環としてBillionVerify DKIM checkerを実行し、その結果をESPのドメインアライメントおよび配信ログと比較してください。
ペイロードと測定の不具合
フィルターは、壊れたHTML、プレーンテキスト版の欠落、容量の大きい画像、または最近ブラックリストに登録されたドメインを指すリンクに反応することがあります。主要なクライアントでレンダリングされたメッセージをテストし、リダイレクトを調査し、リンク先のすべてのドメインを確認してください。受信システムごとに異なるポリシーが適用されるため、ある受信トレイで正常に機能するメッセージでも、別の場所では失敗する可能性があります。
分析によって、別の種類の誤検知が生じることもあります。重複したタグが2回発火したり、ビュースルー用のラッパーがリダイレクトを書き換えたり、同意バナーが最初のペイント後にスクリプトを読み込んだりする場合があります。これらのイベントによってセッションエンゲージメントが歪み、ウェブサイトのバウンス率が実際の体験より悪く、または良く見えることがあります。
メールの診断には、生のキャンペーンログを確認してください。ウェブサイトの診断には、タグの発火、同意の動作、リダイレクトチェーン、イベントのタイミングを確認してください。どのメールアドレスを抑制するかの判断に、ウェブ分析レポートを使用しないでください。
コンテンツ、UX、トラフィック品質に起因する原因
正しく認証された送信者でも、訪問者が獲得元から約束された内容を得られなければ、ウェブサイトのバウンス率が高くなることがあります。メールは正常に配信されていても、ランディングページの関連性、速度、レイアウト、または次のステップの不明確さによって、訪問者を失う可能性があります。
セグメントと離脱要因を一致させる
まずは簡単な診断マトリックスから始めます。レポートをチャネル、デバイス、ランディングページ別にセグメント化し、サイト全体の単一の平均値に頼るのではなく、バウンス率の範囲を比較します。
- 検索意図: ブランド名を含まないオーガニック訪問者が特定のランディングページ群で離脱する場合は、検索クエリの表現とページの訴求内容を比較します。不一致があれば、コンテンツまたはターゲティングに問題がある可能性があります。
- ページパフォーマンス: 複数のページでモバイル訪問者の離脱率が大幅に高い場合は、読み込み速度、レイアウトシフト、可読性、タップ領域を確認します。このパターンはUXまたはパフォーマンスの改善が必要であることを示します。
- インタースティシャルとバナー: ポップアップ、Cookieバナー、または全画面プロンプトの表示直後に離脱が集中する場合は、中断要素を取り除いた状態で体験をテストします。
- コンテンツの深さ: 質の高いソースから訪問したユーザーが情報量の少ないページで離脱する場合は、関連性のない文章を追加するのではなく、不足している説明、根拠、ナビゲーション、または次のステップを追加します。
- トラフィックソース: 有料検索、ディスプレイ、またはソーシャルトラフィックの行動がブランドトラフィックと異なる場合は、キーワードの意図、広告クリエイティブ、オーディエンスターゲティング、参照元での期待値を見直します。
1画面だけで完結するページが、必ずしも壊れているとは限りません。特にイベントトラッキングが不完全な場合、訪問者は答えを見つけたか、意図されたアクションを完了した可能性があります。ページが成果を上げていないと判断する前に、バウンス、コンバージョン、スクロール行動、ページ滞在時間、セッション時間を比較してください。
モバイルと獲得状況の確認
モバイルでの行動は、デスクトップのレポートでは見えにくい問題を明らかにすることがよくあります。最初の操作、フォーム項目、ナビゲーション、閉じる操作を含め、一般的なスマートフォンの画面サイズで実際のランディングページをテストしてください。大きなモニターでは問題なく見えるレイアウトでも、テキストが折り返されたり、画像がずれたり、バナーがCTAを覆ったりすると、使いにくくなる可能性があります。
トラフィックの品質は、クリック前に提示された約束にも左右されます。ブランドトラフィックは通常、幅広いブランド名を含まないトラフィックよりも認知度が高く、一方で意図と一致しない有料キーワードは、そのページに適していない訪問者を引き寄せる可能性があります。広告が遷移先で満たされない期待を生み出す場合、ソーシャルやディスプレイの掲載でも同じ不一致が起こります。
ソーシャルでの顧客獲得に取り組むチームには、X for business guide 2026が、プラットフォーム上の活動をビジネス目標に合わせるための有用な背景情報を提供します。その計画に、コンバージョン重視のメールコピーを組み合わせ、メッセージと遷移先が同じ約束を提示するようにしましょう。
「バウンス」が別の意味を持つ場合
割合ではなく、まずレポートの種類から確認しましょう。メールサービスプロバイダーは、送信済みメッセージ、拒否されたメッセージ、配信応答、ハードバウンス、ソフトバウンス、抑制イベントを表示します。分析プラットフォームは、セッション、ページビュー、イベント、エンゲージメント、コンバージョンを表示します。これらのレポートでは、異なる失敗に対して バウンス という言葉を使います。
メールの ハードバウンス は恒久的なものです。アドレスが無効である、ドメインが存在しない、または受信者がブロックされている可能性があります。メールの ソフトバウンス は一時的なものです。メールボックスの容量超過、受信サーバーによるスロットリング、または一時的なサーバーエラーによって配信が中断されることがありますが、アドレスが恒久的に使用不能であることを意味するわけではありません。
メールのバウンス率は、送信中に拒否されたメッセージから算出されます。メール到達率のベンチマークガイダンスで説明されているように、およそ2%のしきい値 に近づく率は、一般的に送信者レピュテーションのリスクとみなされます。このしきい値は、自動的な削除ルールではなく、調査を開始するきっかけとして扱ってください。SMTP応答を確認し、ハード失敗とソフト失敗を分け、さらに送信量を増やす前に、影響を受けたレコードの出所と経過期間を確認しましょう。
分析では、別の定義が使われます。Universal Analyticsでは、バウンスセッションは通常、以降に記録されたインタラクションがない1回のページビューを意味していました。GA4ではエンゲージメントベースのレポートが使われるため、結果は設定されたイベントとセッション条件によって異なります。そのため、完了した単一ページの訪問が、追跡されていないインタラクションと並んで表示されることがありますが、どちらもメールの拒否を示すものではありません。
| バウンスの2つの意味を比較 | 分析上のバウンス | メールのバウンス |
|---|---|---|
| 測定対象 | ウェブサイトのセッション | 送信されたメールメッセージ |
| 主なシグナル | 以降に記録されたインタラクションまたはエンゲージメントがない | 受信者サーバーによる拒否 |
| 典型的な原因 | 意図との不一致、UXの問題、ページの遅さ、追跡不具合、または完了した単一ページ訪問の意図 | 無効なアドレス、一時的なサーバー問題、ポリシーによるブロック、または古いデータ |
| 次に確認すべきこと | チャネル、デバイス、ランディングページ、イベント、セッション行動 | SMTP応答、ハードまたはソフトの分類、ドメイン、リストの出所、認証 |
| 考えられる対策 | 関連性、UX、コンテンツ、または測定方法を改善する | 不正なアドレスを抑制し、リストを検証し、送信条件を修正する |
レポートに受信者アドレスと配信コードが含まれている場合は、リストの品質と送信条件を調査してください。セッションとページパスが含まれている場合は、分析の定義、追跡、訪問者の行動を確認してください。この違いを確認することで、ウェブサイトの測定上の問題をメールリストの失敗として扱ったり、古いリストを分析上の問題として見過ごしたりすることを防げます。
メール検証を使用してメールのバウンスを修正する
検証は、アドレスがキャンペーンキューに入る前に最も大きな効果を発揮します。送信チームはレコードを評価し、処理方針を割り当て、受信者サーバーがメッセージを拒否する前に、受け入れるか、抑制するか、確認するかを選択できます。
収集段階とキャンペーン段階で検証を実施する
フォーム送信時にリアルタイムの検証リクエストを送信し、入力ミス、使い捨て受信トレイ、メールを受信できないアドレスを検出します。明らかなエラーは訪問者に修正を求めるか、レコードが CRM に入らないようにします。不確かな結果は自動ブロックではなく確認に回すべきです。過度に積極的なフィルタリングは、正当な見込み客まで拒否する可能性があるためです。
キャンペーン前に、既存リストの一括検証を実行します。古い CRM エクスポート、イベントからのインポート、購入データ、最近のエンゲージメントが少ないレコードを優先します。B2B アドレスは、収集から送信までの間に古くなる可能性があります。Postmastery ベンチマークレポートでは、健全なオプトインベースの配信率は約 98.5% とされており、収集時にクリーンだったリストでも、使用前に確認が必要な理由がわかります。
メール検証 APIをフォームまたは CRM と送信プラットフォームに接続すると、構造化された結果を返し、自動的な振り分けが可能になります。後続のインポートで監査証跡が消えないよう、連絡先レコードに結果、確認時刻、ソース、処理方針を保存します。

スコアだけでなく結果に基づいて対応する
検証では、アドレスの構文やドメイン設定以外も評価できます。
- 有効: 同意とエンゲージメントのルールに従い、アドレスを配信対象として維持します。
- 無効: 削除または抑制します。メール検証の仕組みで説明されているように、MX レコードまたはフォールバック A レコードがないドメインは、形式が正しく見えてもメールを受信できません。
- ロールベース:
info@、support@、admin@などの共有アドレスを確認します。用途に共有受信トレイが適している場合のみ維持します。 - キャッチオール: 結果を未確認として扱います。キャッチオールサーバーは SMTP 層で任意のアドレス宛てのメールを受信できるため、SMTP 検証ガイダンスによれば、肯定的な応答だけでは個々のメールボックスの存在を証明できません。これらのレコードを別セグメントに分け、関係性がリスクを正当化する場合にのみ送信し、その後の配信状況や苦情のシグナルを監視します。
- 使い捨て: 一時的な受信トレイはブロックまたは抑制します。継続的なコミュニケーションプログラムが受信者に届く前に期限切れになることが多いためです。
- スパムトラップ: レコードを削除し、取得元を調査します。
- 悪用: 苦情のリスクが見かけ上の有効性を上回る可能性があるため、抑制または隔離します。
- 不明: 確認のため保留し、後で再確認するか、別の信頼できるシグナルが配信を支持するまで抑制します。
定期的なインポート、フォーム、送信前チェックにも同じルールを適用します。検証結果をエンゲージメントデータとは分けて保存し、配信結果、苦情、受信トレイへの配置状況と比較します。リストのクリーニングによって、バウンスの原因を1つ取り除けます。改善が続くかどうかは、許可の管理、認証、ソースレベルの確認によって決まります。
優先順位付きの修正計画
重大度に応じて次のアクションを決める必要があります。すべてのバウンス率を同じ問題として扱うと、低い数値では時間を浪費し、高い数値では不要なリスクにさらされます。

2%未満
これは、適切に管理された許可ベースのリストにおけるメンテナンス範囲です。四半期ごとにメール検証を実施し、対象者に合わない場合はロールベースのアドレスを抑制し、獲得元を継続的に監視します。低いバウンス率だけではメッセージが受信トレイに届くとは限らないため、主な進捗指標として受信トレイ配置率を追跡してください。
技術的な修正は数日以内に変化として現れることがあります。変更が通常のキャンペーン全体で継続していることを確認する間、送信プログラムは安定させておきましょう。
2%~5%
これは見た目だけのレポート上の問題ではなく、調査が必要な警告として扱ってください。リスト全体を検証し、獲得元別に結果をセグメント化し、ハードバウンスとソフトバウンスの分類を確認します。指標がウェブサイトのダッシュボードから取得されている場合は、重複タグやトラッキングエラーがないか分析データを監査してください。
技術的な修正がレポートに反映されるまで、数日かかることがあります。評判が損なわれている場合、回復には数週間かかる可能性があります。メールでは受信トレイ配置率を使用し、バウンス率だけで成功を判断しないでください。
5%超
影響を受けた対象者への追加送信を一時停止してください。IPとドメインの評判を調査し、ポストマスターの応答を確認し、アドレスの提供につながったリストの取得元を特定します。次回のキャンペーン前に、APIを通じてリアルタイムで検証してください。
ベンチマークの根拠では、5%超を重大とみなしています。また、リストの衛生状態が悪いと、バウンス率は文書化されているメールバウンス率のベンチマーク分析のとおり、5%~10%以上の範囲に達する可能性があります。技術的な修復には数日かかることがありますが、評判の修復には数週間かかる可能性があるため、送信量を増やして無理に回復させようとしないでください。
四半期ごとのチェックリストを使用してください。
- リストの健全性: 新しいインポートデータと古いレコードを検証する。
- 獲得品質: 取得元ごとにバウンスと苦情のシグナルを比較する。
- 認証: SPFのアラインメント、DKIM署名、DMARCレポートを確認する。
- インフラストラクチャ: 送信量の変化、スロットリング、共有IPの状態を確認する。
- 測定: メール拒否データとウェブサイトのセッションデータが分離されたままであることを確認する。
すべての変更に担当者、明確なセグメント、回復を確認できる指標が設定されていれば、バウンス率は管理可能になります。
BillionVerifyは、リストクリーニングやリアルタイム検証のワークフローを含め、キャンペーンのメール到達率に悪影響を及ぼす前に不正なアドレスを特定するためのメール検証を提供しています。BillionVerifyにアクセスして、検証サービスをフォーム、CRMの衛生管理プロセス、送信前チェックにどのように組み込めるかをご確認ください。
