这里没有任何规则是我们将自己的看法包装而成的。如果检查执行的是某项标准中的规定,其下方会引用该标准的原文。如果检查执行的是 Google 或 Yahoo 的要求,则会链接到其相关页面。如果是我们自己的判断,则会明确说明。
身份验证
接收服务器能否证明邮件确实来自其声称的来源。这是送达能力中完全依赖 DNS 的一半,也是 Gmail 和 Yahoo 在2024年对批量发件人强制要求的一半。
ARC 链 auth.arc
ARC 可在转发过程中保留身份验证结果。没有 ARC,添加页脚的邮件列表会破坏你的 DKIM 签名,转发的副本会在远端无法通过 DMARC。
如果失败: 作为发件人无需操作。如果你运行邮件列表或转发器,这一点就很重要,也可以解释为什么你的某些邮件在被他人转发后无法通过 DMARC。
扣除在我们的100分制评分中最多扣除2分。
RFC 7960 §1 — Introduction
DMARC with restrictive policies causes problems for many Mailing Lists.
RFC 8617 §2.1 — Evidence
In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.
Google — Requirements for bulk senders (5,000+/day)
DKIM 签名 auth.dkim
DKIM 使用私钥对邮件的部分内容进行签名,并在 DNS 中发布公钥。我们会验证邮件携带的每个签名,并报告签名域、选择器和密钥长度。
如果失败: 在你的发送平台上启用 DKIM,并发布平台提供给你的密钥。使用 2048 位密钥(1024 位仍可通过验证,但正在被淘汰)。
扣除在我们的100分制评分中最多扣除18分 和 在经典10分制评分中最多扣除1分。
RFC 6376 §3.5 — The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header field.
RFC 6376 §6.1 — Extract Signatures from the Message
Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.
Google — Turn on DKIM for your domain
Google — Requirements for bulk senders (5,000+/day)
DKIM 对齐 auth.dkim_alignment
仅有有效签名不足以通过 DMARC。签名域必须与 From 标头中的域匹配,具体是完全匹配还是按组织域匹配,取决于你发布的策略。
如果失败: 使用你自己的域而不是平台的域进行签名。大多数平台都支持此功能,并将其称为自定义发送域或已认证发送域。
扣除在我们的100分制评分中最多扣除10分 和 在经典10分制评分中最多扣除1分。
RFC 7489 §3.1.1 — DKIM-Authenticated Identifiers
DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed.
Google — Add a DMARC record
Google — Requirements for bulk senders (5,000+/day)
DMARC 结果 auth.dmarc
DMARC 将 SPF 和 DKIM 与读者看到的域关联起来,并告诉接收方在两者均未对齐时应如何处理。我们会报告已发布的策略,以及此邮件是否满足该策略。
如果失败: 发布一条 DMARC 记录。先从 p=none 开始,查看几周的报告,然后在确认还有哪些来源以你的身份发送邮件后,将策略改为 quarantine。
扣除在我们的100分制评分中最多扣除14分。
RFC 7489 §6.6.2 — Determine Handling Policy
DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier.
RFC 7489 §6.3 — General Record Format
DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].
Google — Requirements for bulk senders (5,000+/day)
Yahoo — Sender requirements and recommendations
Sender ID auth.sender_id
这与 SPF 执行相同的检查,但检查的是 From 标头中的域,而不是信封中的域。它回答的是另一个问题:你的读者看到的域是否授权了发送该邮件的服务器。一封邮件的信封可以通过 SPF,而可见域却未对任何服务器提供担保。
如果失败: 为 From 标头中的域发布 SPF,而不只是为平台提供给你的退信域发布。
扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除0.5分。
RFC 4406 §4 — Record Selection
After the above steps, there should be one record remaining and evaluation can proceed.
SPF auth.spf
SPF 是一条 DNS 记录,其中列出了哪些服务器可以为你的域发送邮件。接收服务器获取信封中的地址,查询该域的记录,并检查连接 IP 是否包含在其中。我们会报告结果以及该记录所需的 DNS 查询次数,因为评估会在十次时停止,超过此限制会导致永久错误,而不是通过。
如果失败: 发布一条仅指定你的发送平台、不包含其他内容的记录。如果你的记录接近十次查询的限制,请展开你未使用的 include(今天能够通过的记录,可能会在服务商自行添加一条 include 的那天开始失败)。
扣除在我们的100分制评分中最多扣除18分 和 在经典10分制评分中最多扣除1分。
RFC 7208 §4.6.4 — DNS Lookup Limits
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
RFC 7208 §2.6 — Results of Evaluation
Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.
Google — Define an SPF record
Google — Requirements for bulk senders (5,000+/day)
SPF 对齐 auth.spf_alignment
退信地址是否与读者看到的 From 地址匹配。SPF 对信封进行授权,而 DMARC 仅在两者对齐时才认可该授权。
如果失败: 向你的发送平台申请一个属于你自己域的退信子域。如果你的 DKIM 已经对齐,这并不紧急,但当 DKIM 在传输过程中失效时,你将没有后备方案。
扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除0.5分。
RFC 7489 §3.1.2 — SPF-Authenticated Identifiers
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
RFC 7489 §6.6.2 — Determine Handling Policy
If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check.
Google — Add a DMARC record
Google — Requirements for bulk senders (5,000+/day)
基础设施和信誉
发送邮件所使用的机器和地址,以及互联网其他部分已经如何评价它们。
发送主机名可解析 infra.a_record
HELO 中声明的主机名是否存在地址记录。
如果失败: 为服务器声明的名称发布 A 记录。
扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除3分。
RFC 5321 §5.1 — Locating the Target Host
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Google — MX record values and troubleshooting
阻止列表 infra.dnsbl
发送 IP 是否被收件方实际查询的任何阻止列表收录。我们会根据每个区域自身文档中说明的测试点检查我们的列表,而不是通过网页搜索来汇总,因为失效区域会返回 NXDOMAIN,而这会被视为“干净”。
如果失败: 按照收录运营方网站上的移除流程操作。被主要区域收录会直接阻止邮件,因此应先处理这一项,再处理页面上的其他问题。
扣除在我们的100分制评分中最多扣除25分 和 在经典10分制评分中最多扣除3分。
RFC 5782 §2.1 — IP Address DNSxL
Each IPv4 address listed in the DNSxL has a corresponding DNS entry.
RFC 5782 §5 — Test and Contact Addresses
IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.
Google — Postmaster Tools: reputation and delivery errors
Google — Email sender guidelines
HELO 名称 infra.helo
发送服务器在 SMTP 会话开始时声明的自身名称。它必须是可解析的完全限定域名。
如果失败: 将邮件服务器的主机名设置为你域名中的真实名称,而不是容器 ID 或内部名称。
扣除在我们的100分制评分中最多扣除5分。
RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)
The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.
Google — Email sender guidelines
Google — Requirements for bulk senders (5,000+/day)
MX 记录 infra.mx
From 标头中的域名是否可以接收邮件。没有 MX 记录,回复和退信将无处可去,而且过滤器会将无法接收邮件的发送域名视为不良信号。
如果失败: 为你的发件域名发布 MX 记录,即使它只将邮件路由到一个你每月查看一次的邮箱。
扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除3分。
RFC 5321 §5.1 — Locating the Target Host
The lookup first attempts to locate an MX record associated with the name.
Google — MX record values and troubleshooting
反向 DNS infra.rdns
发送 IP 是否能反向解析到主机名,以及该主机名是否能正向解析到同一 IP。重点是双向匹配:让 PTR 指向任意位置很容易,而匹配的一对记录可以证明该地址归你所有。
如果失败: 请让 IP 所有者将 PTR 设置为你控制的名称,并确保该名称有一个指回此 IP 的 A 记录。
扣除在我们的100分制评分中最多扣除12分 和 在经典10分制评分中最多扣除1.5分。
RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
Google — Email sender guidelines
Google — Requirements for bulk senders (5,000+/day)
传输加密 infra.tls
邮件是否通过 TLS 到达,以及使用了哪种密码套件。所有现代系统都会协商 TLS;以明文方式到达的邮件反映出发送配置存在问题。
如果失败: 在发送服务器上启用 STARTTLS。所有主流平台都已支持它,因此此处失败通常意味着传输路径中存在自托管中继。
扣除在我们的100分制评分中最多扣除5分。
RFC 3207 §2 — STARTTLS Extension
The STARTTLS extension to SMTP is laid out as follows:
Google — Require TLS for secure message transport
Google — Requirements for bulk senders (5,000+/day)
垃圾邮件引擎
独立内容过滤器如何判断这封邮件。使用两个引擎而非一个,因为单个引擎的评分只是该引擎的看法。
AI 判定 spam.ai_judge
模型根据技术检查结果和内容测量数据,估算现代机器学习过滤器会如何处理该邮件。它看到的是事实,而不是正文文本。
如果失败: 其本身仅提供详细信息。它的估算会计入下方的综合判定。
仅显示详细信息。从不计分。
综合判定 spam.panel
根据已返回结果的引擎得出一个数值,并进行加权,使最强烈的意见不会被简单平均掉。SpamAssassin 和 Postmark 计为一票,因为它们共享同一套规则库。
如果失败: 逐项处理各个检查结果。这一行会随之变化。
扣除在我们的100分制评分中最多扣除25分。
Google — Why Gmail marks messages as spam
How this score is calculated
Postmark SpamCheck spam.postmark
第三种意见,默认关闭。它的端点会接收整封邮件,而我们无法在不破坏测量对象的情况下对其中任何内容进行编辑,因此启用它意味着接受将每封测试邮件复制给第三方。
如果失败: 无需处理。关闭时,该检查会报告它已关闭,这与通过并不相同。
仅显示详细信息。从不计分。
Rspamd spam.rspamd
另一个独立开发的过滤器。它与 SpamAssassin 出现分歧的频率足以让其意见值得参考,这就是在此加入它的原因。
如果失败: 仅提供详细信息。此引擎的意见会计入综合判定,而不是单独评分。
仅显示详细信息。从不计分。
SpamAssassin spam.spamassassin
经典的基于规则的过滤器,至今仍是大多数电子邮件测试工具背后的引擎。所有触发的规则及其权重都会列出。
如果失败: 查看触发的规则,而不是总分。一旦看清具体是哪些规则,大多数都很容易消除。
扣除在经典10分制评分中最多扣除3分。
Google — Why Gmail marks messages as spam
Apache SpamAssassin — rule documentation
建议
值得执行且从不计分。本节中的任何内容都不会导致扣分,这是由测试强制执行的产品决策。
BIMI advisory.bimi
域是否发布了 BIMI 记录,该记录会让某些客户端在你的邮件旁显示徽标。它首先需要一项强制执行的 DMARC 策略,以及一张需要付费的已验证标志证书。
如果失败: 当 DMARC 设置为隔离或拒绝,并且发送量足以证明证书成本合理时,值得实施。
建议项。不扣分。
BIMI — draft specification, not yet an RFC
DKIM 密钥期限和长度 advisory.dkim_key_rotation
签名密钥的长度及其已使用的时间。密钥越短,随着时间逐年推移,进行离线攻击的成本就越低。
如果失败: 改用 2048 位密钥并按计划轮换。发布新的选择器,切换为使用它签名,然后停用旧选择器。
建议项。不扣分。
RFC 8301 §3.2 — Key Sizes
Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.
Google — Turn on DKIM for your domain
DNSSEC advisory.dnssec
域是否已签名。SPF、DKIM 和 DMARC 都存在于 DNS 中,因此能够伪造 DNS 应答的攻击者也能伪造这三者。
如果失败: 在你的注册商处启用它。通常只需打开一个开关,其余工作由注册商处理。
建议项。不扣分。
RFC 4033 §2 — Definitions of Important DNSSEC Terms
Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets
MTA-STS advisory.mta_sts
域是否发布了要求其他服务器拒绝向你进行未加密投递的策略。它保护的是发送给你的邮件,而不是你发送的邮件。
如果失败: 通过 HTTPS 发布 TXT 记录和策略文件(大约需要一个下午,并且可以阻止降级攻击)。
建议项。不扣分。
RFC 8461 §3 — Policy Discovery
To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.
TLS 报告 advisory.tls_rpt
域是否要求在有人无法通过 TLS 向其投递时发送报告。与 MTA-STS 配合使用:只有策略而没有报告,你将无法判断它是否有效。
如果失败: 添加 TXT 记录,并指定一个用于接收每日报告的地址。
建议项。不扣分。
RFC 8460 §3 — Reporting Policy
A domain publishes a record to its DNS indicating that it wishes to receive reports.