認証コードのメールが複数届いたとき、今使うべき1通を見分けるには？

3つの時系列を区別する

1つ目はリクエスト時刻です。送信元のサービスで送信をクリックした時刻を指します。2つ目は到着時刻で、メールを受信し、受信一覧に表示された時刻です。3つ目は使用時刻、つまり認証ページにコードを入力した時刻です。この3つは同じタイマーで動いているわけではありません。サービスによっては、認証コードを発行してからキューに入れることも、キューに入れてから発行することもあります。受信箱で確認できるのは届いたメールだけで、送信側の内部処理の順序まではわかりません。

たとえば、10:00にAをリクエストし、10:01にBをリクエストしたとします。Bは10:02に届き、Aは10:03になってから届きました。受信一覧で最も新しいメールはAですが、最後にリクエストしたのはBです。再送時に古いコードを無効にするサービスもあれば、一定時間は複数のコードを有効にするサービスや、コードを現在のセッションに紐づけるサービスもあります。そのため、「常に一番上のメールを使う」というルールは当てになりません。判断の基準にするべきなのは、送信元サービスの現在のページに表示されている案内です。

メールに記載された有効期限を、「今届いたばかりだから」と勝手に計算し直すのも避けましょう。発行時点から期限が始まり、配信中に一部の時間が経過している場合があります。パソコンとサーバーの時計がずれていれば、目視での比較にも誤差が生じます。明確に期限切れと表示された場合は、サービスで認められた方法で新たにリクエストしてください。端末の時計を変更したり、古いコードを何度も試したりしないでください。

認証を1つの手順にまとめる

メールがすでに3～4通届いているなら、いったん止まり、5回目のリクエストはしないでください。ログインを完了するための認証ページを1つだけ残し、不要な同じサービスのページは閉じます。ページに表示された受信アドレスが、現在の受信箱のアドレスと完全に一致しているかも確認しましょう。コピー後の前後の空白、ブラウザーの自動入力、アドレスの切り替えにも注意してください。よく似たメールアドレスでも、同じ受信箱とは限りません。

1. 同じ認証ページで、登録なのかパスワードのリセットなのかなど、目的と対象のアドレスを確認します。
2. 送信元サービスが定める待機時間が終わるまで待ち、1回だけ送信して、おおよその時刻を記録します。
3. 受信箱のアドレスは変更せず、残りの有効時間を確認します。必要であれば、延長するためのリンクを使います。
4. 今回の目的に合ったメールを開き、元の認証ページに戻って1回だけコードを送信します。
5. 送信後、ページの結果を確認してから、次のリクエストが必要か判断します。

この手順で配信が保証されるわけではありませんが、失敗の原因を切り分けやすくなります。新しいメールが届かない場合は、もう少し待つか、認証コードが届かない場合の対処法を確認してください。メールは届いたのにコードが拒否された場合は、認証セッションと有効期限を優先して確認します。この2種類の問題をひとまとめにして「メールボックスの不具合」と考えると、アドレスを何度も変えるうちに、はっきりしていた手がかりを失ってしまいます。

数字だけでなくメールの内容を確認する

まず、件名、送信元アドレス、メールの用途、端末に関する案内を確認しましょう。パスワードをリセットしようとしているのに、件名が「ログイン」なら、同じ6桁の数字でも使い回してはいけません。注文番号、問い合わせ番号、郵便番号、認証コードは同じような見た目の場合があります。自動抽出された数字は読み取りを補助するだけで、そのコードの用途や正当性を証明するものではありません。

送信者の表示名も本人確認にはなりません。攻撃者がブランド名や文面をまねることもあります。見慣れたデザインだからといってメール内のリンクをクリックしたり、サポート担当者を名乗る人に認証コードを教えたりしないでください。公式アプリや既知のURLから自分で始めた操作なら、そのページに戻って続けましょう。リクエストした覚えがなければ、通常はメール内のコードを使わず、公式の窓口からアカウントの安全性を確認するのが最も安全です。

