From p=none to Enforcement: A Working Sequence for DMARC Rollout

从 p=none 到强制执行：DMARC 部署的工作序列

DMARC adoption is easy to start and hard to finish. Publishing a policy record takes minutes. Moving that policy to enforcement without blocking legitimate mail takes months of observation, and most stalled rollouts stall at the same point: the organisation has a p=none record, a monitoring report feed nobody reads, and no defined condition for moving to p=quarantine. This is a sequencing problem, not a standards problem. The specifications are stable and well documented.

DMARC 的采用易于开始，却难于完成。发布一条策略记录只需几分钟，但要在不拦截合法邮件的前提下将策略推进到强制执行阶段，则需要数月的观察。大多数停滞的部署都卡在同一个点上：组织拥有一个 p=none 记录，一个无人阅读的监控报告源，以及没有明确的进入 p=quarantine（隔离）阶段的条件。这是一个流程排序问题，而非标准问题。相关规范已经非常稳定且文档齐全。

The three records and what each does

三种记录及其作用

SPF (RFC 7208) authorises sending hosts by IP address. DKIM (RFC 6376) authorises messages by cryptographic signature. DMARC (RFC 7489) binds the two to the visible From domain and tells receivers what to do when neither passes. DMARC is the only one of the three that carries an enforcement instruction. SPF and DKIM both have alignment problems: a message can pass SPF for an envelope domain that does not match the From domain, and a DKIM signature can be valid for a domain the recipient never sees. DMARC closes that gap by requiring alignment with the From domain.

SPF (RFC 7208) 通过 IP 地址授权发送主机。DKIM (RFC 6376) 通过加密签名授权邮件。DMARC (RFC 7489) 将两者绑定到可见的“发件人”(From) 域名，并告知接收方在两者均未通过时该如何处理。在这三者中，只有 DMARC 携带强制执行指令。SPF 和 DKIM 都存在对齐问题：一封邮件可以通过与“发件人”域名不匹配的信封域名的 SPF 验证，而 DKIM 签名也可能对收件人从未见过的域名有效。DMARC 通过要求与“发件人”域名对齐，弥补了这一缺陷。

Why p=none becomes permanent

为什么 p=none 会变成永久状态

The failure mode is organisational. A p=none policy produces aggregate reports, and aggregate reports are XML files that are unreadable without tooling. Without a defined owner and a defined exit condition, the policy stays at p=none indefinitely. It looks like progress and enforces nothing. A rollout needs three things that a policy record does not provide: A named owner for the report feed, a documented list of legitimate sending sources (including third parties), and a written condition for each policy transition.

这种失败模式源于组织内部。p=none 策略会生成聚合报告，而这些报告是如果没有工具就无法阅读的 XML 文件。如果没有明确的负责人和明确的退出条件，策略就会无限期地停留在 p=none。这看起来像是在推进，但实际上并未执行任何操作。部署需要策略记录本身无法提供的三样东西：报告源的指定负责人、一份包含第三方在内的合法发送源清单，以及针对每次策略转换的书面条件。

Building the sending-source inventory

建立发送源清单

The inventory is the substantive work. For each source that sends mail as the domain, record: The sending service or host, and its business owner; whether it can be configured for SPF, DKIM, or both; whether it uses the organisational From domain or a subdomain; and the volume and the recipient population. Third-party senders deserve separate treatment. Marketing platforms, ticketing systems, CRM tools and payment processors frequently send on behalf of the domain and frequently cannot be configured for DKIM without a support request. Discovering them after moving to p=quarantine is the most common cause of a rollback.

清单编制是实质性工作。对于每个以该域名发送邮件的源，记录以下信息：发送服务或主机及其业务负责人；是否可以配置 SPF、DKIM 或两者兼有；是否使用组织域名或子域名；以及发送量和收件人群体。第三方发送方需要单独处理。营销平台、票务系统、CRM 工具和支付处理器经常代表该域名发送邮件，且通常在没有提交支持请求的情况下无法配置 DKIM。在进入 p=quarantine 后才发现它们，是导致回滚最常见的原因。

Subdomains are the other common gap. A DMARC record on the organisational domain does not automatically apply to subdomains unless a sp= tag sets a subdomain policy or a wildcard record covers them. Many organisations have forgotten subdomains that send mail.

子域名是另一个常见的漏洞。组织域名上的 DMARC 记录不会自动应用于子域名，除非通过 sp= 标签设置了子域名策略，或者有通配符记录覆盖它们。许多组织都遗忘了那些仍在发送邮件的子域名。

A transition sequence that holds up

一套经得起考验的转换序列

A sequence that survives contact with a real mail estate:

