この記事の目的：メールソフトで使われる通常パスワード、アプリパスワード、OAuthを同じ「パスワード設定」として扱わず、認証方式の違いから接続障害を切り分けます。
通常パスワード認証
従来型のメール接続では、メールアドレス/ユーザー名とパスワードをメールソフトがサーバーへ提示する方式が広く使われてきました。しかし現在は、サービス側がBasic Authenticationを廃止・制限し、OAuth等のModern Authenticationを要求するケースがあります。
アプリパスワード
アプリパスワードは、二段階認証を利用しているアカウントで、通常の対話型認証に対応しないアプリへ専用の資格情報を発行する仕組みです。すべてのサービス・契約・管理ポリシーで利用できるわけではなく、OAuthの代替として常に使えるものでもありません。
OAuth
OAuth対応メールソフトでは、サービス提供者の認証画面でサインインし、アプリへアクセストークン等を用いた限定的なアクセスを許可します。メールソフトへ通常パスワードを恒久保存する方式とは異なります。多要素認証や条件付きアクセス等の組織ポリシーとも関係します。
「パスワードは合っているのに失敗する」理由
認証方式がサービス側ポリシーと合っていない場合、正しい通常パスワードを何度入力しても接続できません。Outlook等で突然認証画面が繰り返される場合は、パスワードだけでなく、アカウント種別、クライアントのOAuth対応、MFA、管理者ポリシー、サービス側のBasic認証可否を確認します。
再認証が必要になる場面
パスワード変更、MFA設定変更、管理者によるセッション失効、トークン失効、アプリ権限変更などで再認証が必要になる場合があります。保存資格情報を無闇に削除する前に、どの認証方式で接続しているかを把握します。
MicrosoftとGoogleで同じとは限らない
Microsoft 365、Google Workspace、Yahoo等ではサポートする認証方式、アプリパスワードの条件、管理者制御が異なります。「IMAPなら設定は共通」と考えず、利用サービスの最新公式資料を確認します。
現場での確認ポイント
- メールサービスとアカウント種別を特定する
- MFAが有効か確認する
- メールソフトがOAuthに対応しているか確認する
- アプリパスワードがその環境で許可されているか確認する
- 管理者ポリシーや認証ログで拒否理由を確認する
一次資料
関連技術
OutlookでIMAP送受信できない場合はOutlook切り分け記事、ドメインメールの到達性やなりすまし対策はDNS/SPF/DKIM/DMARCの記事と分けて確認します。