术语 · Office 365 SMTP 设置

Office 365 SMTP 设置是什么？它们对应用邮件有什么影响？

Office 365 SMTP 详情并非一套通用主机和密码。Microsoft 文档列出了多种应用和设备模式，包括通过 smtp.office365.com 进行经身份验证的客户端提交、通过租户 MX 端点进行基于连接器的 SMTP 中继，以及向内部 Microsoft 365 收件人进行 Direct Send。它们在身份验证、TLS、端口、发件人身份、外部收件人支持、许可、限制和管理设置方面不同。请根据工作负载和信任边界选择模式，在适用客户端提交时使用 OAuth，严格限制 SMTP AUTH 的启用范围，测试精确的信封和 From 身份，并将中继受理与最终投递或收件箱送达率分开对待。

Office 365 SMTP 详情描述多种路径

Microsoft 365 和 Office 365 的文档区分了客户端 SMTP 提交、SMTP 中继和 Direct Send。客户端提交以 Exchange Online 邮箱身份进行验证，并通过 smtp.office365.com 发信。SMTP 中继把应用或设备视为组织的邮件服务器，并通过入站连接器对连接进行身份验证。Direct Send 以匿名方式向租户的 Microsoft 365 MX 端点提交发给组织内收件人的邮件。它们虽然使用相似的 SMTP 命令，但在运维上是不同的产品。在确定要使用哪条路径之前，不要从论坛上照搬主机名和端口。请先记录租户、接受域、管理员、工作负载、发件人身份、源网络、收件人范围、身份验证方式、TLS 策略、发送量和故障负责人。SMTP 传输既不能为发起邮件的业务事件授权，也不能确立收件人许可，更不能让应用队列具备持久性。

客户端 SMTP 提交设置

Microsoft 当前的设置指南将 smtp.office365.com 列为客户端提交的 DNS 名称，并说明不要用 IP 地址代替。它推荐使用 TCP 587 端口，在文档所述场景下允许使用 25 端口，并要求使用 TLS 1.2 或 TLS 1.3 且启用 STARTTLS。应用以一个已获许可的 Microsoft 365 或 Office 365 邮箱身份进行验证，并可在文档规定的限制内向内部和外部收件人发信。请将该邮箱地址作为明确的身份使用；当可见的 From 与之不同时，测试“代理发送”（Send As）权限。将凭据或令牌保存在服务器端的机密信息管理器中。账户登录成功并不能证明可见的 From 被允许、收件人有效，或者邮件会进入收件箱。客户端提交是一条以邮箱为范围的路径，因此用户被停用、许可证变更、条件访问决策以及 SMTP AUTH 设置，都可能让一个本身没有任何改动的应用中断发信。

使用 OAuth，并只在必要范围内启用 SMTP AUTH

Microsoft 建议客户端 SMTP 提交使用基于 OAuth 的新式身份验证。其 OAuth 文档定义了 SMTP.Send 作用域和 SASL XOAUTH2 格式，委托流程和面向应用的流程都需要进行 Microsoft Entra 注册并获得 Exchange 权限。请把访问令牌和刷新令牌当作机密信息，只申请必要的权限，验证租户与邮箱的绑定关系，轮换应用凭据，并移除不再使用的授权。Microsoft 还建议在 Exchange Online 组织层面禁用 SMTP AUTH，只为仍然需要它的邮箱启用。组织范围的设置和按邮箱的覆盖设置同时存在，并且邮箱设置可以优先生效。安全默认值会禁用 SMTP AUTH。不要仅仅为了保留某一台旧设备，就关闭整个租户的安全基线。当工作负载无法满足 OAuth 和 TLS 要求时，请优先考虑连接器、受支持的新式客户端、本地中继或其他有文档支持的服务。

客户端提交的限制会影响应用设计

