deliverability-incident-response

配信到達性インシデント対応

問題は起こります。そんなときに必要なのは、慌てることではなく、対応手順です。このスキルはトリアージの判断ツリーです。

5 種類のインシデント

症状	最も可能性の高い原因	最初の対応	修正にかかる時間
返信率が急激に低下した	配信到達性 — メールが迷惑メールに振り分けられている	迷惑メール振り分けテストを実行する	1～14 日
バウンス率が 3% を超えて急上昇した	リスト不良、またはドメインのレピュテーション	バウンスの種類を確認する	1～3 日
ドメインがブラックリストに登録された	共有 IP の悪質な利用者、または自分のドメインがフラグ付けされた	ブラックリストを確認し、必要なら切り替える	7～30 日
ウォームアップ中に受信トレイがブロックされた	ウォームアップネットワークが送信パターンを検知した	一時停止して調査し、必要なら置き換える	1～7 日
Gmail でプロモーションとして分類される	コンテンツが原因（リンク、画像、HTML）	コンテンツを簡素化する	1～3 日

判断ツリー：「返信率が低下した」

ステップ 1：低下幅を定量化する

Was this week's reply rate < 50% of last 4 weeks' average?
  Yes → real drop, continue triage
  No  → noise, wait another week

低下が実際に確認できた場合：

ステップ 2：特定のキャンペーンだけか、全体かを確認する

Are ALL campaigns dropping, or just one?
  All → fleet-level issue (infrastructure or copy pattern)
  One → campaign-specific (targeting, copy, list)

ステップ 3：全体的に低下している場合 — 次の項目を順に確認する

1. Smartlead Smart Delivery の迷惑メールテスト（/email-deliverability-audit → run-spam-test.ts）

   • 受信トレイへの配置率が 70% 未満の場合 → 配信到達性に実際の問題があります。ステップ 4 に進んでください
   • 受信トレイへの配置率が 85% を超える場合 → 配信到達性に問題はありません。代わりに文面やターゲティングを確認してください

2. ドメイン認証を確認する（/email-deliverability-audit → check-domain-auth.ts）

   • いずれかのドメインで DKIM が設定されていない場合 → すぐに修正してください（再接続の手順は /zapmail-domain-setup-public を参照）
   • DMARC ポリシーが reject で、アライメントに失敗している場合 → 一時的に quarantine に引き下げてください

3. ウォームアップの状態を確認する（/smartlead-inbox-manager → list-health.ts）

   • 複数の受信トレイがウォームアップ中にブロックされている場合 → ウォームアップネットワークにフラグ付けされています
   • 多数の受信トレイでレピュテーションが「good」から「fair」に低下した場合 → 送信量を減らしてください

4. バウンス率を確認する（/email-deliverability-audit → audit-performance.ts）

   • バウンス率が 3% を超える場合 → リストの品質が低下しています
   • バウンス率が 1% 未満で返信率が低い場合 → メールが迷惑メールに振り分けられています（ステップ 1 の結果）

ステップ 4：迷惑メールへの振り分けに問題がある場合 — 対応方法

時系列順の対応：

1. 直ちに（今日）： 送信量が最も多いキャンペーンを一時停止します。被害の拡大を防ぎます。
2. 1 日目： 送信者を 2～3 個のグループ（tag=active と tag=new）に分けて、迷惑メールへの振り分けテストを実行します。最も状態の悪いグループを特定します。
3. 1 日目： Smart Delivery の spam-filter-details レポートを確認します。特に、どのフィルターが作動しているかを確認してください。よくあるものは DKIM_INVALID、HTML_MESSAGE、LINK_REDIRECT です。それぞれに固有の修正方法があります。
4. 2 日目： 特定した問題を修正します。
   • DKIM_INVALID → すべてのドメインで DKIM レコードを確認し、必要に応じて再公開します
   • HTML_MESSAGE → メール本文を簡素化します（フォントを減らし、インライン CSS とトラッキングピクセルを使わない）
   • LINK_REDIRECT → 1 通目のメール内のリンクを削除または減らします（できればリンクは 0 個にします）
5. 3～14 日目： 送信量を減らします。1 週間、受信トレイごとの 1 日あたりの送信数を 50% 減らします。レピュテーションの回復には時間がかかります。
6. 14 日目： 迷惑メールへの振り分けを再テストします。85% を超えるまで回復していれば、通常の送信量に戻します。

