メール配信診断
テンプレートを変えたり、何度も再送したりすることから始めないでください。まずアプリがメッセージを生成したかを確認し、次にキューと送信サービスが受け付けたかを確認します。最後に認証、ポリシー、受信側を調べ、各段階で時刻とメッセージIDを記録しましょう。
クイック切り分け
順番に確認し、前のポイントの証拠がないまま次を推測してはいけません。
業務アクションによって、正しい受信アドレス宛てのメッセージが作成されていますか？
非同期タスクは正常にキューから取り出されましたか？それとも遅延、失敗、重複が発生していますか？
サービスプロバイダーの応答は、受付済み、遅延、バウンス、ポリシーによる拒否のどれですか？
アドレスはまだ有効ですか？一覧の更新と本文の読み込みは正常ですか？
新しいテスト受信トレイを作成し、アドレスをコピーしたら、内容がシンプルで一意の件名を付けたメールをすぐに送信します。件名には今回のテスト番号を入れても構いませんが、本番の秘密鍵や実在する顧客情報は含めないでください。
業務ボタンのクリック、タスクのキュー投入、サービスプロバイダーによる受付の時刻を記録します。シンプルなメールは届くのに複雑なテンプレートが届かない場合は、基礎ネットワークではなく、テンプレートのレンダリング、添付ファイル、コンテンツポリシーに問題がある可能性が高いでしょう。
業務イベントが送信条件を満たしているか確認します。たとえばアカウントの状態、環境スイッチ、重複排除ルール、通知設定などです。ログには「メールタスクを作成しました」という一般的な情報だけでなく、最終的な宛先アドレスが表示される必要があります。
アドレスが一字一句一致しているか確認します。特に、テスト用メールアドレスを変更した後もアプリが古いアドレスをキャッシュしている場合に注意してください。アプリにメッセージの記録がないなら、まずトリガーとテンプレートパラメーターを修正し、DNSの調査には進まないでください。
非同期メールは、キュー接続、ワーカープロセス、スケジュール時刻、再試行のバックオフで止まることがあります。キュー投入時刻、初回実行、各再試行、最終状態を比較し、タスクがまだ待機中でないことを確認します。
同じイベントから複数のメールが生成される場合は、冪等キーが安定しているか、成功応答の前にコンシューマーがタイムアウトしていないかを確認します。決定的なテンプレートエラーを無限再試行で隠さないでください。受信側に重複メールが発生します。
HTTP 2xxは通常、サービスプロバイダーがリクエストを受け付けたことを示すだけで、受信サーバーが最終的に受け入れたことまでは示しません。queued、sent、delivered、deferred、bounced、rejectedなどのイベントを続けて確認し、サービスプロバイダーのメッセージIDを保存します。
4xx系のSMTP応答は通常、一時的な遅延を示すため、推奨されるバックオフに従います。5xxは多くの場合、恒久的な拒否です。まずアドレス、認証、ポリシーを修正してください。サービスプロバイダーに該当するメッセージがまったくない場合、問題箇所はまだアプリとサービスプロバイダーの間にあります。
SPFが実際の送信元をカバーしているか、DKIM署名ドメインとFromドメインが設定どおりに一致しているか、DMARCのアライメントとポリシーがテスト環境と合っているかを確認します。DNSを変更したばかりなら、TTLや各リゾルバーのキャッシュも考慮してください。
管理画面の緑色の表示だけを見てはいけません。具体的なメールイベントや原文ヘッダーに含まれる認証結果を確認します。共有テストドメインで送信プラットフォームを頻繁に変更すると、古いレコードが残ったり、SPFのDNSルックアップ回数制限を超えたりしやすくなります。
まずプレーンテキストで基準メールを送り、HTML、画像、リンク、添付ファイルを一つずつ追加します。特定の項目を追加した後に失敗するなら、URLの評価、添付ファイルの種類、エンコード、メッセージサイズ、未置換のテンプレート変数を確認してください。
件名や本文でフィッシングを思わせる表現をまねたり、実際の認証情報を使ったりしないでください。認証コードのテストには固定のテストコードを使用し、テスト環境であることを明記します。テスト担当者が本番通知と誤認しないためです。
テスト受信トレイのカウントダウンがまだゼロになっていないことを確認し、現在のツールバーのアドレスと送信先が一致しているか確認します。手動で更新してください。アドレスを変更したばかりの場合、古い受信トレイのメールは新しいアドレスへ移行されません。
実際のメールが届いたら、デモ行が一覧から消え、実データだけが表示されるはずです。詳細を開いたら、件名、送信者、到着時刻、HTML本文、プレーンテキストのフォールバックを同時に確認します。一覧プレビューだけでテンプレートが完全だと判断しないでください。
業務トリガー、キュー投入、サービスプロバイダーの受付、受信の時刻を同じタイムゾーンで比較します。1つのポイントだけが明らかに長い場合に限り、遅延の原因をその区間に特定できます。タイムゾーンの異なるタイムスタンプを統一しないと、誤った判断につながります。
再送テストでは一意のイベント番号を変更し、古いメッセージIDも残します。後から送ったメールが先に届いた場合は、受信一覧の並び順の誤りだと決めつけず、キューの優先度、同時実行コンシューマー、プロバイダーの再試行を確認してください。
| 現象 | 優先して確認 | 次の手順 |
|---|---|---|
| アプリに送信ログがない | トリガー条件、環境スイッチ、テンプレートパラメーター | 業務フローを修正して最小ケースを再実行 |
| キュー投入済み、サービスプロバイダーのイベントなし | コンシューマー、認証情報、ネットワーク、タイムアウト | タスクのエラーと再試行記録を確認 |
| サービスプロバイダーにdeferredと表示される | SMTP 4xx、レート、評価 | バックオフ時間を待ち、連続再送しない |
| サービスプロバイダーにbouncedと表示される | アドレス、ドメイン認証、拒否理由 | 拡張ステータスコードに基づいて修正 |
| プレーンテキストは届くがHTMLは届かない | リンク、添付ファイル、サイズ、コンテンツポリシー | 項目を一つずつ追加して発生箇所を特定 |
| deliveredと表示されるが一覧が空 | 宛先、受信トレイの有効期限、メッセージID | 完全な証拠を受信側サポートに提供 |
上記の手順でも特定できない場合は、タイムライン、宛先、業務イベントID、サービスプロバイダーのメッセージID、最終状態、除外済みの項目を最小限の証拠パッケージにまとめます。機密性の高い本文は削除し、問題の再現に必要な情報だけを残してください。
MSGTMPサポートに連絡する際は、受信トレイの作成時刻と有効期限、アドレスを変更したかどうか、送信サービスプロバイダーに記録された最終応答を伝えてください。パスワード、ログイン認証コード、完全な秘密鍵は送信しないでください。サポートメールアドレスは support@msgtmp.comです。
「再送したらたまたま届いた」では不十分です。問題箇所を特定して原因を説明し、同じ最小ケースで修正後も安定することを確認できて初めて完了です。