Microsoft 当前的对比文档列出的客户端 SMTP 提交限流为每天 10,000 个收件人、每分钟 30 封邮件。请把这些视为当前可能变化、并可能与其他 Exchange Online 限制相互作用的服务限制。统计收件人数量，而不仅是邮件数量，并涵盖 To、Cc、Bcc、重试和扇出。把应用速率、租户公平性、并发、尝试次数和队列存留时间的控制设置在服务上限之下。共享邮箱路径可能在人工使用和自动化使用之间产生争用，而一个凭据被多个应用共用则会掩盖责任归属。请监控速率和收件人余量，但绝不要通过轮换邮箱或发件域名来规避限制。如果工作负载经常接近邮箱提交限制，请根据 Microsoft 当前的指南，评估连接器中继、适用于符合条件的内部流量的 High Volume Email、用于应用投递的 Azure Communication Services Email，或其他专门构建的传输方式。

基于连接器的 SMTP 中继设置

Microsoft 365 SMTP 中继使用的是租户的 MX 端点，而不是 smtp.office365.com，并通过一个入站连接器来识别组织的发信系统。Microsoft 建议使用 TLS 证书对连接器进行身份验证，公共静态 IP 地址是文档中记载的另一种身份识别方式。应用通过 TCP 25 端口连接，可以使用接受域中的地址发信，而无需为每个发件人配备已获许可的邮箱。这种模式适用于证书和网络归属都很稳定的受控邮件服务器、设备或网关。它需要更多的管理工作：连接器范围、证书生命周期、公网 IP 变更、反向 DNS、接受域策略、滥用防范以及黑名单监控。切勿建立开放中继。请限制网关接受哪些内部系统、租户、发件人、收件人和邮件类别。连接器能把连接识别为来自组织，但并不能验证任意的应用输入是否正当。

Direct Send 用于投递给内部收件人，而不是通用中继

Direct Send 以外部 SMTP 服务器的身份向租户的 MX 端点提交邮件，既不以邮箱身份验证，也不通过连接器验证。Microsoft 将其定位为向 Microsoft 365 或 Office 365 组织内的收件人投递，而不是发往任意外部地址的路径。设备或应用需要能够访问 TCP 25 端口，并应使用接受域中的发件人。由于从面向互联网的服务角度看，这条路径是匿名的，因此发件人信誉、DNS、源 IP 和反欺骗判定都很重要。不要把 Direct Send 网关暴露给不受信任的网络，也不要用它来绕过邮箱身份验证。请为未送达报告和支持责任建模，因为打印机或应用可能无法安全地接收退信。如果需要向外部投递，请在评估身份和发送量之后，选择客户端提交、连接器中继、Azure Communication Services Email 或其他受支持的方式。

把信封身份、可见 From 和身份验证分开看待

每条路径都携带 SMTP 信封发件人和收件人命令，以及 RFC 5322 可见邮件头。信封发件人决定传输层退信的去向，通常也是 SPF 所验证的身份；可见 From 决定读者看到的内容，也是 DMARC 的核心身份。OAuth 邮箱身份验证、连接器身份或基于源 IP 的接受，都不会自动为每一个自定义 From 域名建立 SPF、DKIM 或 DMARC 对齐。请在受控的已接收样本上，逐一核对确切的 MAIL FROM、From、Reply-To、DKIM d= 域名和选择器以及连接 IP。为相应域名发布一条有效的 SPF 策略，在支持的情况下配置 DKIM 签名，并评估 DMARC 对齐。不要为了修好某一台设备就添加第二条 SPF 记录或放宽组织的 DMARC 策略。在状态模型中，请把 Microsoft 受理、目标服务器接收、之后的退信、邮箱过滤、进入收件箱和用户操作分开。

建立持久可靠的应用边界

把 Microsoft 365 SMTP 放在经过授权的服务器工作进程或受控中继之后。在建立连接之前先持久化业务事件，包括稳定的幂等键、租户、邮件类别、模板版本、已批准的发件人和收件人、许可或必要性依据、抑制状态以及尝试历史。在生成 SMTP 命令之前，执行按租户划分的发件人和收件人规则。限制邮件大小、收件人扇出、附件和邮件头值。将令牌、密码、证书私钥和连接器管理权限存放在源代码、日志、分析系统、工单和提示词之外。设置有限的超时时间，并结合完整的增强诊断信息和 Microsoft 的指南，把 4xx 响应归为可进行有限次数重试的候选，把 5xx 响应视为该次尝试的永久失败。在 DATA 之后、最终回复之前断开连接，结果是不确定的；请保留该次尝试记录，在重新发送之前先进行核对。SMTP 不提供产品层面的“恰好一次”保证。

