电子邮件送达能力检查
在声誉之前、在内容之前，收件方只问一个问题：这个域名能证明邮件真的来自它吗？本检查读取这份证明——MX 记录、SPF 发件人名单（按收件方的计数方式展开并计数）、位于 _dmarc 的 DMARC 策略，以及常用选择器下的 DKIM 密钥——并按运维人员会修复的顺序，用通俗语言返回发现。
想持续盯着它？用 myeventwatch 免费监控——到期和宕机提醒，无需绑卡。
这项检查测的是什么
垃圾邮件过滤从身份开始，因为身份可以在毫秒内查清。当一封邮件声称来自某个域名时，接收服务器会查询该域名发布的规则。SPF 列出被允许发送的服务器。DKIM 提供一个签名，可用 DNS 中发布的密钥来验证。DMARC 要求可见的发件人域名与这两种证明中的一种对齐，并说明两者都不对齐时的惩罚——无、隔离、拒绝。本页调用 sysosx 服务器上的 GET /api/check/email-auth，它通过健康检查所用的 DNS 解析器读取同样的记录，并将其转化为发现：每个协议、每个问题、一个严重程度，按值得修复的顺序排列。
其中两个发现值得谈谈诚实问题，因为这两处正是检查器常伪造精度的地方。SPF 查询计数是真实的：检查器按接收方适用的相同规则逐项展开 include 和 redirect 链，所以它报告的数字就是严格的接收方会计算出的数字——包括当记录随着供应商更改自己的记录而悄悄漂移、超过十次查询上限时。DKIM 结果是一次探测，而不是一次普查：密钥发布在所有者选择的选择器名称之下，检查会尝试常用选择器，而一个都没找到并不证明 DKIM 不存在——任何其他选择器下的密钥从外部都是看不见的，结果会直截了当地说明这一点，而不是宣称某个域名未签名。唯一完整的 DKIM 测试仍然是一封真实邮件及其 Authentication-Results 标头。
如何阅读结果
从失败项开始；它们是垃圾邮件文件夹最喜欢的原因。没有 MX 意味着该域名根本收不到邮件。没有 SPF，或 SPF 记录以 +all 结尾，意味着任何人都可以声称自己是你——后者更糟，因为这种声称是被官方允许的。多条 SPF 记录会悄悄使 SPF 评估整体失效。缺少 DMARC 记录意味着失败的邮件没有既定的惩罚，而且同样代价高昂的是，没有人在收集那些显示谁以你的域名发送的聚合报告——欺骗活动通常就是这样被发现的。当报告真的到达时，它们以原始 XML 的形式出现；DMARC 报告分析器会在本地打开 .xml、.gz 和 .zip 文件，并将其转化为按来源划分的表格，显示谁通过了、谁失败了以及要修复什么。警告是中间状态：p=none 是启动 DMARC 的好地方，却是止步的坏地方；~all 是测试模式，不是目的地。然后看画面的另一半：认证证明身份，而DNS 黑名单检查器衡量声誉——两者都要运行，因为一个认证完美的域名如果 IP 被列入名单仍会进垃圾箱，一个干净的 IP 如果 SPF 损坏也会如此。把这一切串起来的指南是为什么你的邮件会进垃圾箱。
常见问题
SPF、DKIM 和 DMARC 是什么？它们如何配合？
它们是三个通过 DNS 发布的、对“这封邮件真的来自它声称的域名吗？”这一问题的回答。SPF 列出被允许为某个域名发送的服务器。DKIM 让域名对邮件进行加密签名，使接收方可以用 DNS 中发布的密钥验证签名。DMARC 将它们联系起来：它要求可见发件人标头中的发送域名与 SPF 或 DKIM 结果对齐，并告诉接收方当两者都不对齐时该怎么做——监控、隔离或拒绝。没有 DMARC 的 SPF 只是一个未签名的建议；DMARC 才是把另外两者变成策略的东西。
三项都通过了，我的邮件为什么还是进垃圾箱？
因为认证是入场券，不是座位安排。通过 SPF、DKIM 和 DMARC 意味着接收方相信邮件确实是你的——之后，投放位置取决于声誉和内容：黑名单列入（用本站的黑名单检查器检查）、收件人互动、投诉率、发送量模式以及邮件本身。认证失败是垃圾邮件投放中最常见的可修复原因，这也是为什么这项检查排在第一位，但这里结果干净而垃圾邮件投放持续存在，意味着问题出在声誉或内容上，而不是身份上。
检查说未找到 DKIM 密钥。这是否意味着我的域名没有签名？
不是——结果本身也用同样的话说明了这一点。DKIM 密钥位于域名所有者选择的选择器名称之下，而且无法从外部分别列举一个域名的选择器。本检查探测主要服务商使用的常用选择器（default、google、selector1、selector2、mail、dkim、s1、s2、k1、mandrill 等等）。任何其他名称下的密钥对探测来说都是看不见的。决定性的测试是一封真实邮件：向你控制的邮箱发送邮件，并检查 Authentication-Results 标头，它会报告所用的选择器以及签名是否验证通过。
为什么检查要统计 SPF 查询次数？为什么上限是 10？
评估一条 SPF 记录可能需要进一步的 DNS 查询——每个 include、a、mx、ptr、exists 和 redirect 项都算一次。RFC 7208 将总数上限设为 10；超过它，接收方会返回永久错误，SPF 结果作废，这可能比一条能干净评估的适度记录更糟。随着服务商被添加，记录的查询次数会悄悄增长（每个 include 都带来自己的项），所以一条在设置时合法的记录，会随着供应商更改自己的记录而漂移超过上限。本检查按接收方的方式展开记录并报告真实计数，让漂移在它使你的认证失效之前就被看见。
如果有多个发现都是失败，我应该先修复什么？
按顺序：多条 SPF 记录（合并为一条——在修复它之前，下游的一切都不可靠）、缺失或 +all 的 SPF 记录（发布真实的发件人名单，并以 -all 结尾）、缺失的 DMARC 记录（从带报告地址的 p=none 开始，这样你可以在强制执行之前看到谁以你名义发送），然后随着报告变干净，将 DMARC 从 p=none 提升到 p=reject。如有黑名单列入，那是并行工作——在修复记录的同时修复其原因并申请移除。我们的指南会按顺序讲解其中的道理：为什么你的邮件会进垃圾箱。