判断ツリー：「バウンス率が急上昇した」

ステップ 0：判定に十分な数のバウンスがありますか？

バウンス「率」が意味を持つには、50 件の送信が必要です。それより少ない場合、無効なアドレスが 1 件あるだけで 2%、2 件なら 4% となり、3% のしきい値を簡単に超えてしまいます。バウンスの「内訳」が意味を持つには、特定の送信ドメインに紐付く分類済みバウンスが30 件必要です。サンプルがないドメインは、構造上、送信者に起因する割合が 0% になります。これはリストが劣化しているように見えます。その結果、測定されていないドメインに対して、自信満々に「リストを再検証してください」と判断してしまうのです。

ステップ 1：バウンスをハード／ソフトではなく、SMTP コードで分類します

ハードバウンスかソフトバウンスかだけでは、対処するには大まかすぎます。バウンス通知の DSN に含まれる拡張 SMTP ステータスコードから、原因がどちらにあるかが分かります。バウンスしたリードのメッセージ履歴から DSN を取得し、本文にある [45].\d+.\d+ の最初のコードを使います。DSN テンプレートではコードが繰り返し記載され、後半の「管理者向け詳細」定型文で無関係な例が引用されていることもよくあります。

区分	コード	意味	対応
LIST	5.1.1、5.1.10、5.1.0、5.2.1、5.4.1、5.5.0	メールボックスが存在しません。	リストを再検証します。有効性が確認できたものだけを残します。キャッチオールの結果は合格ではなく、見つからないことを意味します。
SENDER（認証）	5.7.1、5.7.0、5.7.23、5.7.26、5.7.509、5.7.520	ポリシーまたは認証上の理由で拒否されました。	まず SPF／DKIM／DMARC を修正し、7 日後に再確認します。修正可能です。ドメインを置き換えないでください。
BURNED	5.7.606～5.7.614、またはブロックリスト／Spamhaus を示す DSN テキスト	受信側でこの送信者が明確にブロックされています。	/inbox-lifecycle-manager でキャンセル候補にします。DNS の修正では解決しません。
THROTTLE	任意の 4.x.x — 4.7.x、4.4.2、4.4.7、4.2.2	一時的な問題です。グレイリスティングまたはレート制限です。	1 週間、受信トレイごとの 1 日あたりの送信量を 50％減らします。4.x コードを理由にドメインをキャンセルしないでください。
NOISE	5.2.2（メールボックスがいっぱい）、5.3.4（サイズ超過）、5.7.133（制限付き配布グループ）	受信者側の設定によるものです。レピュテーションを示すものではありません。	分母を正確にするため件数には含め、その後、すべての割合計算から除外します。

⛔ 5.7.133 は完全にノイズです。 「このグループは組織内からのメッセージのみを受け付ける」という意味で、他者の配布リスト設定によるものです。実際のサンプルでは最も多いコードになることも多く、送信者側の問題として分類すると、何も問題がないのに「ドメインが使用不能」というキャンセル候補が生まれてしまいます。

次に、クライアントごとではなく、送信ドメインごとに計算します。クライアント単位で分けても、どのドメインに対処すべきかは分かりません。

sender_share = SENDER / (SENDER + LIST + BURNED)      # noise and throttle excluded
burned_share = BURNED / (SENDER + LIST + BURNED)

burned_share > 20%  (≥30 classified bounces)
  → BURNED, at any bounce rate. Evaluate this FIRST, before the rate gate — a domain
    that is majority-blocklisted at a 2.5% bounce rate is still burned.

bounce_rate > 3% AND sender_share < 25%
  → list quality problem. Revalidate.

bounce_rate > 3% AND sender_share 25-50%
  → both diseases at once. Fix the auth gap FIRST, then revalidate. Do not go chase
    the list when 40% of the failures are yours.

bounce_rate > 3% AND sender_share > 50% AND auth incomplete
  → SENDER_AUTH. Fixable. Fix the record, re-check in 7 days.

bounce_rate > 3% AND sender_share > 50% AND auth clean
  → BURNED. Configuration is clean and we are still refused.

bounce_rate > 5% either way
  → stop the campaign immediately to prevent ISP suspension, then classify.

rising 4.x share, low permanent bounce
  → throttle. Cut volume. Do not cancel.

ステップ 1b：サンプリング — すべてのバウンスを列挙しないでください

