先理解三种检查分别做什么
SPF 发布域名允许哪些系统发信；DKIM 使用 selector 对应的公钥验证邮件签名；DMARC 检查 SPF 或 DKIM 是否与可见 From 域对齐，并规定认证失败后的处理策略。通过其中一项，不代表另外两项也通过。
先找准邮件中的多个域名
邮件认证可能涉及多个域名：可见的 Header From、信封或 Return-Path、DKIM 签名域，以及发布 DNS 记录的域名。查询 DNS 前先从邮件头记录它们。把 SPF 或 DMARC 查在错误域名上，是误判“记录不存在”的常见原因。
检查 SPF，避免制造永久错误
在准确的 envelope 域名上查询 TXT，确认只有一条以 v=spf1 开头的有效 SPF 记录。补齐所有合法发信方，删除过期机制，并注意 DNS 查询次数限制。多个 SPF 记录不会自动合并，接收方可能将其视为永久错误。SPF 通过也不代表可见 From 域已经对齐。
使用 selector 检查 DKIM
从 DKIM-Signature 邮件头读取 d= 和 s=，再查询 selector._domainkey.example.com 的公钥，确认记录存在且格式正确。公钥写在错误 selector、记录缺失、签名域改变，或邮件签名后内容被修改，都可能导致 DKIM 验证失败。
理解 DMARC 域名对齐
DMARC 通常发布在 _dmarc.example.com。只有 SPF 或 DKIM 同时完成认证，并且在当前对齐模式下与 Header From 域一致，DMARC 才能通过。邮件可能对服务商域 SPF 通过，却因为 Return-Path 不同而 DMARC 失败；转发可能破坏 SPF，DKIM 也可能因内容被改而失败。
读取 Authentication-Results，不要靠猜
检查收件服务器生成的 Authentication-Results，关注 spf=、dkim=、dmarc=、header.from、smtp.mailfrom 和 header.d。把这些值与刚才查询的 DNS 记录对比。不要只看发信服务商后台，收件服务器的结果才说明这封邮件实际经历了什么。
先观察报告，再执行严格策略
新接入域名时，适合先使用 DMARC p=none，并在条件允许时配置 rua 汇总报告。先识别全部合法发信方，修复对齐问题，清理未知来源，再考虑 quarantine 或 reject。执行严格策略前，要测试子域、转发和第三方平台。
投递问题不只由 DNS 决定
SPF、DKIM、DMARC 全部通过，也不保证邮件一定进收件箱。还要检查反向 DNS、MX 是否可用、发信量、退信率、投诉率、邮件内容、链接、From 和 Reply-To、退订处理，以及发信 IP 和域名信誉。要区分认证失败与垃圾邮件过滤。
一套安全的验证流程
从每个合法平台向多个邮箱发送测试邮件；保存完整邮件头；用 DNS 查询检查 SPF、DKIM、DMARC；对比各个域名和 selector；查看报告；一次修正一个发信方；最后重新测试。不要把私钥发布到 DNS，也不要把含个人信息的邮件内容提交给公开工具。
立即查询真实数据
使用 IIPP 实时工具，检查你正在处理的域名或 IP 地址。
DNS 记录查询 →