域名已经有 SPF 或 DKIM，下一步准备配置 DMARC 时，最容易混淆的是“检查结果”和“处理策略”。生成器里的 none、quarantine、reject 是向收件系统表达的处理请求，不是检测按钮；选择后出现一行记录，也不代表邮件认证已经通过。

下面用宝塔拨测的 DMARC 记录生成器演示。域名使用 example.com，邮箱使用虚构的 dmarc@example.com，本次没有发布 DNS、发送测试邮件或接收报告。

现行 DMARC 核心规范是 2026 年 5 月发布的 RFC 9989，已取代 RFC 7489。当前生成器仍保留了旧规范里的部分选项，下面会把可用的主示例与旧字段的输出分开说明，不能把表单中的每一项都当成现行标准。

先生成带聚合报告地址的 none 策略

进入「站长工具 → DMARC 记录生成」，填写域名 example.com。协议版本保持 DMARC1，过滤比例留空，并清空默认的报告间隔；「聚合报告」填 dmarc@example.com，取证报告先留空，策略选择 none · 监控。

使用 none 策略和聚合报告邮箱，页面实时生成 DMARC 文本
使用 none 策略和聚合报告邮箱，页面实时生成 DMARC 文本

本次生成内容是：

v=DMARC1;p=none;rua=mailto:dmarc@example.com

输入后文本会自动更新。邮箱框里填普通邮箱地址，工具会补上 mailto:；不要因为输出中带了这个前缀，就在输入框里重复填写。

其中 p=none 请求收件方不因该 DMARC 策略对邮件采取特定的投递处置，适合先观察认证情况。但它没有取消收件方其他反垃圾或安全规则，也不等于所有邮件都会进入收件箱。

rua 指向聚合报告接收地址，报告用于汇总观察发信来源和认证结果。聚合报告通常按天或更频繁地提供，但是否收到、何时收到，仍要看收件方的支持与实际发送。这里清空报告间隔，是因为该框生成的 ri 已从现行规范中移除，不能靠它指定报告时间。

正式使用前，需要准备可接收并处理报告的专用邮箱。本例邮箱只是演示文本，不能复制后期待它替你的域名收集数据。

核对的是 _dmarc 主机记录，不是根域 TXT

查看页面下方的「DMARC 记录预览」。本次显示类型 TXT，主机 _dmarc，值与上面的生成文本一致，完整记录名为 _dmarc.example.com。

记录预览显示 TXT 类型、_dmarc 主机及对应记录值，这里尚未执行 DNS 发布
记录预览显示 TXT 类型、_dmarc 主机及对应记录值，这里尚未执行 DNS 发布

在按区域填写相对主机名的 DNS 控制台中，主机通常填 _dmarc；若产品要求完整名称，则按其规则填写。关键是最终名称正确，避免把域名自动拼接两次，或误把 DMARC 内容加在根域的 @ 记录上。

正式发布前先检查现有 _dmarc TXT，确认是否已有策略需要调整，不要直接并列新增另一条不同策略。页面标题虽然写着“发布到 DNS”，这里展示的仍是操作说明和记录预览，没有连接你的 DNS 账号替你保存配置。

表单还能生成 pct 和 ri，但不要依赖它们控制上线

为了核对旧字段的实际表现，将策略改为 quarantine · 隔离，过滤比例填 25，报告间隔填 86400，其余不动。本次页面确实生成：

v=DMARC1;p=quarantine;pct=25;rua=mailto:dmarc@example.com;ri=86400
页面仍能生成 pct=25 和 ri=86400，这两项不能作为现行标准的执行保证
页面仍能生成 pct=25 和 ri=86400，这两项不能作为现行标准的执行保证

quarantine 表达域名所有者对未通过 DMARC 邮件的可疑判断，收件方可能将其隔离等处理。pct=25 在旧 RFC 7489 中用于请求按比例应用策略，ri=86400 用于请求聚合报告间隔；它们有历史含义，但现行 RFC 9989 已移除 pct 和 ri。

因此，不能用当前页面生成的 pct=25 保证只有 25% 的失败邮件受到隔离，也不能用 ri 保证每隔指定时间收到报告。不能识别的标签会被忽略，具体接收方采用哪种实现也没有在本次测试中验证。字段仍能生成，不等于外部邮件系统会执行。

复制到新配置前，应审阅并移除这些旧标签，优先在生成器里清空对应输入，再确认最终输出已不含 pct 和 ri。日常先观察时，可以像主示例一样将这两项留空，使用 p=none 与实际的聚合报告地址。不要把“none”与“25%隔离”混为一谈，也不要因为清除了旧字段就直接把策略改成 reject。页面当前没有提供所有现行字段的配置入口，如需更完整的策略，应按邮件服务商和现行规范另行核对，不能靠猜测补参数。

准备收紧策略前，应根据报告检查业务系统和第三方代发等合法来源，修正认证与域名对齐问题，再评估影响。此处切换只用于查看生成器行为，没有改变任何真实收件行为。

SPF 失败，不一定意味着 DMARC 失败

DMARC 不要求 SPF 和 DKIM 同时通过，而是至少有一项认证通过，并且该项认证使用的域名与邮件 From 域名满足对齐要求。因此，SPF 失败而对齐的 DKIM 通过，DMARC 仍可能通过；反过来，某项认证显示 Pass，如果域名不对齐，也不能直接当成 DMARC Pass。

排查报告时，应一起看发信 IP、SPF、DKIM、对齐域名和 DMARC 结果，不要只根据一个失败字段就把发信服务器全部替换或扩大授权。

取证报告对应 ruf，与聚合报告的 rua 不是同一项。本次填写虚构的 dmarc-forensic@example.com 后，工具另外生成了 ruf=mailto:dmarc-forensic@example.com。是否提供这类报告取决于收件方支持和策略，不能因为写入邮箱就期待每封失败邮件都有报告。使用第三方报告域名时，还需按服务商要求核对外部报告接收授权。

完成真实 DNS 配置后，再查询公开的 _dmarc TXT，并结合实际邮件头和收到的报告验收。DMARC 可以表达策略和提供反馈，不能单凭一条记录承诺送达率，也不能证明域名从此不会被仿冒。