バウンスした行からは、どのドメインが送信したか分かりません。ドメインの特定には、メッセージ履歴の取得が必要です。そのため、事前にドメインごとに層化抽出することはできません。全体の予算を決め、後から最低件数を適用します。期間内の対象リスト全体から均等にサンプリングし（roster[::step] を使います。時間的な偏りが生じる offset=0 のみの使用は避けてください）、判定が必要なドメイン数 × 1.5 × 30 件程度を予算とします。最終的に、特定ドメインに紐づくバウンスが 30 件未満なら、判定せずに サンプル不足 とします。

⚠️ バウンスしたリードの一覧には、通常、日付パラメーターがなく、キャンペーンの全履歴が返されます。送信日でクライアント側のフィルタリングを行ってください。そうしないと、6 か月前に終了したキャンペーンのバウンスが、今週の判断に影響します。

⚠️ メッセージ履歴の取得は一時的に失敗することがあります。「DSN なし」と記録する前に、バックオフを入れて 3 回以上再試行してください。実際の実行では、一見本文がなかった 64 件中 61 件について、再試行時に本文を取得できました。

ステップ 2：リストに問題がある場合

1. キャンペーンから残りのリードをエクスポートします
2. MillionVerifier で一括処理します（1,000 件あたり約 2 ドル）
3. ステータスが「ok」のメールアドレスだけを再利用します
4. 残りは破棄します

ステップ 3：レピュテーションに問題がある場合

送信速度を大幅に落とします。2 週間、受信トレイごとの 1 日あたりの送信量を 50％減らします。ウォームアップをより積極的に行います。

判断フロー：「ドメインがブラックリストに登録されている」

ステップ 1：ブラックリストを確認する

確認先：

• Spamhaus、Barracuda、SURBL は /email-deliverability-audit → スパムテストレポート → ブラックリストの詳細
• セカンドオピニオンとして MX Toolbox（https://mxtoolbox.com/blacklists.aspx）

ステップ 2：ブラックリストのレベルは？

• ドメインが Spamhaus DBL または SURBL に登録されている → 深刻です。ドメイン全体を置き換える必要があるかもしれません。
• 送信 IP が DNSBL に登録されている → 通常は IP プール側の問題です（Zapmail の共有 IP を使っている場合、あなた側の問題ではありません）。Zapmail は IP をローテーションするため、1～2 週間待ちます。
• 小規模なリスト（例：Barracuda） → 該当ポータルから登録解除を申請します。通常、3～7 日で解決します。

ステップ 3：交換するか、修復するか

• ドメインの運用開始から30日未満で、ブラックリストに登録されている場合 → 交換します。修復にかける手間に見合いません。（30日未満のドメインを交換するのはこのケースのみです。返信率による判定ではなく、ブラックリスト登録が確認された場合です。運用開始から間もないドメインをパフォーマンスを理由に停止することはありません。/inbox-lifecycle-manager を参照してください。）
• ドメインの運用開始から90日を超えていて、ブラックリストに登録されている場合 → 修復を試みます。7日間送信を停止し、登録解除を申請してから、徐々に再開します。
• 交換する場合： 古いドメインをアーカイブし、/zapmail-domain-setup-public で似たドメインを新しく購入して、再利用する前に2週間ウォームアップします。

判断フロー：「ウォームアップ中に受信トレイがブロックされた」

ステップ 1：ブロックされた理由は何ですか？

Smartlead の is_warmup_blocked: true フラグは、通常、次のいずれかを意味します。

• ウォームアップメールがウォームアップネットワークでスパムと判定された
• ウォームアップネットワーク内の相手の多くが、メールをスパムとしてマークした
• 受信トレイの種類またはプロバイダーによって、送信レートが制限されている

ステップ 2：原因を切り分ける

1. blocked_reason フィールドを確認します（値が入力されている場合）
2. ウォームアップネットワークの問題の場合 → 受信トレイの評判が損なわれている可能性があります。費用対効果を考慮してください。
   • 運用開始から間もない受信トレイ（30日未満） → 使用を終了し、新しい受信トレイを用意します
   • 運用期間の長い受信トレイ（90日超、以前は評判良好） → ウォームアップを無効にしてから再度有効にし、total_warmup_per_day を下げて試します（40ではなく15を試してください）
3. ISP によるレート制限の場合 → 48時間待ってから、ウォームアップを再度有効にします

ステップ 3：使用終了のワークフロー（/smartlead-inbox-manager 経由）

