这里没有任何规则是我们将自己的看法包装而成的。如果检查执行的是某项标准中的规定,其下方会引用该标准的原文。如果检查执行的是 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 — Sender guidelines FAQ: rules for 5,000+ messages a 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.
RFC 8301 §3.1 — Signing and Verification Algorithms
rsa-sha1 MUST NOT be used for signing or verifying.
RFC 8463 §6 — Transition Considerations
For backward compatibility, signers can add multiple signatures that use old and new signing algorithms.
Google — Set up DKIM
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
DKIM 对齐 auth.dkim_alignment
仅有有效签名不足以通过 DMARC。签名域必须与 From 标头中的域匹配,具体是完全匹配还是按组织域匹配,取决于你发布的策略。
如果失败: 使用你自己的域而不是平台的域进行签名。大多数平台都支持此功能,并将其称为自定义发送域或已认证发送域。
扣除在我们的100分制评分中最多扣除10分 和 在经典10分制评分中最多扣除1分。
RFC 9989 §4.4.1 — DKIM-Authenticated Identifiers
A single email can contain multiple DKIM signatures, and it is considered to produce a DMARC "pass" result if any DKIM-Authenticated Identifier aligns with the Author Domain.
Google — Set up DMARC
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
DMARC 结果 auth.dmarc
DMARC 将 SPF 和 DKIM 与读者看到的域关联起来,并告诉接收方在两者均未对齐时应如何处理。我们会报告已发布的策略,以及此邮件是否满足该策略。
如果失败: 发布一条 DMARC 记录。先从 p=none 开始,查看几周的报告,然后在确认还有哪些来源以你的身份发送邮件后,将策略改为 quarantine。
扣除在我们的100分制评分中最多扣除14分。
RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"
If no Authenticated Identifiers exist for the domain, or none of the Authenticated Identifiers align with the Author Domain, the message is considered to fail the DMARC mechanism check.
RFC 9989 §4.7 — DMARC Policy Record Format
DMARC Policy Records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [RFC6376].
Google — Sender guidelines FAQ: rules for 5,000+ messages a 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 — Set up SPF
Google — Sender guidelines FAQ: rules for 5,000+ messages a day
SPF 对齐 auth.spf_alignment
退信地址是否与读者看到的 From 地址匹配。SPF 对信封进行授权,而 DMARC 仅在两者对齐时才认可该授权。
如果失败: 向你的发送平台申请一个属于你自己域的退信子域。如果你的 DKIM 已经对齐,这并不紧急,但当 DKIM 在传输过程中失效时,你将没有后备方案。
扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除0.5分。
RFC 9989 §4.4.2 — SPF-Authenticated Identifiers
Only an SPF-Authenticated Identifier that has Identifier Alignment with the Author Domain is enough to validate the authorized use of the Author Domain.
RFC 9989 §5.3.5 — Determine DMARC "Pass" or "Fail"
If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.
Google — Set up DMARC
Google — Sender guidelines FAQ: rules for 5,000+ messages a 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 — Set up MX records
阻止列表 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 — Sender guidelines FAQ: rules for 5,000+ messages a 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 — Set up MX records
反向 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 — Sender guidelines FAQ: rules for 5,000+ messages a day
传输加密 infra.tls
邮件是否通过 TLS 到达,以及使用了哪种密码套件。所有现代系统都会协商 TLS;以明文方式到达的邮件反映出发送配置存在问题。
如果失败: 在发送服务器上启用 STARTTLS。所有主流平台都已支持它,因此此处失败通常意味着传输路径中存在自托管中继。
扣除在我们的100分制评分中最多扣除5分。
RFC 3207 §2 — STARTTLS Extension
The STARTTLS extension to SMTP is laid out as follows:
Google — Send email over a secure TLS connection
Google — Sender guidelines FAQ: rules for 5,000+ messages a 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 — Set up DKIM
DMARC 报告投递 advisory.dmarc_reporting
您的 DMARC 记录中的地址是否真的会收到任何内容。如果报告地址位于您自己的域之外,RFC 9990 要求该域先发布自己的许可,即在 your-domain._report._dmarc.their-domain 发布一条 TXT 记录。如果没有该记录,接收方会丢弃该地址:没有退信,没有错误,也没有报告。这是常规配置,而不是罕见情况,因为该地址通常位于监控服务商的域中,或者策略位于发送子域,而该地址位于您的主域中。同一规则也适用于失败报告,RFC 9991 针对 ruf 标签指向相同的流程。我们会查询接收方会查询的相同记录,并显示我们查询的名称。
如果失败: 请让目标域的运维方在检查结果中显示的名称下发布一条包含 v=DMARC1 的 TXT 记录。通常,您将域添加到监控服务商的账户后,他们会为您完成此操作,因此如果缺少该记录,很可能是该域从未在他们那边添加过。如果报告发送到您自己的域,则无需执行任何操作。
建议项。不扣分。
RFC 9990 §4 — Verifying External Destinations
When a Mail Receiver discovers a DMARC Policy Record in the DNS, and the Organizational Domain at which that record was discovered is not identical to the Organizational Domain of the host part of the authority component of a [RFC3986] specified in the "rua" tag, the following verification steps MUST be taken:
RFC 9990 §4 — Verifying External Destinations
Where the above algorithm fails to confirm that the external reporting was authorized by the Report Consumer, the URI MUST be ignored by the Mail Receiver generating the report.
RFC 9991 §5 — Verifying External Destinations
In case of external destinations, a Mail Receiver who generates failure reports MUST use the Verifying External Destinations procedure described in Section 4 of [RFC9990], substituting the "ruf" tag where the "rua" tag appears in that procedure.
Google — Set up DMARC
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.
退信地址长度 advisory.return_path_length
退信地址的长度。RFC 5321 要求接收服务器接受 @ 之前的 64 个八位字节,并在同一节中指出,任何实现都不应施加其能够避免的限制。尽管如此,许多实现还是设置了限制,超过该限制的邮件会在 MAIL FROM 阶段被拒绝,此时甚至还未发送正文。发送平台会将收件人信息编码到退信地址中,以便将退信与原收件人相匹配,因此其长度取决于您写信给谁,而不是您自己。
如果失败: 缩短平台添加在前面的固定部分,或改用更短的退信域名。如果两者都无法更改,面临风险的就是地址最长的订阅者,因此应测量列表中最长的地址,而不是平均长度。
建议项。不扣分。
RFC 5321 §4.5.3.1.1 — Local-part
The maximum total length of a user name or other local-part is 64 octets.
RFC 5321 §4.5.3.1 — Size Limits and Minimums
Every implementation MUST be able to receive objects of at least these sizes.
Haraka — the address parser that enforces the 64-octet local-part, and the flag that relaxes it
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.