メールのワンタイムパスワードの致命的リスクとは？時代はAuthenticatorの活用へ

ユーザーが自社サービスにログインしようとした瞬間、「ワンタイムパスワードを送信しました」という画面が表示されたきり、何分待ってもメールが届かない。

ようやく届いたと思ったら「有効期限が切れています」と弾かれてしまう..😢。

こうした問題はもはや「たまに起きるトラブル」ではなく、メール配信によるワンタイムパスワード認証が構造的に抱えるリスクが顕在化した結果です。

今回のは、IT担当者・システム管理者の視点から、なぜメールワンタイムパスワードが危険なのか、そしてどのように移行を進めるべきかを考えていきたいと思います。

実際に毎週金曜日に再現するワンタイムパスワード遅延の悪夢

ある保険会社で本人確認用のワンタイムパスワードメールが、

• Hotmail
• Outlook

といったMicrosoftの無料メールアカウント宛てに送信された際、毎週金曜日に必ず大幅な遅延（4xxエラー）が発生し、パスワードの有効期限が切れてしまうという現象が定期的に繰り返されていました。

Microsoftのサポートに問い合わせても、最初に返ってくるのは「システムに問題は見当たらない」という定型文のみ。粘り強く交渉して一時的に制限が緩和されても、翌週の金曜日も同じ遅延が再発。

担当者としてはお手上げ状態。お客さまからのクレームは積み上がり、サポートチームもエンジニアも疲弊するという消耗戦が続いたとのことです。

実はこのトラブルは決して特殊なケースではありません。

MicrosoftやGoogleといった大手メールプロバイダーは、迷惑メール対策として受信サーバー側で独自のトラフィック制御を行っており、その判断基準や閾値は非公開です。

金曜日の夕方に遅延が集中した背景には、業務終了時間帯の大量送信による一時的なレート制限がかかったと考えられますが、送信側からはその挙動を完全に把握することも制御することもできません。

インフラ設定による解決の限界

メール配信の現場では、こうしたトラブルに対して以下のような技術的アプローチが取られるのが一般的です。

送信IPとキューの分離

マーケティングメールや通常の通知メールと同じIPアドレスを使っている場合、それらの評判がワンタイムパスワードメールにも影響してしまいます。

たとえば大量のお知らせメールが迷惑メール判定を受けると、同じIPから送られるワンタイムパスワードメールまで届きにくくなるのです。

「送信キュー」とは、送信待ちのメールが順番に処理されていく行列のようなものです。

お知らせメールが大量に並んでいる行列にワンタイムパスワードメールも紛れ込んでしまうと、処理の順番待ちで届くまでに時間がかかることがあります。

そこで、ワンタイムパスワード専用の独立したIPアドレスと送信キューを用意することで、他の種類のメールの影響を受けずに、素早く確実に届けられるようになります。

再送間隔の短縮

メールがエラーで一時的に送れなかった場合、システムは自動的に再送を試みます。通常のメールでは、エラー発生後に数十分待ってから再送する設定が一般的です。

しかし、すぐに届かないと意味がないワンタイムパスワードメールに限っては、数秒から数十秒という短い間隔で素早く再送する設定が有効な場合があります。

IPウォームアップと送信レートの管理

新しいIPアドレスを使い始める場合、いきなり大量のメールを送ると受信BOXから「得体のしれない危険な送信元？」と判断され、迷惑メールフォルダに振り分けられたり、遅延の原因になったりします。

そのため、最初は少量から送り始め、徐々に送信量を増やしていくことで、受信BOXからの信頼を段階的に獲得していく必要があります。

なお当社が提供する、ドメインウォームアップサービスの一環でIPウォームアップも実現できます。

ドメイン認証の徹底（SPF / DKIM / DMARC）

SPF・DKIM・DMARCとは、「このメールは本当にこのドメインから送られたものです」と受信側に証明するための仕組みです。

SPFは住民票、DKIMは印鑑証明書。そして、それが正しい情報でなかったときにどう処理するか指示するのがDMARC。これらの設定を正しく設定しないと迷惑メール判定のリスクが高まります。

一方で、SendGridやAmazon SESといったメール配信サービスの共有インフラを使っている場合は、IPレベルの細かなカスタマイズには限界があります。

