Microsoft 365 应用和设备邮件:2026 年 12 月变更前的检查事项
识别通过 Exchange Online SMTP AUTH 基本身份验证发送邮件的应用和设备,比较受支持的发送方式,并在 2026 年 12 月默认设置变更前验证业务邮件。

在批准更改扫描仪、开票系统或报表应用之前,先确认它是否通过 Exchange Online 使用 SMTP AUTH 基本身份验证发送邮件。微软在 2026 年 12 月进行的变更影响的是这一特定依赖。组织使用 Microsoft 365,并不能说明每个应用如何发送邮件。
实际工作是找出受影响的发件方,确认可继续使用的受支持方式,并在更改正式配置前验证一封有代表性的业务邮件。这样,负责人或预算审批人就能据此判断需要开展哪些工作。
12 月底会发生什么变化
微软的SMTP AUTH 最新时间表表示,相关行为在 2026 年 12 月期间保持不变。到 12 月底,现有租户中的 SMTP AUTH 基本身份验证将默认禁用。管理员仍可在需要时启用它。这项默认设置变更与最终移除是两回事。
对于 2026 年 12 月之后创建的新租户,该功能将默认不可用,OAuth 将是受支持的身份验证方式。微软表示,将在 2027 年下半年公布最终移除日期。这是公布日期的时间窗口,并非移除日期本身。
此时间表针对 Exchange Online SMTP AUTH 基本身份验证。这并不意味着 SMTP 本身会停止使用,也不意味着所有 Microsoft 365 邮箱和设备都依赖同一种方式。修订后的时间表为准备工作留出了时间,但仍需评估一项具体的配置变更。
从业务邮件入手
针对每类重要邮件,请供应商或管理员确认实际发送路径。开票应用可能直接提交到 Exchange Online、使用本地中继,或通过供应商的服务发送。这些只是设想中的示例,各自需要不同的证据。仅凭发件人栏中的 Microsoft 365 地址无法确定发送方式。
建立一份简明清单,记录以下信息:
- 业务邮件:发送什么内容、何时需要发送,以及附件或正文中哪些内容不可缺少。
- 发件方和路径:应用或设备、实际发送服务以及身份验证方式。
- 收件人:组织内部人员、外部收件人,或两者都有。
- 系统负责人:负责该发件方及其供应商关系的人员。
- 后续选项:受支持的发送方式,以及尚未解决的兼容性或配置问题。
- 验证负责人:负责确认所需邮件已送达收件人的人员。
明确记录未知事项,并指定负责人跟进。这样可以区分已确认依赖基本身份验证的发件方,以及仍需单独调查的发件方。在采购或更改配置前,也能向供应商提出明确的问题。
根据收件人和托管环境选择发送方式
OAuth 客户端提交是一种可能的后续方式。微软的SMTP OAuth 文档介绍了相关身份验证支持,包括应用注册和令牌。具体应用或设备必须实现所需支持,租户配置也必须允许使用。仅称产品“支持 SMTP”过于笼统,不能据此确认兼容性。请向供应商核实具体型号或软件版本。
微软的应用和设备发送指南根据收件人范围和运行要求区分不同方式。客户端提交和符合条件的连接器中继可发送给内部及外部收件人。在该指南的比较中,高容量电子邮件(HVE)和 Direct Send 仅适用于内部收件人。若客户发票或提醒要发送到组织外部,这两种方式不适用。
连接器中继有自己的适用条件。它需要入站连接器,并通过证书或符合条件的静态公网 IP 地址进行身份验证,同时还需要可用的 25 端口。微软不允许通过此方式从 Azure 等第三方托管服务进行中继。因此,在将连接器中继视为选项前,必须先核实云托管应用的托管环境是否符合要求。
使用 Direct Send 也需要承担邮件服务器管理职责。其他发送服务,包括微软所述、可用于内部和外部邮件的 Azure Communication Services 替代方案,也需要单独评估兼容性和运行要求。收件人范围、托管环境和可获得的支持决定了哪些选项值得调查。检查受支持的选项后,再决定是否有充分理由更换硬件。
正式变更前验证邮件
明确由谁执行变更、由谁检查业务结果,以及变更后由谁处理故障。使用一封具有代表性的邮件,包含所需的发件人身份、正文和附件。跟踪邮件从提交到目标收件人收到的全过程;如果业务流程需要发送给外部收件人,也要验证外部送达。
身份验证成功只说明邮件发送过程中的一个环节正常。即使供应商确认支持,管理员也成功完成连接测试,仍需检查业务邮件是否确实送达。只有在依赖关系、兼容的发送方式和验证职责都明确后,才安排正式变更。
如果您需要评估应用或设备发件方的相关要求,我们可以通过邮件基础设施服务与您讨论范围。