メール到達率インシデント対応ランブック:急激な低下への対処法

メール到達率インシデント対応ランブックとは、配信が突然低下したときにチームが従う、文書化された計画のことです。たとえば、バウンスが急増する、メールがキューに滞留する、苦情が増える、お客様から「メールが届かない」と連絡が来る、といった場面が該当します。手順を事前に決めておくことが重要なのは、被害を抑えられるか、悪化させてしまうかが、多くの場合最初の1時間で決まるためです。本ガイドでは、30分トリアージ、判断表、収集すべき証拠、復旧手順、連絡テンプレート、レビューの形式、ガードレールという、実践的なランブックをご紹介します。

到達率インシデントとは何か

すべての数値の落ち込みがインシデントというわけではありません。通常のトラフィックは、カレンダー、オーディエンス、コンテンツによって変動します。ここでインシデントと呼ぶのは、主要な指標が短時間で通常の範囲を外れ、原因がすぐには分からない場合です。対象となる指標は、バウンス率、遅延の量、苦情率、重要なメッセージの配信時間、主要なメールボックスプロバイダーでの受信トレイ到達率などです。早めにランブックを開くコストはわずかですが、待てば評判という代償を払うことになります。

重大度のレベルは事前に書き出しておきましょう。シンプルな3段階が使いやすいです。1人が監視する低レベルの「ウォッチ」、インシデントリードを置き1時間ごとに更新する「標準インシデント」、パスワードリセットや決済の領収書といったトランザクションメールに影響が出ている、または認証情報が侵害された可能性がある「クリティカル」です。以下の定義は調整のための例であり、標準ではありません。

レベル	トリガーの例(ご自身のトラフィックに合わせて調整)	対応
ウォッチ	1回の送信で、ある指標が通常の範囲を外れた	担当者が1時間以内に確認し、所見を記録する
インシデント	指標がベースラインの2倍になった、または主要プロバイダー1社が大量のメールを遅延または拒否している	ランブックを開き、リードを指名し、重要度の低い一括配信を停止して、1時間ごとに関係者へ更新する
クリティカル	トランザクションメールの遅延または拒否、認証情報の侵害の疑い、主要な送信IPまたはドメインのブロックリスト掲載	ランブックを全面適用し、4つの役割をすべて配置して、封じ込めまで30分ごとに更新する

最初の30分:トリアージと封じ込め

最初の30分の目的は、根本原因を突き止めることではありません。被害の拡大を止め、どこを調べるべきか分かる程度に問題を分類することです。次の手順を順に進め、それぞれの時刻を記録してください。

1. 0分から5分:宣言する。共有チャンネルを開き、インシデントリードを指名して、問題に最初に気づいた時刻と、おそらく始まった時刻を書き留めます。ログ、レポート、異なる場所にいる担当者の間で時刻が揃うよう、すべてのタイムスタンプはUTCで記録します。
2. 5分から10分:トランザクションメールを守る。主要なプロバイダーに用意した自分たちで管理するメールボックス宛てにテストメッセージを数通送り、パスワードリセット、ワンタイムコード、領収書が引き続き配信されていることを確認します。失敗している場合は、クリティカルなインシデントとして扱います。
3. 10分から15分:それ以外を停止またはスロットリングする。プロモーションキャンペーン、ニュースレター、後回しにできる予約済みの自動化を停止します。完全には止められないストリームは、送信レートを下げます。キューにあるメールは証拠になるため、まだ削除しないでください。
4. 15分から25分:分類する。直近1日のバウンス、遅延、苦情の件数をメールボックスプロバイダー別に確認し、前週と比較します。下の判断表を使って、最も可能性の高い原因ファミリーを選びます。
5. 25分から30分:作業を割り当て、最初の更新を送る。各調査担当に具体的な問いを割り当て、現時点で分かっている事実と次回更新の時刻を記した短い社内向け更新を送ります。

トランザクションメールを専用のストリーム、ドメイン、IPプールに分けておくと、領収書に影響を与えずにプロモーションだけを停止できるため、トリアージが格段に楽になります。まだ分けていない場合は、トランザクションメールとマーケティングメールのストリーム分離を参照し、インシデント収束後にプロジェクト化してください。

症状から原因を探る判断表

