Email Spam Tester 运行测试 · 给 AI 智能体 · API

测试的工作原理

向一次性地址发送一封邮件,系统会对其运行39项检查。本页列出了全部检查:每项检查关注什么、失败时会扣除多少分,以及检查所依据的标准章节。

这里没有任何规则是我们将自己的看法包装而成的。如果检查执行的是某项标准中的规定,其下方会引用该标准的原文。如果检查执行的是 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

内容

邮件本身:其结构、链接、图片,以及过滤器在做出判断前读取的内容。

图片替代文本 content.alt_attributes

图片是否包含 alt 属性。邮件客户端默认阻止远程图片,因此在最初几秒内,替代文本就是你的邮件内容。

如果失败: 编写能够传达含义的替代文本,绝不要让主要视觉内容缺少替代文本。

扣除在我们的100分制评分中最多扣除4分 和 在经典10分制评分中最多扣除0.5分。

Google — Email sender guidelines

脚本和 iframe content.forbidden_tags

HTML 是否包含任何邮件客户端都不会运行的标签。最好的情况是它们会被移除,最坏的情况是它们会被视为规避检测的信号。

如果失败: 移除 script、iframe、object 和 embed。任何交互式内容都应放在链接之后。

扣除在我们的100分制评分中最多扣除10分 和 在经典10分制评分中最多扣除1分。

Google — Email sender guidelines

文本与 HTML 的平衡 content.html_text_ratio

邮件中标记内容与可读文本各占多少。用一整页标记包裹一句话,是过滤器能够识别的形式。

如果失败: 编写与 HTML 表达相同内容的纯文本部分,而不是占位内容。

扣除在我们的100分制评分中最多扣除3分 和 在经典10分制评分中最多扣除0.3分。

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

纯文本和 HTML 部分 content.html_version

邮件是否在 HTML 之外同时包含纯文本替代版本。一些过滤器会考虑是否缺少该版本,而且每个屏幕阅读器都需要它。

如果失败: 发送包含真实纯文本版本的 multipart/alternative,而不是空白部分或一句提示在浏览器中查看的文字。

扣除在我们的100分制评分中最多扣除5分。

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

HTML 大小 content.html_weight

HTML 部分有多大。Gmail 会截断超过约 102 KB 的邮件,并将其余内容隐藏在链接后面,这也会导致退订页脚被隐藏。

如果失败: 精简内联 CSS 和重复的样式块(删除未使用的规则后,大多数模板的大小可控制在限制的三分之一以内)。

扣除在我们的100分制评分中最多扣除3分 和 在经典10分制评分中最多扣除0.3分。

Google — Email sender guidelines

图片大小 content.images_weight

邮件加载的所有图片的总大小。过大的图片会使邮件在手机上加载缓慢,而纯图片邮件也会因其形式受到过滤器怀疑。

如果失败: 压缩图片,并确保关闭图片后邮件仍然可读。

扣除在我们的100分制评分中最多扣除3分 和 在经典10分制评分中最多扣除0.3分。

Google — Email sender guidelines

附件扫描 content.malware

附件是否携带已知恶意软件。在扫描器已关闭的部署环境中,此项会报告扫描未运行,而不是报告未发现问题。

如果失败: 如果此项触发,请停止发送,并查明用于构建邮件的计算机上存在什么问题。

扣除在我们的100分制评分中最多扣除60分。

Google — Why Gmail marks messages as spam

ClamAV — how detection works

预览文本 content.preheader

客户端在主题旁显示的预览行。如果没有预览文本,客户端会显示正文中最先出现的内容,通常是在线查看链接。

如果失败: 将隐藏的预览文本块添加为正文的第一个元素。

扣除在我们的100分制评分中最多扣除2分。

Google — Email sender guidelines

主题行 content.subject

长度、大小写和过滤器评分的模式。我们衡量的是解码后的主题,因此西里尔文字或中日韩文字的主题行会按文本而不是其编码进行判断。

如果失败: 将其控制在约 60 个字符以内,去掉大写喊话和感叹号。

扣除在我们的100分制评分中最多扣除3分。

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

短链接 content.url_shortener

链接是否经过公共短链接服务。短链接会隐藏目标地址,而过滤器正是被训练来怀疑这种行为的。

如果失败: 链接到你自己的域名,或在你的子域名上使用平台提供的跟踪域名。

扣除在我们的100分制评分中最多扣除5分 和 在经典10分制评分中最多扣除0.5分。

Google — Why Gmail marks messages as spam

批量发件人规则

Gmail 和 Yahoo 为所有批量发送邮件的发件人公布的要求。这些要求适用于群发邮件,对于看起来不像群发邮件的邮件则会跳过。

已发布 DMARC 策略 compliance.dmarc_present

From 域是否发布了 DMARC 记录,这与此邮件是否通过 DMARC 是两回事。Gmail 和 Yahoo 要求批量发件人提供该记录。

如果失败: 发布一条记录。p=none 足以满足要求,并会提供可供分析的报告。

扣除在我们的100分制评分中最多扣除6分。

RFC 7489 §6.3 — General Record Format

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records).

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

邮件是否包含邮件客户端可执行操作的退订标头。Gmail 和 Yahoo 要求批量发件人提供此标头,而且无论其他方面如何,缺少此标头都会被过滤。

如果失败: 添加包含 HTTPS URI 的 List-Unsubscribe 标头。所有发送平台都能做到这一点。

扣除在我们的100分制评分中最多扣除10分 和 在经典10分制评分中最多扣除1分。

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

一键退订 compliance.one_click_unsubscribe

更严格的形式:一个 HTTPS URI、一个“List-Unsubscribe-Post”标头,以及一个同时覆盖这两个标头的有效 DKIM 签名。三者缺一不可,否则接收方不会显示该按钮。

如果失败: 通常遗漏的是签名:平台会签署“List-Unsubscribe”,却忘记“List-Unsubscribe-Post”。这两个标头名称都必须出现在同一个签名的 h= 标签中。

扣除在我们的100分制评分中最多扣除8分。

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

建议

值得执行且从不计分。本节中的任何内容都不会导致扣分,这是由测试强制执行的产品决策。

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.