# Tag as retired
npx tsx scripts/tag-inboxes.ts --ids=<id> --add-tag=retired --remove-tag=active

# Disable warmup
npx tsx scripts/set-warmup.ts --mode=disable --ids=<id>

# Replace — buy new domain, create new inbox
# See /zapmail-domain-setup-public

判断フロー：「Gmail でプロモーションに分類される」

ステップ 1：新しい Gmail アカウントでテストする

キャンペーンのメール1通目を、キャンペーンに含まれていない新しい @gmail.com アカウント（自分のアカウントなど）に送信します。どこに届きますか？

• メイン → 問題ありません
• プロモーション → これが問題です
• 迷惑メール → 配信可能性に、より大きな問題があります（上記を参照）

ステップ 2：プロモーションタブへの振り分け要因（および対処方法）

• メール内のリンクが複数 → メール1通目のリンクを0～1個に減らします
• 画像／インライン画像 → 削除します
• HTML の装飾が多い → シンプルにし、タグを減らします
• マーケティング風の表現（「ここをクリック」「今すぐ実行」「期間限定」など） → 削除します
• ヘッダーの配信停止情報（List-Unsubscribe）— 配信可能性の向上には役立ちますが、正しくフォーマットする必要があります
• ロゴ入りの大きな署名ブロック → テキストのみのシンプルな形式にします

ステップ 3：A/B テスト

現在のバージョンと、簡素化したバージョンの2種類を作成します。それぞれ50件のリードに送信し、7日後にどちらの返信率が高いかを確認します。

72時間で「全面的に失敗」した場合のチェックリスト

何も機能せず、原因もわからない場合：

1. すべてのキャンペーンを一時停止します。 これ以上の悪化を防ぎます。
2. 監査： /email-deliverability-audit の全項目を実行します
3. スパムテスト： Smart Delivery を送信者のサブセット2つに対して実行します
4. すべてのドメインで SPF／DKIM／DMARC を確認します — 1つでも設定されていない場合は、再開する前に修正します
5. Zapmail の稼働状況ダッシュボードを確認します — Zapmail の IP に問題があれば、同じプールを使うすべてのユーザーにも影響します
6. 再開後の送信量を75%減らします
7. 実績のあるメール文面を使います — 復旧中に新しい文面で配信を開始しないでください
8. 再開後7日間、返信率を毎日確認します

専門家に相談するタイミング

• 修正を行っても2週間を超えて迷惑メールに振り分けられる → インフラレベルの問題です。送信プラットフォームの移行を検討してください
• 複数のドメインが永久にブラックリスト登録されている → IP プールの問題です。プロバイダーを切り替えてください
• 4週間経ってもドメインの評判が回復しない → ドメインの使用を終了し、交換します

次に行うこと

7日後に /email-deliverability-audit --days=7 を再実行し、回復を確認します。 ドメインや受信トレイの評判はゆっくり回復するため、7日間の期間が経過する前に再監査しないでください。

その間は、/cold-email-weekly-rhythm を使って毎週の運用を続け、新たな問題の発生を早期に検知します。

または、待機します： 問題への対応でドメインや受信トレイを交換した場合は、完全な回復を期待する前に、交換したものを2週間ウォームアップしてください。

関連スキル

• /email-deliverability-audit — 最初に実行する診断一式
• /inbox-lifecycle-manager — 「このドメインは使用できない」という判定後に、停止／交換／購入を判断します
• /smartlead-inbox-manager — 受信トレイへのタグ付け、ローテーション、使用終了を行います
• /zapmail-domain-setup-public — 使用できなくなったドメインを交換します
• /positive-reply-scoring — 回復を確認します（返信率が基準値に戻っているか）

1％ルールの健全性チェック

修正後は、修正が機能したかを判断する前に、通常の送信量で少なくとも200通送信してください。200通未満では、返信率だけではドメインに問題があるのか、単に運の悪い週だったのかを見分けられません。

• 返信率が1％を超える状態に回復 — 回復しています。通常のペースに戻してください。
• 200通以上送信しても1％未満 — 修正は効果がありませんでした。プレイブックを最初からやり直すか、ドメインが使い物にならないと判断し、/inbox-lifecycle-manager に引き継いで置き換えてください。（ただし、30日未満のドメインのキャンセルは引き続き拒否されます。新しいことと使い物にならないことは別です。）

時間をかけてください。レピュテーションの回復には時間がかかります。2日後に再監査しても、何も分かりません。