1. Publish p=none with rua= reporting.
2. Confirm reports are arriving and are being parsed.
3. Align SPF and DKIM for every known source. Fix alignment before changing policy. A source that passes SPF but fails alignment will fail DMARC.
4. Move to p=quarantine with a low percentage. The pct= tag allows partial application. Starting at a low percentage limits the blast radius of an unknown sender.
5. Increase pct= in steps. Each step should be followed by a defined observation period and a check of the aggregate reports for new failures.
6. Move to p=reject. Reject is the only policy that prevents delivery of unauthenticated mail using the domain. Add sp=reject for subdomains once subdomain senders are inventoried.

一套在真实邮件环境中经得起考验的序列：

1. 发布 p=none 并配置 rua= 报告。
2. 确认报告已送达并被解析。
3. 为每个已知源对齐 SPF 和 DKIM。在更改策略前先修复对齐。通过 SPF 但未通过对齐的源将无法通过 DMARC 验证。
4. 以低百分比进入 p=quarantine。pct= 标签允许部分应用。从低百分比开始可以限制未知发送方带来的影响范围。
5. 分步增加 pct=。每一步之后都应进行明确的观察期，并检查聚合报告中是否有新的失败记录。
6. 进入 p=reject。reject 是唯一能阻止使用该域名的未认证邮件投递的策略。一旦子域名发送方清单编制完成，为子域名添加 sp=reject。

Steps 3 through 5 are where the observation discipline matters. The reports are the control, not the policy record.

第 3 到第 5 步是观察纪律发挥作用的关键。报告才是控制手段，而非策略记录本身。

Where BIMI and other extensions fit

BIMI 及其他扩展的定位

BIMI (Brand Indicators for Message Identification) requires an enforced DMARC policy as a precondition, along with a Verified Mark Certificate. It is a downstream consumer of DMARC enforcement, not a substitute for it. Organisations that pursue BIMI before enforcement are optimising the logo next to a message that is not yet authenticated.

BIMI (品牌信息标识) 要求以强制执行的 DMARC 策略为前提，并需要验证标记证书 (VMC)。它是 DMARC 强制执行的下游应用，而非替代品。在强制执行前就追求 BIMI 的组织，是在为尚未认证的邮件优化旁边的 Logo。

Reading the reports without buying a platform

不购买平台如何阅读报告

Aggregate reports are XML and are defined in RFC 7489 Appendix C. They can be parsed with a short script, and the fields that matter for a rollout decision are limited: the source IP, the count, the SPF result, the DKIM result and the disposition. A rollout decision needs the count of messages that would fail under the proposed policy, grouped by source. That is a small amount of data extracted from a large amount of XML.

聚合报告是 XML 格式，定义在 RFC 7489 附录 C 中。它们可以通过简单的脚本解析，对部署决策至关重要的字段很有限：源 IP、计数、SPF 结果、DKIM 结果和处理方式。部署决策需要按源分组的、在拟议策略下会失败的邮件计数。这是从大量 XML 数据中提取出的少量关键信息。

Failure modes worth naming

值得注意的失败模式

• Enforcing before aligning: Moving to p=quarantine while a legitimate source still fails alignment causes delivery failures that look like an outage.

• Ignoring subdomains: The organisational domain enforces, the subdomain does not, and the subdomain is what a phishing campaign uses.

• Treating reports as a compliance artefact: If nobody reads the reports, the policy transition has no evidence behind it.

• Skipping the third-party inventory: External senders are the most common source of unexpected failures and the hardest to fix quickly because the fix usually depends on another organisation.

• 先强制执行后对齐： 在合法源仍未通过对齐时就进入 p=quarantine，会导致看起来像服务中断的投递失败。

• 忽略子域名： 组织域名执行了策略，但子域名没有，而钓鱼攻击往往利用子域名。

• 将报告视为合规性产物： 如果没人阅读报告，策略转换就失去了依据。

• 跳过第三方清单： 外部发送方是意外失败最常见的来源，且最难快速修复，因为修复通常依赖于其他组织。

What enforcement actually buys

强制执行的真正价值

An enforced DMARC policy does not stop all phishing. It stops unauthenticated mail that uses the domain in the visible From field. Attackers respond by moving to lookalike domains, display-name spoofing and compromised legitimate accounts. Those are different problems with different controls. What enforcement buys is a bounded, verifiable claim: mail claiming to be from the domain is either authenticated or rejected. That claim is worth having, and it is the precondition for a set of downstream controls including BIMI and stricter receiver-side handling. Getting there is a sequencing exercise with a report-reading discipline attached.

强制执行 DMARC 策略并不能阻止所有钓鱼攻击。它阻止的是在可见“发件人”字段中使用该域名的未认证邮件。攻击者会通过转向仿冒域名、显示名称欺诈和入侵合法账户来应对。这些是不同的问题，需要不同的控制手段。强制执行带来的价值是一个有界限、可验证的声明：声称来自该域名的邮件要么通过认证，要么被拒绝。这个声明非常有价值，它是包括 BIMI 和更严格的接收端处理在内的一系列下游控制的前提。实现这一目标是一个需要配合报告阅读纪律的流程排序练习。