ソフトバウンスとハードバウンスの違い メール配信の分類ルール
要約
メール配信失敗は、SMTPコードの最初の1桁で判定します。4xxは一時的な状態、5xxは永続的な失敗。バウンスレートが2.5%を超えるとISPの動作が変わります。リトライ戦略と抑止ロジックを正しく実装することが、インフラ信頼性を左右します。
ソフトバウンスとハードバウンスの違い メール配信では、結局のところSMTPコードのたった1桁で決まります。4xxコードは「あとで再試行してください」を意味し、5xxコードは「このアドレスはもう存在しません」を意味します。満杯のインボックスに送信すれば4xxが返ってきてスタックが再試行します。存在しないアドレスに送信すればリモートサーバーが5xxを返し、あなたの抑止リストは同じ分に更新されるべきです。この分類を間違えると、ドメイン評価の低下は他のほぼすべての運用ミスよりも高速です。
SMTPコード：分類の唯一の基準
すべてのメール配信失敗は、3桁のSMTPレスポンスコードを報告します。最初の1桁が、バウンス処理ロジックが分岐すべきポイントです。
4xxコードは一時的な状況を示します。受信サーバーが接続を受け入れ、メッセージを評価した後、いま配信できない判断です。5xxコードは永続的な状況を示します。受信サーバーがこのアドレスへのすべての試行をやめるよう指示しています。
この分岐ロジックはインフラレベルの基本です。アプリケーションが人間が読める診断テキストを読んで「抑止するか再試行するか」を決める必要はありません。最初の1桁がその判定をします。
2桁目と3桁目はより詳細です。452はメールボックスが満杯なことを示します。550はアドレスが存在しないことを示します。421はサーバーが一時的に使用不可であることを示します。ほとんどのバウンス分類器は、これらのサブコードを内部イベントタイプにマップしますが、4/5の分岐は基本のままです。すべての4xxを再試行可能として扱い、すべての5xxを最終的として扱うパイプラインなら、本番ケースの約95%を正しくカバーします。
ソフトバウンスの原因と再試行期間
本番メールパイプラインが遭遇する最も一般的な4xxシナリオを、だいたいの発生頻度順に示します。
メールボックス満杯（452）：受信者のクォータが枯渇しています。ほとんどのESPは24～72時間再試行してから硬い失敗に変換します。このコードはコンシューマーインボックスで過剰表現されており、B2B アドレスはそれ単独ではあまり生じません。
グレイリスティング（451）：受信MTAがスパム防止策として不明な送信者を一時的に遅延させます。10～30分後の再試行は通常、成功します。これは新しいドメインやIPでの最初の送信時の正常な部分であり、それ自体がリスト品質の問題を示すわけではありません。
サーバー一時的に利用不可（421）：リモートサーバーがダウン、レート制限中、またはオーバーロードしています。指数バックオフで再試行してください。ほとんどのサーバーは数時間以内に回復します。複数日にわたってこれが同じドメインに続く場合、ドメイン自体が問題かもしれません。
メッセージサイズ超過（552/554ソフト派生）：メールがそのメールボックスのサーバーのサイズ制限を超えています。ペイロードサイズを縮小せずに再試行しても常に失敗します。これを別の処理キューにルーティングして送信者に通知してください。
本番再試行ウィンドウの標準：最初の再試行は5分後、次に30分後、その後2時間、6時間、24時間。5日間正常に配信されなかった後、SMTP慣例は配信不可報告（NDR）を生成し、メッセージを送信者に返します。あなたのESPがその5日間ウィンドウを守っているか、より短くしているかは確認する価値があります。
追跡する価値のあるメトリクス：最初の再試行で解決するソフトバウンスと3回以上の再試行を必要とするソフトバウンスの比率。健全なリストは、452と421コードのほとんどが2回以内の再試行で解決します。複数の再試行サイクルにわたる高い持続は、セグメントレベルで調査する価値のある信号です。
パイプラインが見るハードバウンスの3つのモード
5xxコードは単一ではありません。サブコードは、抑止後に何をすべきかについて異なることを示します。
存在しないアドレス（550/551）：ドメインは有効ですが、ローカル部分が実際のメールボックスにマップしません。これはコンシューマー向けプロダクトの最も一般的なハードバウンスです。サインアップの誤字入力、放棄されたアカウント、6ヶ月前に有効だったが削除されたアドレス。即座に抑止してください。回復経路はありません。
ドメインが存在しないか、メールを受け付けない（550/553/554）：MXレコード検索が失敗した、またはドメインがすべてのインバウンドメールを明確に拒否しています。アドレスだけでなくドメインレベルで抑止してください。そのドメイン上の他のすべての連絡先も同様に到達不可能であり、ドメインレベルクエリで各々がバウンスするのを待つより高速に浮かび上がります。
ポリシーによって永続的にブロック（550/5.7.1）：受信サーバーは、あなたの送信ドメインまたはIPに対するポリシーレベルのブロックを持っています。これはより稀ですが、組織全体の複数のアドレスにわたるクラスに影響を与えるため、運用的により深刻です。IP評価ログと相互参照してから、トリガーするアドレスだけを抑止するか配信品質チームにエスカレートするか決定してください。
プロダクションでバグを起こすニュアンス：いくつかのMTAが、事実上永続的な状況に対して4xxコードを返します。期限切れで駐車されたドメインは、レジストラがMXレコードを緩く破壊している間、550ではなく450を数週間返すかもしれません。あなたのパイプラインは、SMTPプレフィックスに関わらず、2週間にわたって5回連続して試行したアドレスを、ハードバウンスステータスの候補として扱うべきです。
ソフトバウンスが事実上永続的になるとき
本番状況では、4xxと5xxの間のクリーンなカテゴリー境界は保持しません。3つのパターンは、コードが4xx範囲に留まっていても、ハードバウンスと同じ抑止ロジックをトリガーすべきです。
最初：エンゲージメント歴ゼロによる繰り返しメールボックス満杯バウンス。アドレスが開いたことなく、クリックしたことなく、過去30日間に5回452バウンスしたなら、メールボックスはほぼ確実に放棄されています。配信試行を続けると、アクティベーションの現実的なチャンスなしにバウンスレートを増加させます。ハードとして扱ってください。
2番目：解決なしでの永続グレイリスティング。正当な送信者のグレイリストは再試行で解決します。同じアドレスが一貫して48時間を超えて遅延し続けるなら、あなたはブロックリストにあるか、スパムトラップに送信しています。どちらのケースも継続的な試行を正当化しません。再試行サイクルは評価ダメージを複合させます。
3番目：あなたの送信ドメインだけに見える4xxコード。他の送信者が同じアドレスに正常に到達するがあなたの送信が一貫して延期される場合、問題はメールボックス状態ではなく送信者の評価です。より積極的に再試行することでそれを悪化させます。
エンコードする運用ルール：3つのソフトバウンス後に解決なし、アドレスを試験的な抑止状態に移動させます。ライフサイクルメール送信を停止します。確認するまでそれが本当に到達不可能な場合、重要なトランザクションメール（パスワードリセット、請求アラート）に対して適格を保ちます。
抑止ロジック：削除 vs 保留 vs 再試行
すべてのバウンスイベントがコンタクトストアからの完全な削除を保証するわけではありません。正しい呼び出しはバウンスタイプと連絡先の以前のエンゲージメント履歴によって異なります。
5xxハードバウンス（いかなる以前のエンゲージメント） -- 即座に抑止、再試行なし。
4xx、最初の発生（アクティブなエンゲージメント） -- スケジュールあたり再試行、抑止なし。
4xx、3回以上の発生（以前のエンゲージメント歴なし） -- 試験的な抑止。
4xx、5回以上の発生（いかなるエンゲージメント） -- ハードバウンスとして扱う。
4xxメールボックス満杯のみ（高LTVまたはトランザクション） -- 30日間週単位で再試行。
「削除」と「保留」の区別は実践で問題になります。削除されたアドレスはコンタクトストアから完全に削除されます。保留されたアドレスは抑止ステータスで保持されます。それをクエリでき、ヘルスダッシュボードで表示でき、コンタクトが新しいフォーム送信を通じてオプトバックインする場合、再アクティベートできます。高価値トランザクションフローの場合、保留が正しい呼び出しです。コールドアウトリーチリストでは削除がクリーンです。
運用ポイント：コードで施行する価値のある1つのポイント。あなたが実行するアクション（削除または保留）は、SMTPコードとタイムスタンプを抑止理由として記録すべきです。明示的な理由のない抑止イベントは、2つのキャンペーン間でアドレスのコホートが暗くなった理由を理解したいときに後で監査するのがほぼ不可能です。
ISP動作を変えるバウンスレート閾値
業界ベンチマークとして流通している2%総バウンスレート数字は床であり、目標ではありません。実際に重要な閾値はより粒度があります。
GmailとOutlookは、Google Postmaster ToolsとMicrosoft SNDSを通じて送信者レベルのスパムレートを報告します。これらのダッシュボードは直接バウンスレートを公開しませんが、2つの信号は密接に相関します。2%を超える持続的なバウンスレートはほぼ常に、これらのツールで可視のスパム配置レート増加に先行し、典型的には3～5日の遅延を伴います。
送信ドメインあたり監視する実践的な閾値：
0.5%以下：正常範囲。補正アクション不要。
0.5～1.5%：密接に監視。セグメント別のバウンス理由を調査。通常、いくつかのコホートが低下したデータ品質。
1.5～2.5%：キャンペーンを一時停止して再開前に調査。ほとんどのESPはこの範囲で自動レート制限を開始。
2.5%以上：送信を停止。再起動前に影響を受けたセグメントをクリーンアップ。このレベルでは、いくつかのISPが既にメッセージをスパムにフィルタリングしているか、ゲートウェイで接続を遅延させています。
見落とされることの多い運用の詳細：バウンスレートは総リストサイズではなく、試行された配信に対して計算されます。重くセグメント化して、アクティブなサブスクライバーにのみ送信する場合、絶対バウンスカウントは低下しますが、計算されたレートは比例して変わらないかもしれません。送信あたり絶対カウントとレートの両方を追跡してください。絶対カウントのスパイクは、特にリストのインポート後またはリエンゲージメントキャンペーン後に、しばしば早期警告信号です。
配信トレースでバウンスシグナルを読む
バウンスイベントは、開封とクリックと同じ忠実度で配信トレースに出現すべきです。そうでない場合、あなたの可観測性セットアップにギャップがあります。
最小限、各バウンスイベントは記録すべき：タイムスタンプ、SMTPレスポンスコード、リモートサーバーからの完全な診断メッセージ、送信IP、受信ドメイン、およびコンタクトID。受信ドメインは頻繁に省略され、頻繁に必要とされます。ドメインが複数のコンタクト全体で550 5.7.1を返しはじめるとき、全送信ドメイン全体の評価スコアダメージをする前に、ドメインレベルでそのパターンを検出したいです。
そのデータが正しくモデル化されると、3つのビューがほとんどのバウンス監視ニーズをカバーします：送信ドメインあたりの日次バウンスレート、コホートあたりのソフト・ツー・ハード変換レート（今日の4xxイベントが10日後どのくらい依然バウンスしているか）、および組織的な抑止が複合する前にそれをキャッチするドメインレベルのバウンス周波数テーブル。
目標はゼロバウンスレートではありません。成長しているリストでは達成不可能です。目標はバウンス処理パイプラインで最初のSMTPレスポンスで正確に分類し、正しい閾値で抑止し、配信性インシデントにエスカレートする前に体系的な問題を示すシグナルを表示します。