ソフトバウンスとハードバウンス：原因、コード、および修正方法

多くのメールに関するアドバイスでは、ソフトバウンスは無害であるとされています。なぜなら、受信側のサーバーが後でメッセージを受け入れる可能性があるからです。しかし、これは失敗が単発的であり、再送ポリシーが適切に管理されている場合にのみ当てはまります。ソフトバウンスが繰り返される場合は、メールボックスプロバイダーによるスロットリング（帯域制限）、送信者の評価に関する問題、あるいは事実上メールの受け入れを停止している受信アドレスを示唆している可能性があります。

ハードバウンスはより明確です。アドレス、ドメイン、または受信システムが恒久的な失敗を返しているため、再送を繰り返すことは送信リソースの無駄であり、回避可能なリスト品質の低下を招きます。ソフトバウンスとハードバウンスの実際の違いは、単に一時的か恒久的かという点だけではありません。いつ再送が合理的であり、いつシーケンスを一時停止すべきか、そしていつその行を抑制（除外）すべきかを判断することにあります。

なぜソフトバウンスは見かけほど無害ではないのか

ソフトバウンスは一時的な配信失敗ですが、「一時的」という言葉はサーバーの応答を指すものであり、ビジネス上のリスクを指すものではありません。メールボックスの容量不足、サーバーのダウンタイム、グレイリスティング、またはレート制限などは、後で解消される可能性があります。しかし、キャンペーン全体で同じ応答が繰り返される場合は、受信者や送信パターンが未解決のままであることを示しています。Supedによる持続的なバウンス管理に関するガイダンスでは、一時的な失敗が繰り返された場合、無期限に再送するのではなく、一時停止または抑制する運用上の必要性が強調されています。

この区別はSDR（営業担当者）にとって重要です。一度ソフトバウンスした見込み客には再送する価値があるかもしれません。しかし、毎回ソフトバウンスする見込み客は、コードが4xxで始まるという理由だけで自動シーケンスに留めておくべきではありません。メールボックスが満杯である可能性もありますが、メールボックスプロバイダーが送信者の評価や送信行動を好ましく思っていないために、一時的なポリシーによる拒否を受けている可能性もあります。

繰り返される失敗を診断データとして扱う

一度のバウンスは「その試行ではメッセージが配信されなかった」という一つの答えを提示します。しかし、パターンは「なぜこの受信者やドメインが配信を拒否し続けるのか」という、より有益な答えを提示します。

以下のようなパターンに注目してください。

• 一人の受信者で失敗が繰り返される： メールボックスが満杯、放置されている、または継続的に利用できない可能性があります。
• 一つのドメインで多くの受信者が失敗する： 受信側のプロバイダーがトラフィックを制限しているか、一時的なポリシーブロックを適用している可能性があります。
• 送信量変更後のバウンス： 送信行動がレート制限をトリガーした可能性があります。
• メッセージ変更に関連する失敗： サイズ、コンテンツ、または認証の問題が関与している可能性があります。

メールボックスプロバイダーは、持続的なバウンス活動を送信者の品質に関する証拠として扱うことがあります。最近の到達率に関するガイダンスでは、より厳格なコンプライアンスの施行が指摘されており、ソフトバウンスが単なる受信側の問題ではなく、評価に関する警告、ブロックリスト入り、または認証関連の拒否を反映している可能性があることも示唆されています。有益な対応は「永遠に再送する」ことではありません。理由を特定し、再送のタイミングを制御し、連絡先ごとに結果を記録することです。

実用的なルール： ソフトバウンスは再送の機会を得る。繰り返されるソフトバウンスは調査の対象となる。

中小企業では、キャンペーンの集計レポートが個々の行を隠してしまうため、これを見落とすことがよくあります。全体的なバウンス率が控えめであっても、特定のドメインでの失敗の集中や、再送されすぎている少数の連絡先が隠れている可能性があります。各バウンスを診断イベントとして扱うことで、クリーンアップがより正確になり、有効なアドレスを不必要な抑制から保護できます。

