メールの認証エラーの原因が、
パスワードではなく
「時計」だった

by
  • Macの「メール」がOutlookのアカウントで「認証できませんでした」を出し続けたのに、パスワードも2段階認証も何も壊れていませんでした。
  • 原因は、お盆明けに電源を入れたMacのシステム時計が1時間ほどずれていたことでした。
  • OAuthのアクセストークンもワンタイムコードも、有効期限を「いまの時刻」と突き合わせて判定します。時計が狂うと、正しい資格情報が期限切れに見えます。
  • サーバーが返すのは「認証に失敗した」という結果だけで、理由は書かれていません。エラーメッセージは症状であって、原因ではない。

関連記事

1. メールアプリだけがログインを拒否した

お盆明けの朝、MacでメールアプリからOutlookのアカウントに再認証を求められました。

画面の見た目は、いつもの流れです。 「アカウント “user@outlook.jp” のパスワードを入力してください」というシートが開き、その中にMicrosoftのサインイン画面が埋め込まれて出てくる。 そこまでは何の変哲もありません。

ところが、パスワードの入力欄ではなく「メールをご確認ください」という本人確認の画面が出ました。 確認コードを復旧用のアドレスに送るので、そのアドレスを自分で打ち込め、という画面です。 言われたとおりに入力すると、コードは届きました。 それを入れると、返ってきたのは「認証できませんでした。認証されませんでした。あとでやり直してください。」

手動でアカウント名とパスワードを入れ直すと、今度は「アカウント名またはパスワードを確認できません。」と言われます。 何度やっても同じ。 パスワードは合っているという確信があるのに、機械の方は頑として認めない。

調べてみると、これとまったく同じ症状の集団報告が過去に何度も出ていました。 2025年10月には、Apple標準メールにOutlook.comやHotmailのアカウントを追加できないという投稿が世界中から上がっています1。 2026年4月末にはMicrosoft自身がサービス正常性ページで障害を認め、標準メールアプリからのアクセスに問題が出ていると告知しました2。 「これも同じやつか」と思いかけたところで、iPhoneのOutlookアプリから同じアカウントでテストメールを送ってみたら、あっさり届きました。 アカウントは生きている。パスワードも2段階認証も正常。

2. 原因はシステム時計が1時間ずれていたことだった

そこで、ふと引っかかったのがお盆でした。 このMacは連休のあいだ、ずっと電源を落としていました。 念のためシステム設定の日付と時刻を開いて、時刻を合わせ直し、メールアプリを起動し直す3。

すると、認証エラーは出ませんでした。 再認証の要求すらありません。 何事もなかったかのように、そのまま送受信が動きました。

あとから当時のスクリーンショットを見返して、少し笑ってしまいました。 届いた確認コードのメールは、受信時刻が9時59分と表示されています。 一方で、同じころに撮った画面のメニューバーの時計は、9時04分。 証拠は最初から画面の中に写っていたわけです。

3. 認証の合否は「いま何時か」を基準に判定している

なぜ、時計が1時間ずれただけでログインできなくなるのか。

3.1. アクセストークンには有効期限が書き込まれている

いまのメールアプリは、パスワードを毎回サーバーに送っているわけではありません。 最初に一度だけサインインして、そのかわりにアクセストークン（access token）と呼ばれる文字列を受け取ります。 以降の通信では、パスワードではなくこのトークンを提示する。 これがOAuth（Open Authorization：オープン認可）と呼ばれる仕組みで、Microsoftは個人用アカウントについても、この方式でないと接続を受け付けなくなりました4。

トークンの中には、いくつかの時刻が書き込まれています。 いつ発行されたか。いつまで有効か。いつから使えるか5。 Microsoftのアクセストークンの寿命は、標準でだいたい1時間です6。

ここで、時計が1時間ずれていたらどうなるか。 サーバーは「このトークンは10時00分まで有効」と書いて渡します。 受け取ったMacは、自分の時計を見て「いまは9時04分」と判断する。 一見すると、まだ使える。 ところが逆方向にずれていれば、発行されたばかりのトークンが、手元では最初から期限切れに見えます。 「まだ有効になっていない未来のトークン」と判定されることもある。 どちらに転んでも、正しく発行された資格情報が、正しくないものとして扱われます7。

3.2. ワンタイムコードと証明書も時刻に依存する

本人確認で送られてくる確認コードも同じです。 あれは発行から数分で失効する短命なもので、判定に使われるのは時刻8。 届いたコードを正しく入力しても、時計の基準がずれていれば話が噛み合いません9。

一方で、通信の暗号化に使われるTLS証明書は、今回はあまり関係がなかったはずです。 証明書の有効期間は月単位から年単位なので、1時間程度のずれでは有効期間の外に出ません10。 時計が数か月ずれていれば、こちらも一斉に「この証明書は無効です」と言い出します。

厄介なのは、サーバーが返してくるものです。 「トークンの期限が切れている」も「パスワードが違う」も、プロトコル上は同じ認証失敗として返ってきます。 受け取ったアプリは、それを日本語に訳して「アカウント名またはパスワードを確認できません」と表示するしかない。 アプリは嘘をついていません。ただ、本当のところを知らないだけ。

4. エラーメッセージは症状であって原因ではない

今回いちばん時間を食ったのは、画面に「認証」と書いてあったことでした。