この表は、目に見える症状を最初に確認すべき項目へと結びつけるためのものです。挙げているのは確定した原因ではなく可能性の高い原因であり、複数が同時に起きることもあります。1列目はダッシュボードに表示される内容、2列目は影響範囲を問う観点、3列目は原因を裏付ける、または除外するための確認先です。

症状	範囲	可能性の高い原因	最初の確認
バウンスの急増(5xx拒否)	全プロバイダー、特定の時刻から	認証の不具合、DNSレコードの期限切れまたは削除、認証情報の誤り、未検証ドメインからの送信	SPF、DKIM、DMARCのDNSレコード、最近のDNSやプロバイダーの変更、バウンス応答のエラーメッセージ
バウンスの急増(5xx拒否)	1社のプロバイダー	そのプロバイダーでのポリシーによるブロックや評判に基づく掲載、急な量やコンテンツの変更	そのプロバイダーのバウンスメッセージ、postmasterデータ、そのプロバイダーへの最近の送信履歴
宛先不明エラーを伴うバウンスの急増	ほぼ1つのキャンペーンまたはインポート	古い、購入した、または入力ミスのあるアドレスがリストに追加された	リストの取得元、アドレスの古さ、検証結果
遅延の急増(4xx)	1、2社のプロバイダー	レート制限、初期段階の評判上の懸念、接続数が多すぎる	遅延メッセージ、現在の送信レートと同時接続数、キューの滞留時間
遅延の急増(4xx)	全プロバイダー	自社側のネットワークやDNSの問題、TLSの失敗、送信サーバーのリソース制限	ログ内のタイムアウトとTLSエラー、送信ホストからのDNS解決
苦情の急増	1つのキャンペーンまたはセグメント	想定外のオーディエンス、不明確な登録元、見つけにくい配信停止リンク	セグメントの定義、登録元、配信停止リンクの見やすさ、フィードバックループのデータ
開封とクリックが低下、バウンスは横ばい	1社のプロバイダー	拒否されることなく、メールが迷惑メールフォルダに振り分けられている	Postmasterデータ、シードまたはパネルによるテスト受信トレイの結果、最近のコンテンツや量の変更
開封とクリックが低下、バウンスは横ばい	全プロバイダー	トラッキングドメインの問題、画像ブロック、リンク切れ、または計測方法の変更	トラッキングドメインの証明書とDNS、リンクのテスト、最近のテンプレート変更
見覚えのない送信元からのメールが、DMARCレポートでドメインを通過している	集計レポートに現れる	なりすまし、または自社名義で送信している、忘れられたサードパーティツール	DMARC集計レポートの送信元、承認済み送信者のリスト、送信用認証情報のアクセスログ

特に注意が必要なパターンが2つあります。1つは、予定していない送信量の急増と苦情の急増が同時に起きる場合で、アカウントの侵害や漏えいしたキーによる不正送信の可能性があります。これはまずセキュリティ事案であり、到達率の問題はその次です。もう1つは、1社のプロバイダーだけの問題は多くの場合そのプロバイダーでの評判の問題であるのに対し、特定の1分から全プロバイダーに及ぶ問題は、通常、自社が変更した、または期限切れになった何かが原因だという点です。各ファミリーの詳細は、4xxと5xxの応答の読み方を説明しているSMTPバウンスコードの解説と、振り分けの問題を順を追って扱う迷惑メールフォルダのトラブルシューティングチェックリストをご覧ください。

変更する前に集めるべき証拠

証拠はすぐに失われます。ログはローテーションされ、キューは空になり、レポートは上書きされます。まず集めてから、修正してください。すべてをインシデントの開始時刻を名前に含めた共有フォルダにまとめ、各エクスポートのタイムゾーンを書き留めておきます。