SMTPバウンスコードとサーバー応答の理解

SMTPステータスコードのファミリーは、ソフトバウンスとハードバウンスを区別するための技術的な基礎を提供します。標準では、4xx応答を一時的な失敗（後の試行で成功する可能性がある）、5xx応答を恒久的な失敗（同じアドレスへの再送は一般的に不適切）と定義しています。このフレームワークにより、ソフトバウンスとハードバウンスのセマンティクスに関するリファレンスに記載されているように、バウンス処理は主観的なものではなく運用可能なものとなります。

4xxは遅延を意味し、成功ではない

一般的なソフトバウンスの例には、421、450、451、452があります。正確な文言はサーバーによって異なりますが、実用的な解釈は一貫しています。

• 421： サービスが利用できないか、一時的に接続を閉じている。
• 450： 要求されたメールボックスまたはアクションが現在利用できない。
• 451： 一時的な処理エラーまたはローカルサーバーエラーが発生した。
• 452： サーバーにその時点で要求を完了するための十分なリソースがない。

これらのコードは、送信者に対して別の試行を許可するように伝えています。メールボックスの満杯、一時的なサーバー停止、グレイリスティング、レート制限などはすべて一時的な失敗を引き起こす可能性があります。コードだけでは受信者が回復するかどうかは判断できないため、詳細な診断テキストと各試行の時間を記録してください。

5xxはアドレスの抑制または恒久的なブロックの解決を意味する

一般的なハードバウンスの例には、550、551、553、554があります。これらは、受信システムが配信失敗を恒久的なものと見なしているか、通常の再送では対処すべきではない方法でメッセージを拒否したことを示します。

• 550： 配信が拒否された。多くの場合、メールボックスが利用できないか、要求が拒否されている。
• 551： 宛先のメールボックスがローカルではないか、その宛先で利用できない。
• 553： アドレスまたはメールボックスの構文が無効であるか、受信者が受け入れられない。
• 554： トランザクションが恒久的な失敗として拒否された。

ハードバウンスは、存在しないメールボックス、無効なドメイン、または明示的なサーバー拒否によって発生する可能性があります。確認済みの修正がない限り、直ちにアドレスを抑制してください。バウンス通知がワークフローにどのように適合するかについての平易な説明については、バウンスバックメッセージに関するガイドを参照してください。

ソフトバウンスとハードバウンスの比較

コードファミリーが出発点となりますが、運用担当者には意思決定のフレームワークが必要です。ソフトバウンスは配信経路を可能な状態に保ちますが、ハードバウンスは同じアドレスへの送信を続けることが逆効果であることを伝えています。以下の表は、技術的なシグナルとチームが取るべきアクションを分類したものです。

ソフトバウンスとハードバウンスの概要

属性	ソフトバウンス	ハードバウンス
配信ステータス	一時的な失敗	恒久的な失敗
SMTPファミリー	4xx（421, 450, 451, 452など）	5xx（550, 551, 553, 554など）
一般的な原因	メールボックス満杯、サーバー停止、グレイリスティング、レート制限、一時的なポリシー拒否	無効なメールボックス、存在しないドメイン、無効なアドレス、恒久的な拒否
再送動作	制御された期間内で再送	同じ無効なアドレスには再送しない
リストのアクション	監視、再送、持続する場合は一時停止または抑制	直ちに抑制
診断上の意味	受信者やプロバイダーが回復する可能性がある、または送信者に関連する問題の兆候	宛先が現在実行可能な配信ターゲットではない
評価への懸念	繰り返される失敗はスロットリングや受信者の品質低下を示唆	継続的な試行はリスト管理の不備を示す

