我之前帮几个用户排查过类似的问题，刚好能结合Azure最新的安全规则给你拆解下：

首先，你遇到的错误根源是什么？ #

那个535, b'5.7.139 Authentication unsuccessful...'错误，大概率是Azure AD最近强化了**遗留身份验证（Legacy Authentication）**的限制——安全默认值或者租户级的条件访问策略，现在默认会拦截SMTP基本认证这类旧协议，哪怕你开了2FA和应用密码也没用，因为应用密码本身就属于遗留认证的范畴，Azure现在更倾向于强制使用现代认证方式。

禁用租户默认安全设置的风险 #

你提到禁用组织默认安全设置后恢复了功能，但这确实不是最优解，因为这些默认设置是Azure为了租户安全预设的核心防护，禁用后会带来这些隐患：

• 全局关闭了MFA强制要求：如果租户里其他账号没单独开MFA，很容易被暴力破解
• 允许所有遗留认证协议：除了SMTP，像POP3、IMAP基本认证这些也会被放开，增加账号泄露、邮件被篡改的风险
• 弱化了管理员账号的保护：安全默认值本来会对管理员账号强制更严格的安全规则，禁用后管理员账号更容易成为攻击目标

最优替代方案 #

1. 迁移到现代认证（推荐） #

Azure现在主推用Microsoft Graph API或者SMTP over OAuth 2.0来发送邮件，完全不需要依赖应用密码和SMTP基本认证：

• 对于Web应用，你可以注册一个Azure AD应用，授予Mail.Send的应用权限（不需要用户交互），然后用SDK调用Graph API发送邮件，这是最符合Azure安全规范的方式
• 如果你的邮件客户端支持，也可以配置SMTP使用OAuth认证，现在Outlook、Thunderbird等都支持这种方式

2. 针对性允许遗留认证（临时过渡方案） #

如果暂时没法迁移到现代认证，别全局禁用安全默认值，而是给你的邮件账号单独开例外：

• 登录Azure Portal，进入Azure AD > 安全 > 条件访问
• 创建一个新的条件访问策略，设置“阻止遗留身份验证”，然后在“排除”里添加你的邮件账号
• 或者直接在安全默认值的设置里，针对SMTP协议给特定账号放行（部分租户支持细粒度配置）

3. 强化账号监控 #

如果必须用应用密码，一定要确保密码是强密码，定期轮换，并且在Azure AD > 日志 > 登录日志里监控该账号的登录活动，一旦出现异常登录及时处理

额外排查步骤 #

你可以去Azure AD的登录日志里找失败的认证记录，里面会明确标注是被安全默认值拦截，还是某个条件访问策略拒绝的，这样能更精准地调整配置。

内容的提问来源于stack exchange，提问作者Roosh