証拠	分かること	取得方法
過去7日間のイベントログ	プロバイダー、ストリーム、キャンペーン別の受理、遅延、バウンス、苦情の件数	MigoSMTPのダッシュボード、API、Webhookからエクスポートします。具体的なオプションは、MigoSMTPのアカウントまたはAPIドキュメントでご確認ください
生のバウンス応答と遅延応答	プロバイダーが問題を説明する際の正確な文言	プロバイダー別に、拡張ステータスコードを付けて、異なるメッセージごとにサンプルをコピーする
配信されたテストメッセージと迷惑メールフォルダに入ったテストメッセージの完全なヘッダー	認証結果、経路、フィルターの判定	自分たちで管理するメールボックスにテストを送り、それぞれの元のソースを保存する
DMARC集計レポート	ドメイン名義で送信している送信元と、SPFとDKIMが通過しアライメントしているか	直近7日から14日分のレポートを取得し、その前の期間と比較する
メールボックスプロバイダーのpostmasterデータ	プロバイダーが公表している範囲での、ドメインとIPの評判シグナル、スパム率、認証結果	影響を受けたドメインのダッシュボードをスクリーンショットまたはエクスポートする
ブロックリストとDNSの確認	送信IPやドメインが掲載されているか、レコードが現時点で正しいか	利用している主要なブロックリストを照会し、SPF、DKIM、DMARC、逆引きDNS、トラッキングの各レコードを名前解決する
変更履歴	開始時刻の前後に、何がデプロイ、編集、切り替えされたか	チーム全体に確認する:コードのリリース、DNSの編集、新しいツール、リストのインポート、テンプレートの変更

DNSの簡単な確認は、どのターミナルからでも実行できます。以下のコマンドは、実際には存在しないドメインとセレクターを使って書き方の型を示したものです。ご自身の値に置き換えてください。

# Is the SPF record still published and valid?
dig +short TXT example.com

# Is the DKIM key for the selector still published?
dig +short TXT selector1._domainkey.example.com

# What DMARC policy is published?
dig +short TXT _dmarc.example.com

# Does the sending IP have the expected reverse DNS name?
dig +short -x 192.0.2.25

ヘッダーの読み方については、配信と認証をデバッグするためのメールヘッダーの読み方のガイドをご覧ください。評判ダッシュボードについては、Google Postmaster Toolsの記事で、各シグナルの意味と、必要になる前に設定しておく方法を説明しています。

封じ込めと復旧の手順

封じ込めは被害を止めること、復旧は安全にボリュームを戻すことです。この2つは別のフェーズであり、混同すると火を再び燃え上がらせてしまいます。1時間だけ指標が良くなったからといって、停止したストリームを再開しないでください。

原因別の封じ込め対応

• 認証の不具合:DNSレコードを復元または修正し、テストメッセージでSPF、DKIM、DMARCが通過しアライメントしていることを確認してから、トラフィックを再開します。
• 認証情報またはアカウントの侵害:認証情報を無効化して新しいものに置き換え、送信された内容を確認し、アカウントの所有者に通知して、セキュリティ手順に従います。キーのローテーションについては、APIキーのセキュリティに関するガイドで説明しています。
• 不適切なリストまたはセグメント:セグメントを除外し、バウンスまたは苦情のあったアドレスを抑制して、そのアドレスがどのようにリストに入ったのかを突き止め、再発を防ぎます。
• コンテンツまたはリンクの問題:テンプレートを取り下げ、疑わしいリンクや添付ファイルを取り除き、修正版を再送する前にテストします。
• ブロックリストへの掲載:まず掲載された理由を突き止めて原因を直し、そのうえで該当リストの削除手続きに従います。手順はブロックリスト削除ガイドで説明しています。
• プロバイダーによるレート制限:そのプロバイダー向けの同時接続数と1接続あたりのメッセージ数を減らし、相手が許容するペースでキューを消化させます。

段階的な復旧計画

1. 最もエンゲージメントが高く、最近登録した購読者から、通常の一部の量で再開します。
2. 各段階は、少なくとも丸1日分のプロバイダーからのフィードバックを待って維持します。データの反映が遅いプロバイダーについては、さらに長く待ちます。
3. バウンス率、遅延率、苦情率がインシデント前のベースライン以下にとどまっている間に限って、量を増やします。
4. 指標が悪化したら、その場にとどまらず、ひとつ前の段階に戻ります。
5. エンゲージメントの低いセグメントは最後に戻し、長期間反応のない連絡先には、再エンゲージメント施策や削除を検討します。
6. 最初に合意した期間、フルボリュームで指標が健全な状態が続いてから、はじめて復旧を宣言します。

新しいインフラ向けの同様の慎重な立ち上げ方は、ウォームアップの記事で説明しており、ここにも当てはまります。復旧は、最も良質なトラフィックを先に使う、小さなウォームアップだと考えてください。

連絡テンプレート