ソフトバウンスには判断が必要です。一時的なサーバーの問題には再送する価値がありますが、繰り返されるポリシー拒否には送信速度の低下とインフラの再検討が必要です。システムが「失敗」としか記録しない場合、その区別をつけるために必要な理由が失われます。応答コード、診断メッセージ、受信者ドメイン、キャンペーン、および試行履歴を保持してください。

ハードバウンスには解釈の余地がほとんどありません。アドレスの入力ミスがないことを確認し、抑制してください。恒久的に無効なアドレスを後のキャンペーンに含め続けると、予測可能な失敗が発生し、現在のリストの健全性が損なわれます。Nylasのバウンスコードリファレンスは、一時的な4.x.x応答と恒久的な5.x.x応答の根本的な違いを提供しています。

グレイリスティングは重要な例外です。受信サーバーが不慣れな送信者を一時的に拒否することがあるため、後の再送で成功する場合でも、最初の応答は警告のように見えることがあります。一時的なポリシーブロックはメールボックスの満杯とは異なりますが、どちらもソフトバウンスのカテゴリに表示される可能性があります。そのため、ラベル単体よりも応答の詳細と再送履歴が重要になります。

メールマージワークフローにおけるバウンスシグナルの読み取り

集計されたバウンス率は、キャンペーンに問題があったかどうかを教えてくれます。行ごとのステータス追跡は、どの連絡先やドメインが原因であるかを教えてくれます。 Google Sheetsを使用して作業する小規模なチームにとって、その違いは曖昧な到達率の懸念をクリーンアップのキューに変えるものです。

Mail Merge for Gmailは、送信済み、開封済み、クリック済み、返信済みといった配信およびエンゲージメントの状態をスプレッドシートに書き戻します。そのキャンペーンレポートワークフローはバウンスされたメール記録も表示するため、キャンペーンを一つの区別できない結果として扱うのではなく、個々の連絡先を調査することができます。

行レベルの診断ビューを構築する

受信者アドレス、ドメイン、キャンペーン日、バウンスカテゴリ、SMTPコード、理由テキスト、試行回数、および次のアクションのための列を追加または確保してください。複雑なデータベースは必要ありません。一貫したスプレッドシートの記録があれば、同じ連絡先がレビューなしで別のシーケンスに入るのを防ぐのに十分です。

まずは失敗そのものから始めます。ハードバウンスとしてマークされた行は、アドレスが正しく入力されていないことを確認した後、抑制リストに移動する必要があります。ソフトバウンスとしてマークされた行は、理由が一時的であると見なされ、再送回数がポリシーの範囲内である場合にのみ、対象として維持されるべきです。

次に、ドメインごとに行を比較します。同じプロバイダーの複数の連絡先が1つのキャンペーン中にソフトバウンスする場合、すべてのメールボックスが満杯であると想定しないでください。送信ペース、認証、またはキャンペーンパターンがプロバイダーレベルの拒否を引き起こしていないか確認してください。1つの連絡先だけが失敗を繰り返す場合は、まずその受信者の記録を調査してください。

ステータスを使用してフォローアップを制御する

シンプルなワークフローでアクションを割り当てることができます。

• 再送： 行には単一の一時的な応答があり、繰り返される問題の証拠がない。
• 保留： 同じ受信者またはドメインでソフトバウンスが繰り返されており、レビューが必要。
• 抑制： サーバーが恒久的な失敗を返したか、一時的な失敗が文書化された上限を超えた。
• リリース： 後の試行で成功したため、行は通常のキャンペーン対象に戻る。

重要な詳細は履歴のコンテキストです。タイムスタンプのない「ソフトバウンス」ラベルでは、一度限りのサーバー停止と、繰り返し失敗している連絡先を区別できません。以前のキャンペーン結果を表示または別のログにリンクさせ、送信のたびにシートをフィルタリングしてください。

バウンスパターンが送信者の評価に与える影響