認証と言われれば、認証の周りを探します。 パスワードを疑い、2段階認証を疑い、アプリパスワードを試し、Microsoftのアカウント設定を開く。 実際、フォーラムでも同じ道をたどった人が大勢いて、パスワードを変え、2段階認証をオンオフし、それでも直らないと報告しています11。 時計を疑った人は、ほとんどいませんでした。

そして、この道の先には落とし穴があります。 アカウントをいったん削除して追加し直す、という手です。 これは一見もっともらしいのですが、フォーラムには「消したら二度と追加できなくなった」という報告がいくつも並んでいます12。 動いている接続を自分から切ってしまうと、戻すときに認証をやり直すことになる。 その認証が壊れているから困っているのに。

時刻は、どのエラーメッセージにも顔を出さないのに、あらゆる認証の前提になっています。 証明書の検証も、トークンの期限も、ワンタイムコードも、全部そこにぶら下がっている。 だから、認証まわりで「どう考えてもおかしい」という状況になったら、パスワードより先に時計を見るほうが早いのかもしれません。

なお、日付と時刻の自動設定がオンでも、こういうことは起きます。 長く電源を落としていた直後は、ネットワークにつながって時刻サーバーと同期するまでにわずかな間があります。 その隙にアプリが認証を始めれば、狂った時計のまま判定されます13。 何度も繰り返すようなら、そちらは内蔵電池の消耗を疑う番。

原因が分かってしまえば、なんてことのない話でした。 それでも、丸一時間かけてフォーラムを読み漁った甲斐はあったと思っています。 機械が「パスワードが違う」と言うとき、機械が本当に見ているものは何なのか。 それを一度でも覗いておくと、次に同じ顔をしたエラーが出たときに、少しだけ違う場所を探せます。

  1. このときの報告では「Authentication Failed」と「Unable to verify account name or password」の2種類のエラーが確認され、iCloudやGmail、法人向けのMicrosoft 365 Exchangeは影響を受けていないと整理されています。 – Apple Mail breaks Outlook sign-ins, but only if you’re unlucky
  2. このときのステータス表示には、iOSの標準メールアプリからOutlookとHotmailにアクセスする際に問題が生じる可能性がある、という趣旨の記載が含まれていました。 – Service change takes down Microsoft Outlook for iOS
  3. Appleは、メールやメッセージ、ファイルのタイムスタンプを正確に保つために、ネットワークタイムサーバを使った自動設定を勧めています。設定は、システム設定の一般にある日付と時刻から行います。 – Macで日付と時刻を自動的に設定する
  4. Microsoftは2024年9月16日をもって、Outlook.com、Hotmail.com、Live.comの個人用アカウントについて、ユーザー名とパスワードだけで接続する基本認証のサポートを終了しました。 – Keeping our Outlook Personal Email Users Safe: Reinforcing Our Commitment to Security
  5. JWTの仕様では、発行時刻をiat、有効期限をexp、使用開始時刻をnbfというクレームで表します。expの検証は現在時刻がexpより前であることを求め、nbfの検証は現在時刻がnbf以降であることを求めます。 – RFC7519: JSON Web Token
  6. Microsoftのアイデンティティプラットフォームは、発行時に60分から90分の範囲でランダムな値を既定の有効期間として割り当てています。平均は75分で、ばらつきを持たせることで更新要求が特定の時刻に集中するのを避けています。 – Access tokens in the Microsoft identity platform
  7. 仕様は時計のずれを見込んだ多少の猶予を認めていますが、その幅は数分を超えないものとされています。実装では30秒から60秒程度を採るものが多く、1時間のずれは吸収できません。 – 4. JWT Claims | RFCinfo
  8. Microsoftのワンタイムパスコードは用途によって有効期間が異なり、パスワードリセットの場面では5分、ゲストユーザーの認証では30分とされています。 – Email one-time passcode authentication – Microsoft Entra External ID
  9. 認証アプリが生成するコードもシステム時刻を元に計算されるため、端末の時刻がずれているとサーバー側の許容範囲から外れます。Microsoftのサポート回答でも、この点が失敗の要因として挙げられています。 – AD-B2C Custom Policy – Microsoft Authenticator TOTP valid for more than 30 seconds
  10. 公的に信頼されるTLS証明書の最長有効期間は長らく398日でしたが、CA/Browser Forumの決定により2026年3月15日から200日、2027年に100日、2029年には47日へと段階的に短縮されます。 – Digital Certificate Lifespans to Fall to 47 Days by 2029
  11. あるユーザーは、Exchangeと汎用のメール設定の両方を試し、アカウントを削除してやり直し、パスワードの変更、2要素認証の設定変更、アプリパスワードの発行まで行っても、アカウント名かパスワードを確認できないと言われ続けたと書いています。 – My Microsoft Email Account now refuses to connect to my Apple Mail app
  12. すでにアカウントを追加してあるMacでは動き続けるのに、いったん削除して追加し直そうとすると通らなくなる、という報告が複数のスレッドに残っています。 – Unable to add outlook.com email account to Apple Mail on Mac
  13. 自動設定を一度オフにして再びオンにすると、タイムサーバーとの同期が強制的に走ります。ターミナルからsudo sntp -sS time.apple.comを実行して手動で合わせることもできます。 – 【2026年最新版】Macのタイムゾーン・時刻設定の変更方法完全ガイド