上线前测试配置和故障模式

使用专用的受控收件人和与生产环境一致的源网络。验证 DNS 解析、端口可达性、STARTTLS 协商、证书主机名和证书链、OAuth 令牌获取和作用域、SMTP AUTH 的组织和邮箱设置、Send As 授权、连接器匹配、接受域以及 MX 端点的选择。发送纯文本、HTML、附件、Unicode、退信以及预期发送量的样本。记录原始邮件头、可信的 Authentication-Results、SMTP 回复、跟踪标识符和邮件跟踪证据，但不要保留客户内容。负面测试应覆盖：已撤销的令牌、过期的连接器证书、变更后的公网 IP、邮箱 SMTP AUTH 被禁用、安全默认值、无效的 From、通过 Direct Send 发往外部收件人、每分钟和收件人数量限制、暂时延迟、永久拒收，以及 DATA 前后的连接中断。演练暂停工作负载和迁移持久化任务的过程，同时不绕过永久性的策略或收件人失败。

使用当前 Microsoft 指南并测试您的租户

Microsoft 365 SMTP 配置取决于租户的策略、身份、连接器和网络环境。在依赖所选路径发送生产邮件前，请使用当前 Microsoft Learn 文档，并在您的租户中进行测试。

常见问题

Microsoft 365 客户端 SMTP 的主机名是什么？

Microsoft 目前为经过身份验证的客户端提交记录的主机名是 smtp.office365.com，并说明应使用该 DNS 名称，而不是固定的服务 IP 地址。

客户端 SMTP 提交应使用哪个端口？

Microsoft 推荐使用 TCP 587 端口，并在受支持的客户端提交场景中记录了 25 端口，要求使用 STARTTLS 以及 TLS 1.2 或 TLS 1.3。

Microsoft 365 客户端提交支持 OAuth 吗？

支持。Microsoft 推荐使用 OAuth，并记录了 SMTP.Send 作用域和 SASL XOAUTH2。租户注册、权限、令牌保管和邮箱绑定仍然需要仔细配置。

SMTP 中继和 Direct Send 有什么区别？

连接器中继会对组织的邮件系统进行身份验证，并且可以支持外部收件人。Direct Send 不经过该连接器，直接使用租户的 MX 端点，面向的是内部收件人。

应该为每个邮箱都启用 SMTP AUTH 吗？

不应该。Microsoft 建议在组织范围内禁用它，只为仍然需要它的邮箱启用，并优先使用新式身份验证和受支持的替代方案。

Office 365 SMTP 受理了邮件，是否就代表进入了收件箱？

不是。受理只是一个有限范围内的传输结果。之后的投递、未送达、收件方过滤、邮箱文件夹归属以及用户互动，仍然是各自独立的证据。

应用可以使用 465 端口进行 Microsoft 客户端提交吗？

Microsoft 当前的指南指出，默认使用 465 端口的设备不支持这条 Microsoft 365 路径在客户端提交时所要求的 TLS 版本。

我应在哪里验证 Microsoft 365 SMTP 配置？

在依赖所选路径发送生产邮件前，请使用当前 Microsoft Learn 文档，并在您的租户中进行测试。

参考来源

继续学习

如何评估 SMTP 中继服务从提交安全、身份验证、队列、重试行为、限制、投递事件、抑制、隔离和迁移适配性等方面评估 SMTP 中继服务。Google SMTP 中继服务评估指南从授权模型、TLS、发件人身份、配额、错误处理、身份验证、可观测性和迁移风险等方面评估 Google Workspace SMTP 中继。SMTP 邮件协议：应用邮件是如何传输的了解 SMTP 提交、中继、信封、响应码、TLS、重试和邮件内容如何影响应用邮件的工作流程。SMTP 端口 25、465 和 587 实用指南根据角色和 TLS 模式选择正确的 SMTP 端口，然后诊断连接、握手、身份验证和邮件受理方面的故障。如何评估邮件送达率服务从范围、证据、身份验证、反馈环、抑制列表、隐私、可迁移性和运维契合度等方面评估邮件送达率服务。