メールボックスプロバイダーは、個々のメッセージの成功以上のものを評価します。彼らはハードバウンス活動をリスト品質のシグナルとして、また持続的なソフトバウンス活動をスロットリング、ポリシーの摩擦、または送信者に関連する評価トラブルの証拠として解釈する可能性があります。その結果、受け入れの遅延、受信トレイへの配置率の低下、またはより広範なフィルタリングが発生する可能性があります。

業界のベンチマークは、チームが小さな数字を軽視すべきではない理由を示しています。検証済みのメールバウンス率ベンチマークによると、数十億通のメールに基づくあるベンチマークでは、業界全体の平均ハードバウンス率が0.21%、平均**ソフトバウンス率が0.70%**であると報告されています。別のエンタープライズマーケティング分析ソースでは、ハードバウンス率2%、**全体的なバウンス率5%**と報告されており、リストの品質とキャンペーンのコンテキストがいかに大きく異なる結果を生むかを示しています。

合計だけでなく構成を読み取る

2つのキャンペーンは、全体的なバウンス率が同じであっても、正反対の対応を必要とする場合があります。一方は、後で解消される一時的な拒否がほとんどである可能性があります。もう一方は、古い見込み客データによる恒久的な失敗が含まれている可能性があります。合計数だけでは、どのアドレスを削除すべきか、送信インフラに注意が必要かどうかは分かりません。

少なくとも以下の側面を追跡してください。

• ハードとソフトの混合： 恒久的な失敗は直ちに抑制が必要であり、一時的な失敗は制御されたレビューが必要です。
• 理由コードの集中： 繰り返されるメールボックス満杯の応答は受信者の問題を示唆し、ドメイン全体の拒否はプロバイダーや送信者の摩擦を示唆する可能性があります。
• キャンペーンごとの傾向： リストのインポートや送信変更後のバウンス活動の増加は調査に値します。
• ドメイン分布： 特定のプロバイダーでの集中は、集計レポートでは隠れてしまうスロットリングを明らかにすることがあります。

需要創出チームは、アウトリーチの背後にあるインフラも保護する必要があります。エージェンシー向けの需要創出ガイドは、より広範な計画のコンテキストを提供しますが、バウンス処理はキャンペーンワークフロー自体に組み込まれるべき技術的な運用規律です。

ドメインの信頼と送信行動に関するより深い扱いについては、メール送信者の評価に関するリソースを使用してください。中心となるポイントは単純です。ハードバウンス活動が少なければクリーンなリスト管理が維持され、繰り返されるソフトバウンスパターンはプロバイダーが対応をエスカレートさせる前に調査に値するということです。

段階的なバウンス修復プレイブック

バウンスのクリーンアップは、単一の削除アクションではなく、意思決定プロセスとして最も効果的です。サーバーの応答から始め、受信者の履歴と関連付け、チームの誰かが実行できる次のステップを割り当てます。

ステップ1：応答を分類する

4xxの一時的な失敗と5xxの恒久的な失敗を分離します。明らかな入力ミスがないか確認した後、ハードバウンスしたアドレスを抑制します。受信サーバーがすでに恒久的であると識別した結果を待ちながら、将来の送信にそれらを含め続けないでください。

ソフトバウンスについては、理由を記録します。メールボックスが満杯であれば、後の再送が正当化されるかもしれません。グレイリスティングは、受信システムが通常の再送を確認した後に解消される可能性があります。一時的なポリシーブロックやレート制限の場合は、キャンペーンの速度を落とし、別の試行を行う前に送信者の認証と送信行動をレビューする必要があるかもしれません。

ステップ2：制御された再送ウィンドウを適用する

再送は、上限がある場合にのみ有用です。ある文書化されたMailchimpのポリシーでは、非アクティブな連絡先の場合は7回のソフトバウンス、以前に購読者の活動があった連絡先の場合は最大15回のソフトバウンスで、ソフトバウンスの連絡先をハードバウンスのクリーンアップ対象に変換します。これらのしきい値は普遍的な法律ではありませんが、チームが低エンゲージメントの受信者と以前アクティブだった受信者に対して別々のルールを必要とする理由を示しています。

