SPF/DKIM/DMARC 记录检测工具
只需输入域名，即可实时查询 SPF、DMARC、DKIM 记录，诊断反仿冒邮件认证的配置状况。
诊断防冒名的 DNS 设置
输入一个域名，本工具便当场查询其 SPF、DKIM 与 DMARC 记录，报出防冒名邮件的设置做到了哪一步。您可借此弄清自家域名是否易被第三方冒用，以及自己发出的信是否为对方所信任。
**这三者各司其职，单靠其中任何一个都不够。** SPF 宣告何等服务器可代该域名发信，DKIM 则以签名担保信件不曾被改动。**而 DMARC 的职责，是指示收信一方如何处置那些未通过前两项检查的邮件。** 关窍正在于此：**纵有 SPF 与 DKIM，若无 DMARC，一封检查未过的冒名信究竟作何处置，便全凭收信方自行裁夺。** 许多域名把 DMARC 留在 `p=none`，那意思是「报告尽管送来，却什么也不拒」——这是途中的一站，而非已然立起的防线。
使用方法
- 输入待查的域名 只给域名即可，形如 `example.com`。
- 查看 SPF 的内容 **请看所许可的发信方清单，以及末尾的限定符是 `~all` 还是 `-all`。**
- 阅读 DMARC 的策略 **停在 `p=none` 时，尚无任何拒绝之举。**
- 补上所缺的记录 诊断的结果，便是您决定往 DNS 里添些什么的依据。
用好本工具的小技巧
- 建议按照 SPF、DKIM、DMARC 的顺序进行配置：先完善 SPF 和 DKIM，最后再用 DMARC 向接收方明确处理指示。
- DMARC 不要一开始就设为 p=reject，应先用 p=none 收集报告，确认所有合法发信渠道后再逐步收紧策略，以避免误伤。
- include 数量过多的域名可能触及"10 次 DNS 查询 / 255 字符"的限制而导致查询失败，建议定期清理不必要的 include。
- 本工具仅尝试常见的 DKIM 选择器，因此即使显示"未找到"，也可能只是实际使用的选择器名称不同。
- Gmail、Outlook 等主要邮件服务商自 2024 年起已要求大量发信者配置 SPF、DKIM、DMARC，发送邮件通讯的域名应优先确认此项设置。
这些场景会用到
查一查自家域名的防线
**冒名之害，最先落在那些全无防备的域名头上。**
查究自己的信为何被当作垃圾
信件到不了时，头一个该疑的便是 SPF 或 DKIM 有缺。
添了发信服务之后确认一遍
**一旦用上新的投递服务，便该查一查是否忘了把它添进 SPF。**
查一查往来对象的域名
这为判断所收之信是否真出其手，提供了依据。
邮件认证的术语
- SPF
- **罗列可代该域名发信之服务器**的 DNS 记录。末尾的 `-all` 意为凡未列者一概拒收。
- DKIM
- 发信时附上的数字签名。**收信方可凭公钥确认：信件的正文与标头在途中不曾被改写。**
- DMARC
- **指示收信一方如何处置未通过 SPF 与 DKIM 检查之邮件**的记录。
- p=none
- DMARC 的一种策略，意为**要报告，但既不拒绝也不隔离。** 那是刚开始采用时的设定。
- p=quarantine 与 p=reject
- 分别指示收信方「当作垃圾另置一旁」与「径直拒收」。**做到这一步，才是此事的目标。**
- 选择器
- 言明 DKIM 公钥安放在 DNS 何处的名称，以 `selector._domainkey.example.com` 的形式被引用。
常见问题
闲话 ― 反仿冒邮件三大支柱的诞生历程
SPF、DKIM、DMARC 分别在不同时期因不同背景而诞生。最早出现的 SPF（约 2003 年）用于声明"哪些 IP 地址可以使用该域名发送邮件"，作为对抗垃圾邮件发送者伪造发件地址的手段而普及开来。但 SPF 在邮件转发方面存在弱点：转发后发件 IP 会发生变化，导致认证失败。
弥补这一弱点的是约 2007 年标准化的 DKIM。它不像 SPF 那样依据 IP 地址判断，而是对邮件正文和部分邮件头附加数字签名，接收方使用 DNS 中公开的公钥验证签名，因此只要签名本身未被破坏，即使经过转发也能通过认证。
不过 SPF 和 DKIM 只能检测出"认证失败"，至于失败邮件该如何处理（投递、标记为垃圾邮件或拒收）完全取决于接收服务器自身判断。为统一这种"对接收方的指示"，2012 年制定了 DMARC。DMARC 还具备将认证结果以报告形式（rua=）回传给发件域名管理者的机制，使管理者能够持续监控自己的域名是否被滥用。
2024 年 Google 和 Yahoo 将 SPF、DKIM、DMARC 事实上列为大量发信者（每日 5000 封以上）的必备要求，这三大支柱也因此从少数大企业的专属知识，变成了发送邮件通讯或系统通知邮件的所有机构都无法忽视的基础常识。