SPF DMARC 检测工具

填入域名点检测即可。工具会读取 SPF 记录并展开其中每一条 include 和 redirect，读取 _dmarc.你的域名 上的 DMARC 记录，按一批常见名称探测 DKIM selector，并解析 MX 主机。每条记录给出各自的结论，MTA-STS、TLS-RPT、BIMI 也在同一趟里查完。

RFC 7208 规定，求值过程中触发 DNS 查询的项最多十个：include、a、mx、ptr、exists 以及 redirect 修饰符。include 是递归计数的，所以接入几家服务商就可能把总数悄悄推过十次。求值会在第一个匹配的机制处停下，因此这个总数是最坏情况，而不是对每封邮件的判定：要走到第十次之后才匹配的发信路径会拿到永久性错误——在 DMARC 里等同于 SPF 失败——而更早匹配的发信方仍然通过。这也是为什么超预算的记录看上去毫无异常，却只对一部分发信方失败。

先删掉已经不再使用的服务商 include，多数情况这一步就够了。服务商地址段稳定的，把 include 换成 ip4、ip6 机制，它们不占预算。把一部分邮件迁到带独立 SPF 记录的子域上，等于把预算拆成两份。把 include 展平成字面地址也可行，但需要长期维护——服务商可能不打招呼就改地址段。

-all 是硬失败：不在名单上的服务器即未授权，收信方可以直接拒收。~all 是软失败：同样未授权，但先投递再打标记。名单还没摸干净时用 ~all 比较稳妥，-all 才是最终该到的位置。?all 是中立，什么都不断言，以它结尾的记录和没有记录差别不大。

因为 DNS 没有任何办法列出一个域名发布了哪些 selector。DKIM 密钥存放在 selector._domainkey.你的域名，不知道 selector 名称就无从查起。本工具会探测主流服务商使用的名称，但自定义的——包括 Amazon SES 签发的随机 selector——必须手动提供。从该域名任意一封邮件的 DKIM-Signature 头里取 s= 标签，填进 selector 输入框即可。

p=none 表示仅监控：收信方不做任何处置，只发报告。作为起点是对的，但它保护不了任何东西，所以是中转站而非终点。p=quarantine 让收信方把验证失败的邮件按可疑处理，通常落进垃圾箱。p=reject 则直接拒收。常规路径是先 none，等报告干净了转 quarantine，最后到 reject。

最常见的原因是缺少授权记录。如果 rua 地址所在的域名和被报告的域名不是同一个——比如用了监控服务商——对方域名必须发布一条 你的域名._report._dmarc.对方域名 的记录表示接受。缺了它，规范的发报方会直接丢弃报告且不作任何提示，表现出来就和没人发报告一模一样。本工具会对每个外部地址检查这条记录。

不会。网页无法建立 SMTP 连接——浏览器碰不到 25 端口——所以 MX 一节只检查配置。它确认记录存在、读取优先级、解析每个目标，并指出几类常见故障：目标没有地址记录、该填主机名的地方填了 CNAME、或者直接写了 IP 地址。对端服务器到底有没有响应，需要能说 SMTP 的工具才能验证。

SPF 通过不等于 DMARC 通过。DMARC 还要求对齐：通过 SPF 的那个域名，必须和收件人看到的 From 地址一致。通过服务商发信时，常见情况是 SPF 过的是服务商自己的域名，而 From 头显示的是你的域名，对齐就不成立。用你自己的域名做 DKIM 签名可以解决，因为 DKIM 对齐是独立判定的。至于信誉、内容和名单质量，那已经在认证之外了。

MTA-STS 告诉发信服务器：投递到本域必须使用 TLS，堵住机会性 TLS 留下的降级攻击口子。TLS-RPT 则请对方在这一环节失败时发报告。BIMI 用于发布品牌 logo 供支持展示的收信方使用，前提是 DMARC 已经处于强制策略。三者都是可选的，没有配置完全正常。

可以，而且凡是发信的子域都值得查一遍，因为 SPF 和 DKIM 都是按确切名称查询的。DMARC 不同：子域没有记录时，收信方会回退到组织域的记录并套用其 sp 标签。本工具只查你输入的确切名称，所以子域上 DMARC 显示为空，往往意味着实际生效的是上级域的策略。

两者回答的问题不同。DNS 查询工具给你看记录——任意类型、任意解析器，还能追委派链。这个工具则是对其中特定几条做判断：它把 SPF 链展开而不是打印一行，按上限计数，并依据各自的规则解读 DMARC 和 DKIM。想看发布了什么用那个，想知道配得对不对用这个。