適切な連絡は、問題の修復にあたっている担当者を中断させる問い合わせの数を減らします。メッセージは短く、事実に基づき、定期的に送りましょう。分かっていること、分かっていないこと、現在の対応、次回更新の時刻を明記します。責任追及は避け、自分たちでは制御できない復旧時刻の約束もしないでください。以下の架空の文面は、ご自身のトーンに合わせて調整してください。

社内の関係者向け更新

Subject: Email delivery incident - update 1 (14:30 UTC)

Status: Investigating, contained.
Impact: Promotional emails to one large mailbox provider are being
delayed or filtered. Order confirmations and password resets are
being delivered normally in our tests.
Actions taken: Promotional sends paused at 14:10 UTC. Evidence
collection in progress. No changes made to DNS yet.
Next steps: Review provider responses and authentication reports.
Needed from you: Please do not schedule new campaigns until we confirm.
Next update: 15:30 UTC or sooner if anything changes.
Incident lead: [name]

サポート担当・顧客対応チーム向けメッセージ

Subject: For support: delayed or missing marketing emails

What customers may report: Some people have not received recent
newsletters or promotions.
What we know: We are investigating a delivery problem affecting one
mailbox provider. Account and transactional emails are working.
What to say: We are aware that some emails are delayed and are working
on it. Please ask the customer to check their spam folder and to add
our sending address to their contacts.
What not to say: Do not name a cause or promise a time until the
incident lead confirms.
Escalate to the incident lead if: a customer reports missing password
reset or payment emails.
Next update: 16:00 UTC.

架空の数値による実例

あるチームが、通常は1日におよそ20万通のプロモーションメールと1万5,000通のトランザクションメールを送信しているとします。通常のバウンス率は約0.6パーセント、通常の苦情率は約0.05パーセントです。ある火曜日のUTC 09:00に、8万件の連絡先へのキャンペーンが配信されました。09:40までに、ダッシュボードにはそのキャンペーンで2,400件のハードバウンス(3パーセント)が表示され、大手プロバイダーの1社が残りのメッセージの大半を遅延させています。

09:45にオンコールの調査担当がランブックを開きます。09:55までにプロモーションのストリームが停止され、テストの領収書メールが配信されていることが確認されました。判断表からは、1つのキャンペーンに集中した宛先不明エラーを伴うバウンスの急増が疑われます。リストの履歴を確認すると、8万件のアドレスのうち3万件は、2日前に古いイベントのスプレッドシートからインポートされ、一度も検証されていなかったことが分かりました。2,400件のバウンスのうち約2,000件が、このインポート分でした。

封じ込めはシンプルです。バウンスしたアドレスを抑制し、未検証のインポートをすべてのセグメントから除外して、今後使う前に検証を通します。チームは翌朝、最もエンゲージメントの高い連絡先に対し、通常の10パーセントの量でストリームを再開しました。バウンス率が1パーセントを下回る状態を保ちながら、その後の数日で25、50、100パーセントへと引き上げ、フルボリュームで3日間問題がなかったことをもって復旧を確認しました。レビューでは、新しいインポートは必ず検証を通し、指名された担当者が承認するまでキャンペーンに使わないという、新たなガードレールが加わりました。このインシデントのコストは、1日の停止といくつかのキャンペーンの遅れで済み、長期にわたる評判の立て直しは避けられました。

調整すべきガードレールとアラートしきい値

多くのインシデントは、適切な数値を誰も見ていなかったために、お客様から先に指摘されて発覚します。ガードレールは、その発見を早めます。以下の値は、適切なアラートの形を示すために選んだ例です。これらは普遍的な標準ではなく、適切な数値はオーディエンス、プロバイダー、これまでの実績によって異なります。数週間かけてご自身のベースラインを測定し、それに対する相対値でしきい値を設定してください。重視するメールボックスプロバイダーが公表している上限があれば、最新の送信者ガイドラインで確認し、何を追跡するかは、測定すべき指標に関するガイドも参考にしてください。

