您已检查 SPF 和 DKIM 记录，确认发送域名看起来干净，并启动了营销活动。随后，应用程序在第一封邮件离开您的系统之前返回了身份验证错误。DNS 配置不一定有问题。您的发送应用程序可能未通过出站 SMTP 服务器要求的客户端登录。
这一点回答了什么是 SMTP 身份验证这一实际问题。SMTP AUTH 证明客户端、应用程序或用户有权通过服务器提交邮件。SPF、DKIM 和 DMARC 解决的是另一个身份问题，即接收方服务商是否应信任与邮件相关联的域名。可靠的邮件送达率取决于这两个层面，以及发送前对邮件列表进行仔细的清洁。
邮件投递的隐形守门人
营销团队可能花费数天时间检查发件人信誉、域名对齐和邮件内容，最后却发现其 CRM 无法向出站邮件服务器进行身份验证。由于提交服务器首先拒绝了连接，营销活动根本无法到达收件人的基础设施。
这正是 SMTP AUTH 的作用。它是应用程序与接受出站邮件的邮件服务器之间的守门人。客户端识别一种身份验证机制，与服务器完成交互，然后获得提交邮件的权限。没有这项权限，即使邮件编写正确、域名记录发布正确，也暂时无济于事。
两项身份检查，而非一项
邮件投递涉及两个不同的问题：
- 此客户端能否通过此服务器提交邮件？
- 收件人是否应当信任此邮件所代表的发件人身份？
SMTP AUTH 解决第一个问题。SPF、DKIM 和 DMARC 解决第二个问题。CRM 可能拥有有效凭据，却使用一个缺少对齐身份验证记录的域名发信。反过来，域名可以发布强健的记录，但应用程序使用了过期密码、已禁用的方法，或某个拒绝为该账户中继邮件的服务器。
操作规则： 按顺序调试发送路径。首先确认客户端能够建立安全且经过身份验证的提交会话。然后确认域名级别的身份验证和收件人端的策略。
SMTP AUTH 背后的标准是 RFC 4954，该标准将 SMTP 身份验证正式定义为一种基于 SASL 构建的服务扩展。它允许服务器公布所支持的机制，并让客户端选择其中一种，而无需更改 SMTP 核心的邮件传输命令。这种设计至今仍支撑着企业邮件系统和发送平台中的身份验证提交。
为什么营销人员会遇到此类故障
此错误通常出现在基础设施变更之后，而不是文案或定向策略变更之后。服务提供商可能会禁用旧版身份验证方法。管理员可能会关闭某个账户的 SMTP AUTH。安全策略可能要求使用加密提交。防火墙可能允许服务器之间的流量，却阻止营销应用程序所使用的端口。
因此，“密码是正确的”并不足以完成诊断。服务器可能拒绝的是身份验证方法、连接安全性、账户的中继权限，或发送客户端的配置。应将 SMTP AUTH 视为协议级控制，而不是一个表单字段。
理解 SMTP AUTH 握手
SMTP AUTH 是一种协商式交换。客户端不会发送用户名，然后希望服务器接受它。服务器会先确认自己支持的内容，随后客户端选择兼容的机制并开始身份验证流程。
协议序列
该交换通常按以下顺序进行：
- 客户端建立连接。 对于经过身份验证的提交，应用程序通常会通过指定的提交服务进行连接，并在暴露凭据前协商传输安全性。
- 客户端发送 EHLO。 这条扩展问候消息会告知服务器客户端理解哪些 SMTP 功能。
- 服务器公布功能。 响应中可能包含
250-AUTH行，列出支持的 SASL 机制。客户端必须选择服务器提供的机制。 - 客户端发送 AUTH。 根据 RFC 4954 的 AUTH 命令规范，该命令将选定的机制作为第一个参数。
- 双方完成交换。 根据所使用的机制，服务器可能会发出质询，客户端则使用所需的身份验证数据进行响应。交换过程中可以使用 Base64 编码表示凭据，但编码并不等于加密。TLS 必须保护该会话。
- 服务器接受或拒绝会话。 身份验证成功通常会返回
235。失败的尝试通常会返回535，但诊断详情会因提供商而异。
重要的一点是，SMTP AUTH 发生在客户端提交邮件信封和内容之前。身份验证完成后，应用程序便可继续执行 MAIL FROM、RCPT TO 和 DATA 等命令，但仍须遵守服务器的中继和策略控制。
响应告诉你的信息
缺少 AUTH 功能可能表示客户端连接到了错误的服务、使用了不受支持的端口，或联系的是不提供身份验证提交功能的服务器。535 响应可能表示凭据无效、账户被阻止、身份验证方法已禁用，或提供商拒绝了旧式登录行为。
应用程序日志应记录服务器的响应代码和协商后的安全状态，同时避免记录密码和令牌。在调查一封已被接受但后来遭到过滤的邮件时，团队还可以免费分析邮件标头，检查接收系统记录的身份验证结果。
SMTP AUTH 也不能替代账户安全措施。如果邮箱或服务账户使用多因素身份验证，请查看提供商支持的流程，不要假设普通密码一定有效。Finchum Fixes IT 的 2FA 指南介绍了第二重身份验证因素为何会改变登录模式，可帮助你了解相关背景。
对于负责清理为这些系统提供收件人数据的团队，BillionVerify 是一项专业的邮箱验证服务，旨在解决一个问题：错误的邮箱数据会让企业蒙受损失。它解决的是列表质量问题，而不是 SMTP 登录本身。
SMTP 身份验证 vs 发件人身份验证
最贴切的类比是员工徽章与公司信笺抬头的区别。
SMTP AUTH 就像徽章。 它告诉外发邮件服务器，该客户端或账户有权提交邮件。SPF、DKIM 和 DMARC 则像信笺抬头和验证标记。 它们帮助接收方评估邮件是否代表显示给收件人的域名。
徽章检查成功，并不意味着可疑的信笺抬头值得信任。同样，完善的域名记录也不会授权应用程序将邮件注入服务器的队列。
| 功能 | 客户端提交（SMTP AUTH） | 域名验证（SPF/DKIM/DMARC） |
|---|---|---|
| 主要问题 | 此客户端是否获准提交邮件？ | 收件人是否应信任此域名身份？ |
| 运行位置 | 发送客户端与外发服务器之间 | 邮件、DNS 记录与接收方之间 |
| 主要组件 | EHLO、已公布的 AUTH 机制、SASL 交换、转发权限 | SPF 授权、DKIM 签名验证、DMARC 对齐与策略 |
| 典型故障 | 身份验证拒绝、账户已禁用、不支持的方法 | 欺骗失败、未对齐、基于策略的过滤 |
| 成功后的影响 | 服务器可能接受邮件并进行后续投递 | 收件人可以在过滤决策中使用域名身份信号 |
每一层能证明什么
SPF 为域名授权指定的发送 IP 地址。DKIM 附加加密签名，使接收系统能够检查已签名的邮件内容和域名签名是否有效。DMARC 将这些结果与可见的 From 域关联起来，并提供处理未通过对齐检查邮件的策略。这些区别在此 SPF、DKIM 和 DMARC 对比中得到了清晰总结。
SMTP AUTH 不会发布任何域名指令，也不保证收件人会将邮件放入收件箱。它只能确认发送服务已接受该客户端作为获授权的提交者。
发布记录不等于执行策略
从运营角度看，拥有记录与执行策略之间的区别非常重要。根据 DMARC Guard 的邮件身份验证研究，一项覆盖 550 万个域名 的 2026 年测量显示，SPF 的发布率为 56.0%，DMARC 为 30.4%，DKIM 为 22.7%。同一来源的另一项涵盖 排名前 10,000 个域名 的基准测试显示，SPF 发布率达到 84.5%，DMARC 发布率为 76.6%，而采用隔离或拒绝策略的 DMARC 执行率为 54.0%。
实际经验很简单。域名可能看起来已经完成配置，但实际上仍处于仅监控模式。使用 DMARC 检查工具检查策略和对齐情况，但要单独排查 SMTP 凭据问题。两种工具互不替代。
安全提交的端口和协议
凭据绝不应通过未受保护的客户端提交会话传输。因此，SMTP AUTH 应与传输加密以及专用于消息提交的端口配合使用，而不应与不受限制的中继路径搭配。
标准定义的提交端口是 587，通常与 STARTTLS 配合使用，详见这篇 SMTP 身份验证端口概览。客户端建立 SMTP 会话，接收服务器的功能信息，请求升级到 TLS，然后在受保护的连接中执行身份验证。
选择正确的端点
端口 25 主要用于服务器之间的中继。对于使用用户凭据提交邮件的应用程序、CRM 或营销平台来说，它并不是通常的选择。许多网络会限制该端口，因为开放中继滥用和遭入侵的主机已使不受限制的出站 SMTP 成为安全问题。
端口 465 使用隐式 TLS，这意味着连接从一开始就经过加密。一些服务提供商和应用程序仍然要求使用该端口，但配置必须与服务器的预期相匹配。如果客户端在隐式 TLS 端点上假定使用 STARTTLS，或者在服务器预期先发送明文问候语再升级连接的情况下假定使用隐式 TLS，身份验证就会在开始前失败。
| 连接类型 | 典型用途 | 安全要求 |
|---|---|---|
| 端口 25 | 服务器之间的中继 | 不是常规的经身份验证的客户端提交路径 |
| 端口 587 | 消息提交 | 通常会在 SMTP AUTH 之前协商 STARTTLS |
| 端口 465 | 必要时用于提交 | 连接建立时即开始隐式 TLS |
防止暴露的配置检查
在测试凭据之前，请确认应用程序的端点、端口、加密模式和身份验证机制与服务提供商的文档一致。端口可能可以访问，但 TLS 协商仍可能失败。同样，服务器可以公布 AUTH 功能，却因中继权限或租户策略禁止提交而拒绝该账户。
MX 记录验证工具有助于识别负责接收某个域名邮件的邮件服务器，但 MX 数据不能替代出站服务提供商提供的提交端点。接收基础设施和经过身份验证的发送基础设施可能是独立的服务。
安全边界： 不要通过禁用 TLS 来“修复”身份验证失败。这可能暴露凭据和邮件流量，同时无法解决潜在的兼容性或策略问题。
对于高容量系统而言，API 在运维上可能比维护频繁交互的 SMTP 会话更简单，但当应用程序已经支持 SMTP 且服务提供商提供稳定的提交服务时，SMTP 仍然很有用。选择应依据集成需求、可观测性和安全控制，而不是惯例。
旧版身份验证弃用的影响
即使密码没有更改，邮件发送工作流也可能停止进行身份验证。服务提供商正在用 OAuth 和其他授权流程取代 Basic Authentication。Basic Authentication 会直接发送用户名和密码，而 OAuth 等流程允许管理员控制令牌、权限范围、同意和撤销。
Microsoft 宣布的计划指出，Basic Authentication 的行为预计将在 2026 年 12 月 前保持不变。此后，现有租户预计将默认禁用该功能，而之后创建的新租户预计将使用 OAuth 作为受支持的方法。Microsoft 计划在 2027 年下半年 宣布最终移除日期。这些预计里程碑见于 Microsoft Exchange Online SMTP AUTH 弃用时间表。
为什么有效密码仍会失败
服务提供商可能会在检查密码之前拒绝身份验证方法。租户管理员也可能已为该邮箱禁用 SMTP AUTH，或者应用程序只提供 LOGIN 或 PLAIN，而服务要求基于令牌的流程。因此，从一个邮箱进行成功的登录测试，并不能确认每个发送集成都能继续正常工作。
Microsoft 早期的通知称，受影响的 Basic Authentication 路径将从 2026 年 3 月 1 日 开始分阶段拒绝，并于 2026 年 4 月 30 日 完全关闭，具体信息见这份 SMTP AUTH 迁移指南。服务提供商的时间表和租户策略可能发生变化，因此请核实每个环境的当前状态，不要把旧的实施日期当作保证。
实用的迁移计划
盘点所有通过该租户提交邮件的系统，包括 CRM 工作流、计费应用程序、监控工具、表单和脚本。为每个系统记录账户、端点、端口、加密模式、身份验证机制和负责人。将支持 OAuth 的集成与需要替换或采用已批准应用专用密码方案的集成分开。
在更改生产发送流程之前，先在受控环境中测试新流程。检查令牌过期、同意要求、错误处理和访问撤销。同时确认身份验证成功后，工作流仍能正确处理服务提供商的响应。即使存储的密码仍然有效，不支持 OAuth 的连接器也可能在营销活动期间失败。
验证登录之外的邮件送达率
对出站服务器进行身份验证可以证明提交权限，但不能证明收件人邮箱存在、收件人域名接受发送到该地址的邮件，也不能证明邮件能够避开过滤。
发送前验证流程始于 MX 查询。MX 记录用于标识负责接收某个域名邮件的邮件服务器。正如这篇关于邮箱验证工作原理的概述所述，没有 MX 记录的域名无法接收邮件。随后，验证服务可以通过 SMTP 会话探测收件人服务器，以评估该地址是否看起来能够正常送达。
验证流程实际检查的内容
服务无需发送营销邮件即可获取有用信息。它可以识别收件人域名的 MX 主机，打开 SMTP 会话，并询问服务器是否会接受指定的收件人。即使服务器返回肯定响应，结果仍可能存在歧义，因为某些服务器会接受该域名下所有地址的邮件。
这正是全收件检测发挥作用的地方。验证器会向同一个 MX 主机发送第二个测试地址。如果服务器连随机地址也接受，则该域名会被归类为全收件域名，而不会将其视为原始邮箱存在的证据，具体流程可参考这篇全收件检测工作流。
实用区分： “服务器已接受”与“已确认是某个特定邮箱”并不总是同一结果。
因此，验证最适合作为风险分类系统，而不是简单的有效或无效开关。在营销活动造成硬退信之前，营销运营团队可以将可能正常送达的地址与未知地址、全收件地址、一次性地址、基于角色的地址或其他高风险记录区分开来。
BillionVerify 邮件送达率检查工具可以作为团队评估的工具之一，融入发送前审核，用于检查地址和发送路径。运营目标不仅是登录成功：减少无效收件人、维护发件人信誉，并为营销活动提供更清洁的受众。
构建具有韧性的发送基础设施
具有韧性的发送系统会将身份验证视为分层控制，而不是单一复选框。客户端必须安全地向出站服务进行身份验证。可见的发件人域名必须通过一致的身份检查。收件人数据必须足够新，以避免营销活动产生不必要的退信。
从基础设施审计开始
绘制从应用程序到收件人的完整路径。针对每个发送工作流，记录提交服务商、身份验证方式、加密要求、账户所有者和备用行为。这份清单通常会暴露出仍依赖密码或旧版 SMTP 设置的弃用集成。
然后，有意测试各种故障模式：
- **提交失败：**确认客户端能够访问预期端点、协商 TLS、看到预期的 AUTH 能力，并收到成功的身份验证响应。
- **域名失败：**验证 From 地址中显示域名的 SPF 授权、DKIM 签名和 DMARC 对齐。
- **数据失败：**在新地址和导入地址进入营销活动或销售序列之前，验证这些地址。
- **信誉失败：**使用 IP 信誉检查工具监控退信、投诉、黑名单信号以及接收行为的突然变化。
RFC 4954 标准提供了协议基础，但仅符合标准并不能保证运营韧性。服务商可能会施加租户规则、禁用某些机制，或更改身份验证要求。
将清洁纳入工作流
不要等到列表规模变大或营销活动即将安排时才开始。应在注册、导入、CRM 同步以及大型发送之前加入验证。实时检查可以阻止明显存在风险的地址进入数据库，而批量审查则可以识别销售和营销团队积累的过时记录。
最佳工作流还应保留结果及其原因。“由于 catch-all 而未知”应区别于“邮箱拒绝”或“域名没有接收服务器”。通过细分，团队可以决定是抑制、审查，还是谨慎测试某个地址，而不是将每条不确定记录都视为安全。
分层计划还需要明确责任归属。基础设施团队应管理 OAuth 迁移和 TLS 策略。营销运营团队应维护发送域名对齐和抑制规则。数据团队应定义验证状态的处理方式。如果没有明确的责任归属，每个团队都会以为另一个团队正在保护发送路径。
这段视频以可视化方式解释了相关的基础设施概念：
核心经验很实际：SMTP AUTH 负责将邮件送入出站队列，而域名身份验证和收件人验证则决定整个邮件送达系统是否有理由信任它。在监控中保持这些控制彼此独立，但要在运营流程中将它们连接起来。
BillionVerify 提供邮箱验证，用于在收件人数据进入营销活动、工作流和出站序列之前进行检查。使用它将 SMTP 级验证、MX 和 catch-all 信号以及送达率审查连接到发送前流程中，然后访问 BillionVerify，为你的团队评估这一工作流。