認証メールは通常すぐ届きますが、「すぐ」が何秒かは一律ではありません。アプリの処理、メッセージキュー、メールサービス、受信ドメイン、メールソフトの更新にそれぞれ時間がかかります。再送を何度もクリックするとコードが複数発行され、最新のコードと最初に届いたメールが食い違う原因になります。
1. まず時間の基準を作る
ユーザーが送信をクリックした時刻を起点にし、「待ち始めた時刻」を起点にしないでください。その後、APIの応答、サービス事業者の受信時刻、メールの到着時刻を記録します。この3つの時刻から、遅延がアプリ、送信サービス、受信側のどこで起きたかを判断できます。
これらは確認の順序であり、サービスの保証時間ではありません。大量送信、ドメイン評価の変化、受信側のグレーリストによって時間が延びることがあります。状況に応じた待機時間の目安を知りたい場合は、認証遅延計算ツールを使ってキューと再試行条件を記録できます。
2. 本当に送信されたか確認する
ページに「送信済み」と表示されても、フロントエンドのリクエストが完了しただけで、メールサービス事業者がメッセージを受け付けたとは限りません。まずAPIの状態、メッセージキュー、サービス事業者のイベントログを確認します。理想的なログでは、同じリクエストIDでユーザー操作、テンプレートのレンダリング、サービス事業者への送信、最終配信イベントを追跡できます。
- APIエラー：パラメータ検証、レート制限、認証を確認し、フロントエンドが誤って成功を表示しないようにします。
- キュー待機：滞留件数、コンシューマーの状態、再試行回数を確認し、重複タスクを防ぎます。
- サービス事業者による拒否：曖昧なテキストを保存するだけでなく、標準化されたエラー分類を確認します。
- 配信済み：受信ルール、迷惑メール分類、メールソフトの更新を引き続き確認します。
3. アドレス、有効期限、受信ルールを確認する
最も多い原因は、やはりアドレスの入力ミスです。コピー時に空白が入っていないか、文字が抜けていないか、ドメインが正しいか確認してください。一時的なテストアドレスの場合は、有効期限が切れていないことも確認します。期限切れのアドレスは、以前使えていたとしても新しいテストには使用しないでください。
送信側で配信済みと表示された場合は、受信トレイのルール、迷惑メール分類、企業ゲートウェイの隔離、メールソフトのキャッシュを確認します。テストには専用の受信アドレスを使い、個人メールに残る過去のルール、購読、エイリアス設定が判断に影響しないようにします。RTのホームにあるテスト受信トレイは自動でポーリングします。新しいアドレスに手動で変更し、基準を作り直すこともできます。
4. 再送に適したタイミング
再送する前に、少なくとも3つ確認してください。最初のリクエストが完了していること、現在のアドレスがまだ有効であること、ページ上のクールダウンが終了していることです。送信サービスがまだ再試行中なら、新しいリクエストはキューを増やすだけです。「最新の認証コードで古いコードを無効にする」仕組みでは、先に届いた古いメールのコードが使えない場合もあります。
適切な再送ボタンでは、クールダウンの状態を明確にし、リクエスト成功後は1つのカウントダウンだけを表示します。再送時には、メールの件名や本文で新しいコードであることを知らせても構いませんが、内部の再試行回数は表示しないでください。ユーザーがメールアドレスを間違えた場合は、ページ全体の再読み込みではなく、メールアドレスの入力手順に戻れるようにします。
送信を連続してクリックしないでください。認証コードのページを複数開いたり、古いメールのコードを順番に試したり、リクエスト時刻を記録せずに「メールサービスが遅い」と決めつけたりするのも避けましょう。
5. 1回の遅延を再現可能な証拠に変える
有効な記録には、少なくともリクエスト時刻、受信時刻、対象ドメイン、テンプレート種別、サービス事業者のイベント状態、最終メールヘッダーを含めます。件名、From、Message-IDがあれば、どのリクエストのメールかを確認できます。時刻や識別情報のないスクリーンショットだけでは、古いメールと新しいメールを区別できません。
調査では、まず1つの変数だけを変えて再テストします。同じテンプレートでアドレスを変える、同じアドレスでテンプレートを変える、または同じ受信ドメインで送信環境を変える方法です。一度に1つだけ変えれば、問題の範囲を絞れます。特定の受信ドメインだけで遅延が起きる場合は、HTMLを書き直す前に、ドメイン単位のバウンス、評価、レート制限を確認してください。
6. リリース前に遅延の誤判定を減らす
リリース前には、正常な到着、一時的な遅延、送信失敗、コードの期限切れ、再送という5つの状態をテストしてください。画面の文言では、待機中であること、再送できるタイミング、メールアドレスの変更方法を伝え、バックエンドのエラーをユーザーが行動に移せるローカライズ済みの案内に変換します。
トランザクションメールのチームは、業務リクエストからサービス事業者の受信まで、受信から配信まで、そしてユーザーが認証を完了するまでの時間など、観測可能な指標も設定すべきです。これらの指標をテンプレートのバージョンと関連付ければ、問題が配信経路にあるのか、コンテンツ変更にあるのかを判断できます。メール到着後の表示も確認する場合は、HTMLメールの表示チェックガイドを続けてご覧ください。