发布日期：2026 年 9 月 21 日 · RootGS 技术编辑
域名已经添加SPF记录，邮件仍被拒收；DKIM显示通过，DMARC却失败；也有人一次性设置严格策略后，正常通知邮件开始丢失。邮件认证并不是添加三个TXT记录就完成。要先知道每个发信系统使用了哪些身份，再判断认证是否通过、是否与用户看到的发件域名对齐。本文介绍可操作的核查顺序，同时说明认证通过为什么不能保证进入收件箱。
一、先列出所有真实发信来源
企业邮箱、网站订单通知、营销平台、工单系统和设备告警，可能使用不同发信服务。先整理每一类邮件的发送平台、用户看到的From域名、信封发件域名，以及DKIM签名域名。不能只验证管理员手工发的一封邮件，就认定所有自动通知都已覆盖。
迁移邮箱或更换网站SMTP时，记录修改时间与旧平台是否仍在发信。域名中的旧授权长期保留会增加管理复杂度，过早移除又可能让尚未迁完的系统失败。用实际发信清单决定调整顺序，比从网上复制一整条SPF模板更可靠。
二、SPF检查发信来源，不直接认证可见From
SPF让接收方检查某个服务器是否被相应域名授权发送，通常涉及SMTP信封中的MAIL FROM域名，在特定情形还涉及HELO身份。邮件界面显示的From与这些身份并不是同一个字段。因此某个域名的SPF通过，不等于用户看到的发件地址就已经被认证。
发布时应使用发信服务要求的机制，并把同一名称下的SPF策略正确整合，不能并排发布多条互相独立的v=spf1记录。include等会触发DNS查询的机制存在协议规定的查找限制，嵌套服务过多可能产生错误。不要仅凭TXT字符串看起来简短就判断解析成本很低。
SPF记录也不是邮件密码，不能通过它给网站建立SMTP登录权限。DNS授权和应用认证需要分别配置与测试。
三、DKIM签名证明什么，又不证明什么
DKIM由发信系统使用私钥签名，接收方根据签名中的域名与选择器查询公钥并验证相关内容。配置时要核对实际发出的邮件是否已经带签名，而不是只确认DNS里有一段公钥。签名域名还可能属于服务商，与用户可见From域名不同。
转发或邮件列表处理可能修改被签名的内容，从而影响验证结果。验收要覆盖客户实际收信路径，而不是只测试同一平台内互发。DKIM通过也不表示内容一定可信、收件人一定愿意接收，签名只是邮件认证链路中的一部分。
四、DMARC的关键是认证与标识对齐
DMARC将认证结果与可见From域名关联起来。核心判断不是“SPF和DKIM都必须通过”，而是至少有一条支持的认证路径通过，并满足相应的标识对齐要求。实际是否对齐取决于域名关系和采用的严格或宽松模式，不能只比较邮件界面上的名称。
例如From使用企业自己的域名，但SPF验证的是一个无关平台域名，DKIM也只由无关平台域名签名，那么这两项即使各自通过，也可能不满足DMARC对齐。应优先使用发信平台支持的自定义域名认证能力，并用真实邮件头确认效果，而不是不断重复添加无关TXT记录。
五、先观察完整发信范围，再收紧策略
在首次部署或调整发信体系时，可以先采用适合观察的策略并收集报告，检查合法来源是否都已覆盖。p=none表达观察性的处置策略，不代表认证已通过，也不是所有接收方必须投递。接收方仍可结合自身规则处理邮件。
确认合法来源的身份与对齐后，再评估逐步收紧到quarantine或reject。直接照搬严格策略，可能把遗漏的订单通知或设备告警一起影响。报告接收地址需要可管理、可处理数据；使用外部报告域名时还应核对相关授权要求。报告是聚合线索，不能把它当成每封邮件即时送达的完整回执。
六、用真实邮件头和DNS结果交叉核验
准备来自每个实际发信系统的测试邮件，并在不同目标邮箱检查认证结果。查看可信接收系统生成的Authentication-Results，结合From、Return-Path和DKIM-Signature分析相关域名；不要信任任意转发文本或不明来源插入的认证头。
下面是只读DNS查询示例。selector1必须换成该发信平台实际使用的选择器，示例域名不能直接用作生产配置。记录查询结果、时间和正在验证的邮件，避免用今天的DNS解释变更前的旧邮件。
dig TXT example.com
dig TXT selector1._domainkey.example.com
dig TXT _dmarc.example.com公网缓存、多个选择器和轮换中的公钥都可能影响观察。保留原记录与变更时间，按服务商流程进行密钥轮换，不应因为一个旧邮件验证失败就立即删除所有旧选择器。
七、认证通过后，继续看投递质量
邮件进入垃圾箱还可能与内容、用户反馈、发信节奏、地址质量以及发送基础设施有关。认证只解决部分身份与策略问题，不能保证所有目标邮箱进入收件箱。排查退信时保存具体状态和原因，区分认证失败、地址不存在、限速和其他拒收。
为网站通知建立业务侧可核对的发送记录，并区分已提交给发信平台、被接收方接受和用户已阅读。不要把SMTP提交成功写成客户已看到邮件。持续维护发信清单、轮换记录和失败告警，才能让域名认证从一次性DNS修改变成稳定的通知能力。
