Soft bounce

ソフトバウンスは一時的なメール配信失敗です。受信側メールサーバーは現時点ではメッセージを拒否していますが、原因は時間で解消する可能性のあるもの — 受信者のメールボックスが上限を超えている、受信側サーバーが一時的にダウンまたはレート制限中、初回試行で greylisted された、TLS ハンドシェイクの一時的な不具合、などです。送信者にはリトライが期待されます。対する ハードバウンスは永続的な拒否であり、決してリトライすべきではありません。

ハードバウンス処理を駆動する同じ BounceType enum には、もう 1 つの case があります:

enum BounceType: string
{
    case HARD = 'hard';
    case SOFT = 'soft';
}

送信ベンダー（SES、Mailgun、SparkPost など）からの SOFT webhook イベントはハードバウンスとまったく同じように BounceLog に記録されますが、RecordBounce リスナは 1 回の発生では購読者を自動的に拒否リストに登録しません。アドレスはアクティブのまま残り、後続のキャンペーンにも含まれます。ソフトバウンスが設定可能なストリーク数を超えて累積し続けた場合、運用者は bounce-handler のポリシー経由でアドレスを拒否リストに昇格できます — 1 回限りのソフトバウンスはノイズとして扱われます。

ソフトとハードのバウンスを混同するのは、小規模プラットフォームで最も多いバウンス処理の誤りです。ソフトバウンスで自動拒否リスト登録すると、受信者のサーバーに一時的な不具合があるたびにリストが縮みます — Gmail の一度の障害だけで数千人の正当な購読者を失う可能性があります。逆にハードバウンスをソフトのように扱う（とにかくリトライする）と送信者レピュテーションを焼き切ります。AcelleMail はデータモデル層（BounceType::HARD vs BounceType::SOFT）でこの区別を強制し、リスナが誤って一方をもう一方として扱えないようにしています。

• 4xx SMTP レスポンス — 4xx クラス全体が「一時的失敗、リトライ可」を意味します。
• メールボックス満杯 — 受信者がストレージ上限に達した状態。通常は数日で解消します。
• Greylisting — 初回送信者を遅延させる anti-spam 技術。正当なリトライは数分で成功します。
• レート制限 — 受信者がこの IP / ドメインからのトラフィックをスロットリング中。バックオフしてリトライしてください。
• TLS / 接続の問題 — 受信側の一時的なネットワークまたは証明書の問題。

ソフトバウンスを拒否リスト昇格させるべき閾値、妥当なストリーク長、ベンダーの生の理由文字列の読み方を含む完全な運用プレイブックは 到達率 §8にあります。