SMTP身份验证和 SPF, DKIM 和 DMARC 两种登录方式不可互换。 SMTP AUTH 向SMTP服务器验证客户端的身份。 SPF根据域的信封策略评估发送主机， DKIM验证消息签名， DMARC评估相对于可见发件人的对齐域身份验证。成功的帐户登录可以与下游DMARC失败共存，并且入站 Internet 邮件不需要对您的提交帐户进行身份验证。
找到客户端-服务器关系
RFC 4954 定义了 AUTH 扩展及其对 SASL 机制的使用。服务器的授权策略决定经过身份验证的客户端可以执行的操作。知道经过身份验证的帐户名并不会自动授权每个可能的信封或可见的发件人地址。提交服务通常应用额外的发件人、中继和组织限制。
RFC 6409 区分消息提交和中继。在更改凭据或DNS之前确定应用程序正在使用哪个服务。连接到提供商的经过身份验证的提交服务的设备与将 Internet 邮件传送到您域的MX的远程邮件服务器具有不同的关系。不要尝试通过向外部发件人提供邮箱密码来修复普通的入站身份验证失败。
跟踪下游领域证据
SPF根据RFC 7208检查连接主机和相关信封身份。 DKIM验证使用 选择器 以及签名中的签名域，以查找公钥材料并验证RFC 6376下涵盖的内容。 DMARC要求传递域和可见的发件人域之间存在适当的关系 RFC 9989.
应用程序可以成功验证供应商帐户，然后使用未对齐的退回域和未对齐的DKIM签名域进行发送。下游SPF和DKIM可能都通过，而DMARC失败。相反，正确配置的域可以在服务器之间传递的邮件上传递DMARC而无需在面向接收者的跃点上进行SMTP AUTH。帐户凭据和域授权必须在各自的边界进行调查。
使用证据而不暴露秘密
对于登录失败，记录服务端点、安全传输状态、公布的方法和完整错误，不包括凭据和令牌。对于登录后发件人拒绝，请捕获允许的发件人策略和拒绝的命令。对于下游故障，获取可信接收器结果、信封信息、 DKIM d 和 s 值以及可见的 From 域。避免将身份验证有效负载复制到票证或文章示例中。
比较两个假设结果
情况 A：客户端通过提交服务的身份验证并被允许发送，但最终接收者报告了vendor.example的SPF通行证和d=vendor.example的DKIM通行证，而 From 使用了brand.example 。假设适用的DMARC策略并且没有未解决的评估错误，则两个域都不会对齐，并且消息会失败DMARC 。其他密码无法更改这些域关系。
情况 B：服务器将普通入站邮件传送到收件人MX而该跃点上没有SMTP AUTH。受信任的接收者报告有效的 DKIM签名 与d=brand.example匹配 From= brand.example 。通过适用的策略并且没有未解决的评估错误，一致的签名可以提供DMARC通行证。这不会建立安全内容、收件箱放置或执行请求的业务操作的权限。这两种情况都是虚构的比较；未使用凭据、提供商登录或加密测试。
修复负责的配置
如果 AUTH 失败，请遵循提供商当前支持的身份验证方法和传输要求。不要仅仅因为旧文章提到过时的机制就启用它。如果经过身份验证的帐户缺乏使用地址的权限，请通过正常管理流程修复授权发件人配置。如果下游 结盟 如果失败，请配置合法发件人支持的信封或DKIM域，而不是假设其他密码会有所帮助。
修复后，使用无害的消息测试提交和最终接收者评估。保留不同的结果：客户端经过身份验证、发件人被允许、消息被接受、域机制被评估以及最终的处置被观察到。单一的成功标签隐藏了太多东西。该演练教导如何区分这些结果；它不声明已执行的协议处理、 DKIM验证或租户配置。
单独保存验收结果
- 客户端经过身份验证：记录端点、支持的机制和结果，而不是秘密。
- 允许发件人：验证该帐户是否已获得此信封的授权以及可见的发件人。
- 消息接受：保留内容传输后的响应和接收服务器。
- 域验证：独立记录可信SPF / DKIM结果和DMARC对齐。
- 观察到的交付：保留接收方结果，而不将传输接受转换为收件箱保证。