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

测试的工作原理

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

这里没有任何规则是我们将自己的看法包装而成的。如果检查执行的是某项标准中的规定,其下方会引用该标准的原文。如果检查执行的是 Google 或 Yahoo 的要求,则会链接到其相关页面。如果是我们自己的判断,则会明确说明。

更新时间:

检查分组我们的评分经典评分
ARC 链身份验证−20
DKIM 签名身份验证−18−1
DKIM 对齐身份验证−10−1
DMARC 结果身份验证−140
Sender ID身份验证−5−0.5
SPF身份验证−18−1
SPF 对齐身份验证−5−0.5
发送主机名可解析基础设施和信誉−5−3
阻止列表基础设施和信誉−25−3
HELO 名称基础设施和信誉−50
MX 记录基础设施和信誉−5−3
反向 DNS基础设施和信誉−12−1.5
传输加密基础设施和信誉−50
AI 判定垃圾邮件引擎
综合判定垃圾邮件引擎−250
Postmark SpamCheck垃圾邮件引擎
Rspamd垃圾邮件引擎
SpamAssassin垃圾邮件引擎0−3
图片替代文本内容−4−0.5
链接可用性内容−5−1
脚本和 iframe内容−10−1
文本与 HTML 的平衡内容−3−0.3
纯文本和 HTML 部分内容−50
HTML 大小内容−3−0.3
图片大小内容−3−0.3
可见链接的目标内容−30
链接信誉内容−400
附件扫描内容−600
预览文本内容−20
主题行内容−30
短链接内容−5−0.5
已发布 DMARC 策略批量发件人规则−60
List-Unsubscribe批量发件人规则−10−1
一键退订批量发件人规则−80
批量邮件的 TLS批量发件人规则−50
BIMI建议00
DKIM 密钥期限和长度建议00
DMARC 报告投递建议00
DNSSEC建议00
MTA-STS建议00
退信地址长度建议00
TLS 报告建议00

身份验证

接收服务器能否证明邮件确实来自其声称的来源。这是送达能力中完全依赖 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

内容

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

图片替代文本 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 9989 §4.7 — DMARC Policy Record Format

If this tag is not present in an otherwise syntactically valid DMARC Policy Record, then the record is treated as if it included "p=none".

Google — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

邮件是否带有邮件客户端可执行操作的退订标头。Gmail 和 Yahoo 要求群发发件人提供该标头,无论其他方面如何,缺少该标头都会触发过滤。此规则适用于群发邮件。要求收件人确认订阅或告知订阅已成功的邮件,是针对收件人刚刚执行的操作发送给单个人的邮件;CAN-SPAM 将其称为事务性或关系类邮件,Gmail 和 Yahoo 均不要求此类邮件提供退订标头。因此,此检查会先读取邮件内容。订阅确认邮件、欢迎邮件、事务性邮件或没有列表标头的通知不会被扣分,报告会说明该邮件被判定为何种类型。夹带优惠信息的欢迎邮件实际上是群发邮件的第一期;如果没有列表标头,检查无法区分两者,因此不会根据猜测扣分。如果邮件带有 List-Unsubscribe 或 List-Id,则表示你已自行声明其为列表邮件,检查会像以往一样运行。

如果失败: 添加包含 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 — Sender guidelines FAQ: rules for 5,000+ messages a day

Yahoo — Sender requirements and recommendations

一键退订 compliance.one_click_unsubscribe

更严格的形式:一个 HTTPS URI、一个 "List-Unsubscribe-Post" 标头,以及一个同时覆盖这两个标头的有效 DKIM 签名。三者缺一不可,否则接收方不会显示该按钮。与 List-Unsubscribe 检查一样,它适用于群发邮件,而不适用于确认邮件或欢迎邮件。

如果失败: 通常遗漏的是签名:平台签署了 "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 — Sender guidelines FAQ: rules for 5,000+ messages a 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 — 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.