シグナル	アラートの例(ベースラインに合わせて調整)	推奨される自動アクション
キャンペーンごとのハードバウンス率	ベースラインの2倍超で警告、4倍超または独自に定めた絶対上限に達した時点で停止	キャンペーンを停止し、担当者に通知する
プロバイダーごとの苦情率	プロバイダーが公表する上限の半分で警告、4分の3で呼び出し	セグメントを停止し、登録元を確認する
プロバイダーごとの遅延の割合	通常は見られない割合(たとえば15分間で10パーセント)を超えたら警告	そのプロバイダーへの送信レートを下げる
トランザクションメールのキュー滞留時間	最も古いメッセージの待機が数分を超えたら警告	オンコールの調査担当を呼び出す
送信量	1時間あたりの送信量が、その時間帯の通常値の何倍かを超えたら警告	認証情報の侵害や暴走したジョブがないか確認する
DNSと証明書の健全性	SPF、DKIM、DMARC、トラッキングの各レコードが名前解決できるかを毎日確認し、証明書の期限切れの数週間前に警告	障害が起きる前に修正するチケットを起票する
新しいリストのインポート	検証と承認が済むまで、キャンペーンでの使用をブロックする	ワークフローで指名された担当者の承認を必須にする

アラートに加えて、ストリームの分離、キャンペーンごとの送信上限、新しい取得元に対する保留期間、各ドメインとIPに常任の担当者を置くといった、構造的なガードレールも追加してください。レートとリトライの挙動も重要で、ヘルプセンターのレート制限、リトライ、バックオフのガイドで説明しています。

オンコールの役割

ランブックは、ポケットベルが鳴る前に役割が決まっているときに最も効果を発揮します。小さな会社では1人が複数の役割を兼ねても構いませんが、それぞれの役割に担当者と代理を決めておく必要があります。

役割	責任	担当しないこと
インシデントリード	インシデントの宣言と終了、意思決定、更新時刻の設定	すべての調査を自分で行うこと
技術調査担当	ログ、ヘッダー、DNSの確認、修正のテスト、封じ込め案の提示	リードに伝えずに本番設定を変更すること
送信・キャンペーン担当	何を、誰に、なぜ送ったかの把握、ストリームの停止と再開	リードの同意なしにトラフィックを再開すること
連絡担当	関係者とサポートへの更新の送信、タイムラインの管理	原因を推測すること

事後レビュー

記憶とログが新しいうちに、数日以内にレビューを行います。個人を責めない形で進めましょう。目的は、誰がボタンを押したかではなく、システムのどこに問題をすり抜けさせた要因があったかを見つけることです。ほとんどのインシデントでは、1ページ程度の記録で十分です。

1. 概要:何が起き、どのような影響があったかを、2、3文で記します。
2. タイムライン:開始、検知、封じ込め、復旧の各時刻です。すべてUTCで記録します。
3. 根本原因と寄与要因:直接の原因と、それを許した、または検知を遅らせた不備です。
4. うまくいったこと:効果があり、今後も続けるべき対応です。
5. アクション:それぞれに担当者と期日を付けます。たとえば、新しいアラート、検証ステップ、DNSチェック、承認フローの変更などです。
6. フォローアップ:アクションの完了と指標の安定を確認する日付です。

インシデントチェックリスト

1. インシデントを宣言し、リードを指名し、開始時刻をUTCで記録した。
2. テストメッセージでトランザクションメールを確認し、専用のストリームで維持している。
3. 重要度の低い一括配信とプロモーションのストリームを停止またはスロットリングした。
4. 判断表で症状を分類した:バウンス、遅延、苦情、エンゲージメントの低下のいずれか、および1社か全社か。
5. 証拠を保存した:イベントログ、生の応答、ヘッダー、DMARCレポート、postmasterデータ、ブロックリストとDNSの確認結果。
6. チーム全体から変更履歴を集めた。
7. 再開する前に、原因を修正し、テストメッセージで確認した。
8. 合意した合格基準のもと、エンゲージメントの高い連絡先から、減らした量で段階的に復旧している。
9. 関係者とサポートへの更新を予定どおり送った。
10. レビューを実施し、アクションを割り当て、ガードレールとアラートを更新した。

MigoSMTPは、これらの手順のいくつかに役立つ送信機能、ログ、イベントを提供しています。ご利用いただけるレポート、Webhook、制御機能の詳細は、MigoSMTPのアカウントまたはAPIドキュメントでご確認ください。

参考資料と出典

• RFC 5321: Simple Mail Transfer Protocol(応答コードと再試行の挙動)
• RFC 3463: Enhanced Mail System Status Codes
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 6591: Authentication Failure Reporting Using the Abuse Reporting Format
• Google: Email sender guidelines