配信トラブルシュート
テストメールが届かない：証拠を集めてから再送を判断する
「届かない」という結果だけでは、どの層で障害が起きたか分かりません。効果的な調査は、アドレスの有効性確認から始め、送信タスク、サービスプロバイダーの応答、受信ポーリング、本文の表示まで順に進めます。
まず状況を固定し、送信ボタンを連打しない
連続して再送すると複数のタスクとメッセージIDが作成され、「どの操作に対応するメールか」が分かりにくくなります。現在の受信アドレス、実行時刻、テスト環境、テンプレートのバージョン、アプリケーションログのタスクIDを先に記録しましょう。
時間の基準を統一することも重要です。ブラウザー、キュー、サービスプロバイダーの管理画面でタイムゾーンが異なる場合があるため、UTCに換算し、元の時刻も残しておくのが安全です。
第1層：アドレスが完全で、まだ有効か確認する
受信ページからアドレスをコピーし直し、履歴を見ながら手入力しないでください。@の前後の文字、余分な空白、テストスクリプトが前回交換済みのアドレスを参照していないかを確認します。
使い捨てメールアドレスには有効期限があります。アドレスの期限が切れていたり、別の受信箱に切り替わっていたりすると、古いトークンでは新しいメールが現在のページに表示される根拠になりません。新しいアドレスを作成し、最小構成のメールを1通送る方が確実です。
第2層：「業務トリガー」と「メール処理」を切り分ける
ページに成功と表示されても、メールタスクの処理が始まったとは限りません。アプリケーションが正しくタスクを作成したか、コンシューマーが稼働しているか、リトライを使い切っていないか、テンプレートの描画前に受信者変数が上書きされていないかを確認します。
タスクがキューに残ったままなら、受信システムからは何も確認できません。この場合は受信ページを何度も更新するのではなく、コンシューマーや設定を修正します。
第3層：サービスプロバイダーまたは SMTP の応答を読む
メッセージID、受け付け応答、拒否コード、バウンスイベントを確認します。「受け付け済み」は通常、次の配送先がリクエストを受信したことを示すだけで、最終的に目的の受信トレイへ届いたことを意味しません。
4xxの一時エラーなら、バックオフ戦略に従って待ちます。5xxの恒久エラーなら、ドメイン、受信アドレス、認証、コンテンツポリシーを先に修正します。元の応答を保存し、「送信に失敗した」だけで済ませないでください。
第4層：ポーリング、一覧、本文は別々に確認する
1回分のポーリング間隔を待ってから手動で更新し、ブラウザーのネットワークリクエストを確認します。一覧に件名と送信者が表示されるなら、メールは到着しています。詳細が空の場合は本文データを調べるべきで、DNSを再確認する必要はありません。
メールの詳細には html_body や text_body が含まれる場合があります。HTMLテンプレートが隔離されたり、外部画像が読み込まれなかったり、スクリプトが除去されたりしても、メールが未着とは限りません。プレーンテキストのフォールバックと元のフィールドを比較しましょう。
第5層：最小構成のメールで比較対象を作る
新しい使い捨てアドレスを作成し、固定の件名、他と重複しないイベントID、1文のプレーンテキストだけを含むメールを送ります。画像、添付ファイル、複雑な変数は入れません。最小構成のメールが届いたら、HTML、ブランド素材、業務データを少しずつ追加します。
比較対象を用意すると、基本的な配信の問題とコンテンツポリシーの問題をすばやく切り分けられます。一度に変更する変数は1つだけにしてください。そうしないと、復旧しても本当の原因が分かりません。
結果を次回も使える結論にまとめる
結論には少なくとも、障害が発生した層、直接的な証拠、修正内容、再テストのサンプル、まだ説明できていない制限を含めます。「リトライしたら直った」だけを残してはいけません。同じ問題の再発防止につながらないためです。
現在発生している障害を調べている場合は、配信トラブルシュート実験台で4つの事実から優先して確認すべき項目を生成できます。