メールに端末、場所、時刻の情報があれば、今回のリクエストと明らかに無関係なメールを除外する手がかりになります。ただし、おおまかな場所を正確な証拠とみなさないでください。モバイル回線、プロキシの出口、サービス提供者による位置情報の判定などで、表示場所が変わることがあります。「自分がリクエストしたか」「用途が一致しているか」「セッションが一致しているか」を総合して判断しましょう。アイコンやブランドカラーだけを根拠にしてはいけません。

遅れて届いたメール、古いコード、無効エラーへの対処

メールが遅れて届いた時点ですでに認証が完了しているなら、もう一度試す必要はありません。再送信するとエラー回数が増えたり、不要なログイン手順に戻されたりすることがあります。認証がまだ終わっていない場合は、現在のページが引き続き有効か確認してください。ページを閉じた、認証が新しくなった、ブラウザーのセッションがリセットされたといった場合、古いメールを残しておいても、元の認証状態には戻せません。

「無効」と表示されたら、まずコピー時に空白、全角数字、改行が混じっていないか確認し、別の用途のコードを貼り付けていないことも確かめましょう。それでも拒否される場合は、サービスの再試行制限に従ってください。届いたコードをすべて順番に試すのはやめましょう。連続して失敗すると認証が一時的にロックされるサービスもあり、受信箱から送信元サービスの制限を解除することはできません。

サービスが使い捨てメールを明確に禁止している場合は、利用をやめ、認められている長期利用可能なアドレスを選んでください。大量のドメインを試したり、何度も再送したり、端末を変えたりしても、ルールに沿った解決にはなりません。一時メールはリスクの低い短期確認に適しています。銀行、医療、メインアカウントの復旧には使わないでください。

秘密情報を含めずにテストを記録する

メール送信の開発や受け入れテストでは、1回のテストを「リクエスト時刻」「到着時刻」「ページの表示」「最終結果」の4項目で記録するのがおすすめです。リクエストはR1、R2のように記録し、認証コードの本文を書き写す必要はありません。これにより、「2回目のリクエスト後に1通目が届く」といった現象を把握し、配信の遅れとフロントエンドのセッション消失を区別できます。テストごとに変更する条件は、ブラウザーかアドレスなど1つだけにし、すべての変数を同時に変えないでください。

調査用のスクリーンショットを共有する前に、メールアドレス全体、認証コード、トークン付きの確認リンク、アカウント識別情報を隠してください。注文通知にも氏名や配送情報が含まれることがあります。パスワードのメールではないからといって、公開してよいわけではありません。サポートに問い合わせる際は、おおよその時刻、操作手順、表示されたエラー、リクエストを複数回行ったかどうかを伝えると役立ちます。有効な認証コードを知らない相手に送る必要はありません。

自社のメール送信システムを担当している場合は、ユーザーの秘密情報を漏らさずに、内部リクエストIDで送信ログと認証ログを紐づけられます。認証コード全体を分析イベントやブラウザーのコンソールに記録しないでください。この記事は人が確認する際の手順を提案するものであり、FwdBayが第三者の送信キューを確認したり、認証コードが失効したか判定したり、認証を代行したりできると主張するものではありません。

認証後にもう一度確認する

認証成功の表示が出たら、アカウントに登録されているメールアドレスが現在の一時アドレスのままか確認してください。今後、安全に関する通知、更新のお知らせ、アカウント復旧メールが届く可能性があるサービスでは、一時アドレスが使えなくなる前に、自分で長期管理できるアドレスへ変更し、新しいアドレスの認証を済ませましょう。今回メールを受信できたことは、今この時点で受信できる証明にすぎず、半年後にも復旧手段があることを保証しません。

短期の認証が終わったら、機密性の高いメールは速やかに削除してください。長期保管が必要な業務通知は、保存方針が明確なメールアドレスに転送しましょう。低リスクの認証を1回だけ行うなら、現在の受信箱を使えます。送信元ごとに連絡を継続して受け取りたい場合は、独立した転送用エイリアスを検討してください。選ぶ基準は、どちらが速そうかではなく、どのくらいの期間連絡を受け取る必要があるかです。