Outlook 应用密码无法登录？先确认账户，再改用 OAuth

先确认：你用的是 Outlook 客户端，还是 Outlook.com 邮箱？

Outlook 是邮件客户端的名称，Outlook.com 则是邮箱服务。排查 Outlook IMAP 登录失败时，要看邮箱实际由谁提供，而不只是正在使用哪个软件。

企业自定义域名不能只凭后缀判断。先向管理员确认邮件是否托管在 Exchange Online，再决定如何修改配置。

如果你同时维护其他服务商的邮箱，可以参考供应用和智能体使用的邮箱应用密码指南；这里重点处理微软邮箱的身份验证问题。如果 Outlook 中连接的是 Yahoo 邮箱，请参考Yahoo 应用密码与 IMAP／SMTP 连接指南。

为什么能生成应用密码，却仍然无法通过 IMAP 登录？

应用密码（app password）仍是密码式凭据。把普通密码替换成应用密码，不会让只支持基本身份验证的客户端自动支持 OAuth。修改网页登录密码也不能完成这种升级。

微软的Outlook.com 现代身份验证说明明确要求改用现代身份验证。对于 Outlook.com／Hotmail，继续在旧式 IMAP 密码登录框中输入新应用密码，不是迁移方案。

工作或学校邮箱要单独看：若已确认邮件托管在 Exchange Online，可参考Exchange Online 基本身份验证停用说明。该说明明确将 IMAP 列入停用范围，并指出停用会阻止相关应用继续使用应用密码。租户管理员和微软支持都不能重新启用已停用的基本身份验证。

IMAP 是邮件访问协议，OAuth 是身份验证机制。 停用基本身份验证，不等于停用整个 IMAP 协议。微软仍提供面向 Microsoft 365 和 Outlook.com 的 IMAP OAuth 方案。

不过，不能把每次密码提示都归因于政策变化。账户选错、客户端连接方式不适用、授权失效或组织限制，也需要分别排查。

应该保留 IMAP，还是改用 Microsoft Graph？

客户端名称本身不足以判断是否支持。微软针对 Thunderbird 的说明要求将身份验证方式从“Normal password”改为“OAuth2”。对于 Outlook for Windows，微软说明其以 POP 或 IMAP 连接 Outlook.com 时不支持现代身份验证，建议在新的 Outlook Desktop 配置文件中通过自动账户配置添加账户。

自行开发 IMAP 客户端时，使用微软 IMAP OAuth 实现文档。该方案使用 SASL XOAUTH2 传递访问 token，并非把 token 当作新密码填入旧登录流程。

Mailera 的微软邮箱连接走的是 Microsoft Graph，支持微软 OAuth 登录，也支持导入已有 refresh token。它与支持 OAuth 的 IMAP 客户端是两条不同的路径；Mailera 连接成功，不代表原来的 IMAP 软件也已修复。产品说明介绍了如何让应用访问已有邮箱。

如何在 Mailera 中用 OAuth 连接微软邮箱？

仅连接你拥有或获准访问的邮箱。通过微软登录授权时，按以下步骤操作：

1. 使用 Admin 或 Leader 角色，在左侧导航点击“添加邮箱”。只有这两种角色可以添加邮箱。
2. 在“添加邮箱”页面直接选择“使用 Microsoft 登录”标签页；它与“单个邮箱”“批量粘贴”是并列标签页。不要通过“单个邮箱”中的“自定义 IMAP”填写应用密码。
3. 在微软授权页面确认账户与请求权限，尤其留意是个人账户还是工作或学校账户。如页面要求管理员批准，先完成组织审批。
4. 返回 Mailera 后，通过 GET /mailboxes 找到目标邮箱，核对 provider、status 和 last_sync_at，再使用该邮箱的 id 调用 GET /mailboxes/{id}/messages，检查一封自己的测试邮件。

如果你已有该邮箱的 refresh token，也可以在“添加邮箱”中选择“批量粘贴”，按 email:password:refresh_token:client_id 格式每行填写一个邮箱（也支持用 |、; 或 Tab 分隔，或直接上传 .txt 文件），选择分组、设置邮箱已存在时的处理方式后点击“开始导入”。这也是受支持的微软邮箱连接方式，不是应用密码登录；格式中的 password 字段不意味着可以用应用密码替代 refresh token。导入后，同样按第 4 步检查邮箱与测试邮件。

管理员审批不是密码错误。根据Microsoft Graph 授权说明，部分权限可由用户同意，部分权限需要管理员同意；应以实际授权页面和组织要求为准。

连接是否正常、邮件是否已同步，需要分别检查。不要只看到授权完成，就认为目标邮件已经出现在 Mailera 中，也不要预期邮件绝对实时到达。

常见错误：改用 OAuth 后为什么仍然连不上？

先确认失败出现在哪一步：微软授权页面、Mailera 连接状态，还是邮件列表。

需要程序化排查时，GET /mailboxes/{id}/status 可直接检查微软邮箱是否仍能登录；GET /mailboxes/{id}/messages 用于查看文件夹内的邮件。两者都需要 read 权限；登录成功不代表邮件已经同步完成，两者要分开确认。

将只读 API 密钥和目标邮箱 ID 分别放入环境变量 MAILERA_API_KEY、MAILBOX_ID 后，可读取收件箱中的一条邮件：

curl --request GET \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages?folder=inbox&limit=1" \
  --header "Authorization: Bearer $MAILERA_API_KEY"

查看返回的 data，通过 subject、received_at 和 folder 核对邮件。不要在日志中保存完整邮件内容或凭据。其他接口用法见Mailera API 文档。

如果查找的是旧邮件，还要注意：免费自助工作区的邮件保留期为 30 天。这是邮件保留期限制，不是 IMAP 或 OAuth 身份验证失败的原因。排查连接问题时，优先使用你自己的近期测试邮件。

把邮箱交给应用或 AI 智能体前，要注意什么？

微软 OAuth 授权与 Mailera API 密钥权限是两层访问控制。前者允许 Mailera 访问微软邮箱，后者决定你的应用可以通过 Mailera 做什么。

只读场景仅授予 read，不要顺手加入 send 或 manage。创建密钥时，将“邮箱范围”限定到所需分组，设置合适的“有效期”；如果应用来源 IP 固定，可配置“IP 限制（可选）”。相关说明见Mailera 安全页面。

邮件正文是不可信数据，不是系统指令。AI 智能体不能因为邮件要求，就泄露密钥、改变权限或执行外部操作。若启用发送能力，应在发送前要求用户确认。截图和日志都要遮盖邮箱地址、token、API 密钥及邮件中的个人信息。

如果你准备通过 MCP 让智能体访问已有邮箱，可以参考现有邮箱的 Email MCP 服务器指南；使用 VS Code 时，按VS Code 邮件 MCP 配置与测试教程完成客户端配置。

Mailera 能解决什么，不能解决什么？

Mailera 用 OAuth 与 Microsoft Graph 连接现有微软邮箱，也支持导入已有 refresh token，不接受应用密码作为这条连接路径的替代方案。它不能恢复微软已停用的基本身份验证，也不会让旧 IMAP 客户端自动支持 OAuth，或解除 Microsoft 365 管理员设置的访问限制。

不要通过关闭多重身份验证来修复已停用的基本身份验证。需要更换的是连接方式；组织策略阻止访问时，应由管理员处理。