そして最大の問題は、どれだけ送信側がベストプラクティスを尽くしても、受信側（MicrosoftやGoogle）のフィルタリングロジックを送信者が完全にコントロールすることは不可能という点です。

受信プロバイダーはスパム対策のためにアルゴリズムを常時変更しており、昨日まで問題なく届いていたメールが、今日から遅延するケースは珍しくありません。

根本的な問題：「メールはリアルタイムツールではない」

この状況に対し、今の時代に必要なのは、設定のチューニングではなく設計思想の転換です。

「遅延が致命傷になるワンタイムパスワードにおいて、到着時間が保証されない『メール』という手段を使うこと自体が根本的に誤っている」

と、理解するということです。

SMTPはもともと「蓄積交換型」の設計思想に基づいており、一時的な遅延はエラーではなく仕様として許容された文句が言えない動作なのです。

RFC 5321（セッション2.1）にも

“Consequently, SMTP is primarily a deferred-delivery system rather than an instant messaging system.”

「SMTPはメッセージを届けるもので、即時に配信する義務はない」と明記されています。

数秒以内のリアルタイム性が絶対条件となるワンタイムパスワード認証に、このプロトコルを使い続けることは、設計上の根本的なミスマッチです。

認証アプリ（Authenticator）への移行を検討すべき理由

専門家たちが強く推奨するのが、Google AuthenticatorやMicrosoft AuthenticatorなどのTOTP（Time-based One-Time Password）認証アプリへの移行です。

TOTPはRFC 6238で標準化されており、サーバーとアプリが共有する秘密鍵と現在時刻から30秒ごとに6桁のコードを生成します。

通信は初期設定時のみ必要で、認証のたびにメールやSMSを送る必要もありません。

移行によって得られる3つのメリット

(1) 配信トラブルからの解放

プロバイダーのレート制限やブラックリストを気にする必要がなくなります。リソースに限界があるサポートへの問い合わせが溢れるような事態も解消されます。

(2) ユーザー体験の向上

ユーザーは受信トレイの更新を待つことなく、アプリを開いてパスワードを確認するだけで、即座にログインを完了できます。認証にかかる時間が劇的に短縮されます。

(3) サポートコストの削減

「ワンタイムパスワードが届かない」という問い合わせと、その調査・対応にかかるシステムエンジニアの工数を大幅に削減できます。

移行の現実：すぐには切り替えられないケースへの対応

とはいえ、「明日からすべてのユーザーに認証アプリを使ってもらう！」というわけにはいかないと思います。

一般消費者向けサービスや、ITリテラシーが多様なユーザー層を抱えるサービスでは、段階的な移行が必要です。

現実的な移行ステップとしては、次のような段取りをとる必要があります。

• フェーズ1（共存）：認証アプリを「推奨オプション」として追加し、メール認証と並列提供する。ユーザーに選択肢を与えつつ、アプリ認証への誘導を強化する。
• フェーズ2（優先化）：新規登録ユーザーにはアプリ認証をデフォルトに設定。メール認証はフォールバック扱いとする。
• フェーズ3（廃止）：十分な移行期間を経たのち、メールのワンタイムパスワードを廃止またはアカウント復旧時のみに限定する。

なお、認証アプリへの移行が難しいユーザー層に対しては、SMSもメールよりはリアルタイム性の高い代替手段です。

ただし、攻撃者が被害者の携帯電話番号を自分のSIMカードに不正に移行させ、電話番号そのものを乗っ取る「SIMスワッピング攻撃」のリスクがあるため、高セキュリティが求められる用途ではSMSも過信は禁物です。

最後に

メールのワンタイムパスワードのトラブルに直面すると、私たちはつい

• どうすれば早く届けられるか
• どのIPを使うべきか

というインフラ最適化の思考に入りがちです。

しかし今回のケースが示すように、問題の本質は「リアルタイム性が求められる用途に、非リアルタイムな仕組みを使い続けていること」にあります。

メールのワンタイムパスワードの維持にかかる運用コスト

• メール配信にかかる費用
• 障害対応工数
• サポートへの問い合わせ対応

を積み上げると、認証アプリへの移行コストは決して高くはないはずです。

次回のシステム改修のタイミングで、ぜひ認証アプリへの移行を検討してみてください。

それは単なるセキュリティ強化ではなく、ユーザー体験の向上と、エンジニアの平穏な週末を取り戻すための、最もコストパフォーマンスの高い投資となるはずです。