キャンペーンごとの回数だけでなく、受信者ごとの回数を追跡するためにスプレッドシートを使用してください。理由を誰もレビューしていない段階で自動フォローアップが新たな失敗を生成しないように、同じアドレスが繰り返し失敗する場合はシーケンスを一時停止します。

ステップ3：原因別に修復する

• メールボックス満杯： シーケンスを一時停止し、後の再送を検討します。継続的な失敗をアドレスが健全であることの証明として扱わないでください。
• グレイリスティング： 送信システムの再送動作を機能させ、その後の配信が成功するかどうかを確認します。
• 一時的なポリシーブロック： 送信負荷を軽減し、認証と評価のシグナルを検査し、同じキャンペーンを盲目的に繰り返すことを避けます。
• ハード拒否： 確認済みの修正がない限り、直ちにアドレスを抑制します。

ステップ4：キャンペーン記録をクリーンアップする

各キャンペーンの後、ハードバウンス、繰り返されるソフトバウンス、ドメインの集中、および診断詳細が欠落している行をフィルタリングします。保留中のすべての連絡先に担当者を割り当てます。次のアクションがない行は、最終的に誤って再送信されてしまいます。

メールリストのクリーンアップワークフローを使用して、抑制とレビューを緊急タスクではなく日常業務の一部にしてください。

長期的な到達率のためのバウンス管理ポリシーの構築

バウンスポリシーは、キャンペーンを開始する前に4つの質問に答える必要があります。「何が再送され、どのくらいの期間、何回失敗した後にシーケンスが一時停止され、いつ抑制が恒久的なものになるのか」。書面による回答がなければ、チームメンバーの一人がソフトバウンスを無期限に再送する一方で、別のメンバーが最初の失敗で削除してしまう可能性があります。

時間ベースの再送ウィンドウは、ポリシーの施行を容易にします。Brevoは、ソフトバウンスされたメッセージに対して36時間の再送期間を文書化しています。また、ソフトバウンスとハードバウンスの処理ポリシーによると、キャンペーン内で5回連続してソフトバウンスが発生したアドレスをブロックリストに登録しています。そのアプローチは、「一時的」が「無制限」を意味するわけではないという重要な原則を示しています。

ポリシーは、理由コードを保持し、受信者レベルの問題とドメインレベルのパターンを区別する必要があります。恒久的な失敗は直ちに抑制し、持続的な一時的な失敗は一時停止し、プロバイダー全体の拒否は送信量を増やす前にレビューしてください。定期的なリストの衛生管理をスケジュールし、保留中の連絡先を誰がリリースできるかを文書化し、キャンペーン全体で抑制の決定を一貫させてください。

認証も同じ運用計画に含まれます。SPF、DKIM、DMARCは、受信システムがメッセージを承認済みで信頼できるものとして評価するのに役立ちます。これらは無効なアドレスを修復するわけではありませんが、一時的なポリシー関連の拒否を無害なメールボックスの問題として誤分類するのではなく、調査するのに役立ちます。

実用的なポリシーは、複雑化することなく測定可能です。バウンスカテゴリ、応答コード、理由、試行回数、キャンペーン、受信者ドメイン、および最終的な処分を追跡してください。キャンペーンごとにそれらのフィールドをレビューし、カテゴリが繰り返されているという証拠がある場合は、再送および抑制ルールを調整してください。

---

Mail Merge for Gmailを使用すると、Google Sheetsの受信者データを使用してGmailからパーソナライズされたキャンペーンを送信でき、行ごとの配信およびエンゲージメントステータスをシートに書き戻すことができます。Mail Merge for Gmailを使用して、バウンスの結果を個々の連絡先に紐付け、リスクのある行を一時停止し、繰り返される失敗が将来の送信に影響を与える前にアウトリーチワークフローをクリーンアップしてください。