直接答案：2026 年发布的 RFC 9989（DMARC 核心）、RFC 9990（聚合报告）、RFC 9991（失败报告）已经取代 2015 年的 RFC 7489（以及 RFC 9091），DMARC 从 Informational 变成 Standards Track / Proposed Standard。关键变化不是“再加一个 DNS 记录”，而是：用 DNS Tree Walk 取代 Public Suffix List 判断 Organizational Domain、增加 np/psd/t 标签、移除 pct/rf/ri、把聚合/失败报告拆成独立 RFC。对发信方最实际的动作仍是：SPF + DKIM 对齐 → p=none 收聚合报告 → 修复所有合法邮件流 → p=quarantine → p=reject；Google/Yahoo 对批量发信还要求 DMARC、From 对齐、one-click unsubscribe 和 spam rate < 0.3%。如果域名有真人用户会往邮件列表发信，不要直接上 p=reject：RFC 9989 明确建议先 p=none 至少 1 个月、再 p=quarantine 同样时长，并确保 p=reject 不只依赖 SPF、必须有有效 DKIM。
本文面向跨境电商/外贸独立站、SaaS、事务邮件和邮件营销团队，解释 DMARCbis（RFC 9989/9990/9991）的变化、记录写法、p=none→quarantine→reject 迁移、Google/Yahoo 批量发信要求、常见失败模式和 90 天落地清单。规则来自 IETF RFC 9989/9990/9991（2026 年发布）、Google Workspace 发信人指南、Yahoo Sender Best Practices，均于 2026-11-08 访问。本文把“官方规则事实”“编辑建议”和“待确认项”分开写，不构成法律或采购建议。
① DMARCbis 已是 Standards Track：RFC 9989/9990/9991 取代 7489；策略发现改用 DNS Tree Walk，旧接收方可能算出不同的 Organizational Domain——用严格对齐 + 每个 Author Domain 都发记录来消除歧义。② pct 被移除，不要再用百分比灰度；用 p=none→p=quarantine→p=reject 分阶段，或 t=y 测试模式（整体降一级）。③ 批量发信的最低线是 SPF+DKIM+DMARC、From 对齐、one-click unsubscribe、spam < 0.3%；p=reject 必须有 DKIM，不能只靠 SPF。
DMARCbis 变了什么：从 7489 到 9989/9990/9991
RFC 9989 是 DMARC 核心规范，RFC 9990 是聚合报告（rua），RFC 9991 是失败报告（ruf）；三者一起取代 RFC 7489，RFC 9989 还取代 RFC 9091。最重要的工程变化是策略发现：旧实现依赖 Public Suffix List 找 Organizational Domain，新规范用 DNS Tree Walk，并把 Public Suffix Domain（PSD）策略发现纳入；如果接收方还是旧实现，可能和发送方预期不一致。RFC 给出的规避方法是：对组织内所有 Author Domain 显式发布 DMARC 记录，并使用严格对齐。此外新增 np（不存在子域策略）、psd（PSD 标志）、t（测试模式）标签，移除 pct/rf/ri，报告格式拆到 9990/9991。
| 维度 | RFC 7489（旧） | RFC 9989/9990/9991（新） |
|---|---|---|
| 标准状态 | Informational | Standards Track / Proposed Standard |
| Organizational Domain | 依赖 Public Suffix List | DNS Tree Walk；含 PSD 策略发现 |
| 新增标签 | — | np、psd、t |
| 移除标签 | pct、rf、ri | 不再使用；报告拆分到 9990/9991 |
| 报告 | 核心文档内描述 | RFC 9990 聚合、RFC 9991 失败报告 |
| 互操作风险 | PSL 版本差异 | Tree Walk vs PSL 可能算出不同 Organizational Domain |
| 缓解 | — | 严格对齐 + 每个 Author Domain 显式记录 |
来源：IETF RFC 9989（2026，Appendix C “Changes from RFC 7489”）、RFC 9990、RFC 9991。表中为编辑整理；具体实现差异以接收方/工具文档为准。
记录怎么写：核心标签与示例
DMARC 记录仍是 DNS TXT：v=DMARC1; p=...; rua=...; ruf=...; fo=...; adkim=...; aspf=...; sp=...; np=...; t=...。p 是组织域策略，sp 是子域策略，np 是不存在子域策略；adkim/aspf 控制 DKIM/SPF 对齐（r=relaxed 默认，s=strict）；rua/ruf 是聚合/失败报告地址；fo 控制失败报告选项；t=y 是测试模式（把策略整体降一级，例如 p=reject+t=y 对失败邮件按 quarantine 处理）；psd=y 只适用于 Public Suffix Domain，普通域名不要设。pct 已移除，不要再写“pct=25”做灰度。
| 标签 | 作用 | 编辑建议 |
|---|---|---|
| v=DMARC1 | 版本 | 固定；必须是第一条 |
| p=none/quarantine/reject | 组织域策略 | 从 none 开始，按报告逐步升级 |
| sp= | 子域策略 | 子域多时单独评估；不设则继承 p |
| np= | 不存在子域策略 | 防子域伪造；按业务需要设置 |
| rua= | 聚合报告地址 | 至少一个；用专用邮箱/分析工具 |
| ruf= | 失败报告地址 | 可选；注意隐私与报告量 |
| fo= | 失败报告选项 | 常用 0/1/d/s；按排障需求 |
| adkim/aspf | DKIM/SPF 对齐 | r 默认；要消除 Tree Walk 歧义用 s |
| t=y | 测试模式 | 整体降一级；不能替代分阶段迁移 |
| psd=y | PSD 标志 | 仅 Public Suffix Domain 使用 |
| pct/rf/ri | 已移除 | 不要再依赖；用新标签/分阶段 |
来源：IETF RFC 9989（Section 4/6、Appendix C）与 RFC 9990/9991。表中为编辑整理；发布前用 DMARC 语法校验工具检查，避免一条错误记录导致整域策略失效。
迁移路径：p=none → quarantine → reject
RFC 9989 建议先用 p=none 进入 Monitoring Mode，靠 rua 聚合报告审计所有发信流；确认合法邮件都通过 SPF/DKIM 对齐后，再升级到 quarantine/reject。对有真人用户、会往 Internet 邮件列表发信的域名，RFC 明确建议先 p=none 至少 1 个月、再 p=quarantine 同样时长，比较处置结果后再决定 p=reject；并且 p=reject 不能只靠 SPF，必须有有效 DKIM。事务邮件/纯系统发信域名通常可以更快，但也要先看报告。
| 阶段 | 记录示例 | 进入/退出条件 |
|---|---|---|
| 监控 | v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r | 能收到报告；合法流清单完整 |
| 测试 | v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com | 想验证 reject 但先按低一级处置 |
| 隔离 | v=DMARC1; p=quarantine; sp=quarantine; rua=...; ruf=...; fo=1; adkim=s; aspf=s | 报告里合法邮件基本全通过；无大流量失败 |
| 拒绝 | v=DMARC1; p=reject; sp=reject; np=reject; rua=...; ruf=...; fo=1; adkim=s; aspf=s | 隔离期无合法邮件被拦；有 DKIM；应急回滚预案 |
| 子域 | 对每个 Author Domain 单独发记录；用 sp/np 控制 | 避免继承歧义；覆盖所有子域 |
编辑整理的迁移示例，不是官方模板；记录语法/策略以 RFC 9989 为准。p=none 至少 1 个月、p=quarantine 同样时长是 RFC 对有邮件列表用户域名的建议；纯事务域名可按报告质量缩短。
接收方要求：Google 与 Yahoo 的批量发信底线
Google 对个人 Gmail 账号：所有发信人至少 SPF 或 DKIM、PTR、TLS、spam rate < 0.3%、符合 RFC 5322；每天超过 5,000 封的批量发信人还要 SPF+DKIM+DMARC（p=none 允许）、From 域与 SPF/DKIM 对齐、营销/订阅邮件支持 one-click unsubscribe（List-Unsubscribe-Post + List-Unsubscribe）。Yahoo 对 bulk sender 同样要求 SPF+DKIM、DMARC 至少 p=none 且 DMARC pass、From 对齐（relaxed 可接受）、one-click unsubscribe（RFC 8058；也接受 mailto）、正文可见退订链接、2 天内处理退订、spam rate < 0.3%。这些是“进收件箱”的门槛，不是可选项。
| 要求 | Google（个人 Gmail） | Yahoo（bulk sender） |
|---|---|---|
| SPF/DKIM | 所有发信人 SPF 或 DKIM；5,000+/天 SPF+DKIM | 所有 SPF 或 DKIM；bulk SPF+DKIM |
| DMARC | 5,000+/天必须有；p=none 允许 | bulk 至少 p=none，且 DMARC pass |
| From 对齐 | From 域与 SPF 或 DKIM 对齐 | relaxed alignment 可接受 |
| One-click unsubscribe | 营销/订阅邮件必须；List-Unsubscribe-Post | 必须；RFC 8058 推荐，mailto 也可 |
| 退订处理 | 按 one-click 请求处理 | 2 天内处理；正文可见链接 |
| Spam rate | < 0.3% | < 0.3% |
| 其他 | PTR、TLS、RFC 5322；不得冒充 Gmail From | PTR、RFC 5321/5322 |
来源：Google Workspace“Email sender guidelines”（访问 2026-11-08）；Yahoo“Sender Best Practices”（访问 2026-11-08）。表中为编辑整理；“bulk”定义/执行细节以两家最新页面为准，规则可能更新。
常见失败模式：为什么有 DMARC 还是进垃圾箱
DMARC pass 只证明 From 域被授权，不保证内容/信誉/退订体验；常见失败是 SPF 超过 10 次 DNS 查询、DKIM 用 ESP 自己的域导致与 From 不对齐、子域没有记录而继承组织策略、邮件列表/转发破坏 SPF、旧接收方用 PSL 与新 Tree Walk 算出不同 Organizational Domain、以及还在用已移除的 pct。另一个高频问题是营销邮件没有 one-click unsubscribe，或退订请求没有在 2 天内处理。
| 失败模式 | 症状 | 控制 |
|---|---|---|
| SPF 查询超限 | permerror；部分流失败 | 减少 include、合并 SPF、用 DKIM 兜底 |
| DKIM 不对齐 | DMARC fail，即使 DKIM pass | 用自有域签名；检查 d= 与 From |
| 子域无记录 | 继承组织策略，误伤/漏保护 | 逐个子域发记录；用 sp/np |
| 邮件列表/转发 | SPF 断，DKIM 可能保留 | p=reject 前测试；确保 DKIM |
| Tree Walk 歧义 | 新旧接收方判断不同 | 严格对齐 + 每个 Author Domain 记录 |
| 仍用 pct | 策略不按预期生效 | 移除 pct；用分阶段/t=y |
| 无 one-click 退订 | 批量邮件被限流/判垃圾 | List-Unsubscribe-Post；2 天内处理 |
| 信誉/投诉率高 | spam rate > 0.3% | 清洗名单、确认订阅、监控 Postmaster/CFL |
编辑整理的常见故障，不是官方清单；具体 SPF/DKIM/DMARC 错误以 RFC 9989/7208/6376 和接收方报告为准。
90 天落地清单
先用 90 天把“域名/子域清单、SPF/DKIM 对齐、p=none 报告、修复合法流、one-click 退订、升级策略”串起来。顺序是：盘点 → 认证 → 监控 → 修复 → 隔离 → 拒绝 → 持续监控。不要一上来 p=reject；也不要在没有报告的情况下“永久 p=none”。
| 阶段 | 动作 | 产出 |
|---|---|---|
| 第 1–2 周 | 盘点所有发信域/子域/ESP/事务流/营销流 | 域名与流清单、owner |
| 第 2–3 周 | 补 SPF/DKIM；确认 DKIM d= 与 From 对齐；PTR/TLS | 认证基线、对齐报告 |
| 第 3–4 周 | 发布 p=none + rua；接 DMARC 分析工具/邮箱 | 聚合报告、基线 |
| 第 4–8 周 | 按报告修复合法流；处理列表/转发/子域 | 失败清单、修复记录 |
| 第 8–10 周 | 升级 p=quarantine；监控误伤；准备回滚 | 隔离期报告、回滚预案 |
| 第 10–12 周 | 升级 p=reject（确保 DKIM）；逐域推广 | 拒绝策略、监控 |
| 持续 | one-click 退订、spam rate、报告/告警、季度复核 | 月度复盘、SLA |
编辑整理的落地建议，不是官方模板；具体策略、报告工具、退订实现和接收方要求以 RFC 9989/9990/9991、Google/Yahoo 页面为准。
常见问题
DMARCbis 是什么？现在生效了吗？
DMARCbis 是 IETF 对 DMARC 的重写：RFC 9989（核心）、RFC 9990（聚合报告）、RFC 9991（失败报告），2026 年发布，取代 RFC 7489/9091。它是 Standards Track/Proposed Standard；接收方/工具会逐步实现，发送方应按新规范检查记录和策略。
RFC 9989 最大的变化是什么？
策略发现从 Public Suffix List 改为 DNS Tree Walk（含 PSD 策略），新增 np/psd/t 标签，移除 pct/rf/ri，报告拆到 9990/9991；旧接收方可能与新算法算出不同 Organizational Domain，建议严格对齐并为每个 Author Domain 显式发记录。
pct 还能用吗？
RFC 9989 移除了 pct；不要再用“pct=25”做灰度。要测试可用 t=y（整体降一级），或按 p=none→quarantine→reject 分阶段。
p=reject 是不是越早越好？
不是。先 p=none 收报告、修复合法流；有邮件列表用户的域名，RFC 建议 p=none 至少 1 个月、p=quarantine 同样时长后再考虑 p=reject。p=reject 不能只靠 SPF，必须有有效 DKIM。
DMARC 能保证进收件箱吗？
不能。DMARC 只验证 From 域授权，不保证内容、信誉或退订体验；Google/Yahoo 还看 spam rate < 0.3%、one-click unsubscribe、PTR/TLS 等。DMARC 是必要条件，不是全部。
Google/Yahoo 的批量门槛是多少？
Google 对每天超过 5,000 封到个人 Gmail 的发信人要求 SPF+DKIM+DMARC、From 对齐、one-click unsubscribe；Yahoo 对 bulk sender 要求 SPF+DKIM、DMARC 至少 p=none、From 对齐、one-click/2 天内退订。具体定义/执行以两家页面为准。
子域要不要单独发 DMARC？
建议要。子域不设记录会继承组织域策略；用 sp 控制子域、np 控制不存在子域。RFC 9989 还建议对每个 Author Domain 显式发记录，避免 Tree Walk/PSL 差异导致误判。
one-click unsubscribe 怎么做？
营销/订阅邮件加 List-Unsubscribe-Post: List-Unsubscribe=One-Click 和 List-Unsubscribe: <https://...>，实现无页面 POST 退订；Yahoo 还要求正文可见退订链接并在 2 天内处理。事务邮件是否加按业务/接收方规则决定。
研究方法与局限
本文把“官方规则事实”和“编辑建议”分开：RFC 9989/9990/9991 的标准状态、DNS Tree Walk、PSD、np/psd/t、pct/rf/ri 移除、报告拆分、p=reject 的 DKIM/邮件列表注意事项，来自 IETF RFC 9989（2026，Appendix C）与 9990/9991；Google 的 5,000 封/天、SPF+DKIM+DMARC、From 对齐、one-click、spam < 0.3%、PTR/TLS/RFC 5322，来自 Google Workspace 发信人指南；Yahoo 的 bulk SPF+DKIM、DMARC 至少 p=none、relaxed 对齐、RFC 8058/2 天退订、spam < 0.3%，来自 Yahoo Sender Best Practices。迁移阶段、90 天清单和失败模式为编辑整理。
局限有八个：① 不构成法律/合规建议；② 未逐家接收方核对 DMARCbis 实现进度；③ 未覆盖所有 ESP/工具的记录语法差异；④ 未展开 SPF 10 次查询、DKIM 密钥轮换、ARC/转发等细节；⑤ 未评估 DMARC 报告工具的隐私/成本；⑥ 未覆盖 BIMI/VMC；⑦ 未做真实发信测试/信誉数据；⑧ Google/Yahoo 规则可能更新，实施前应复核官方页面。
数据来源与口径
- IETF RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC)（2026）：rfc-editor.org/rfc/rfc9989。核心规范、DNS Tree Walk、np/psd/t、pct/rf/ri 移除、Appendix C 变更。访问 2026-11-08。
- IETF RFC 9990, DMARC Aggregate Reporting（2026）：rfc-editor.org/rfc/rfc9990。聚合报告格式/发送。访问 2026-11-08。
- IETF RFC 9991, DMARC Failure Reporting（2026）：rfc-editor.org/rfc/rfc9991。失败报告。访问 2026-11-08。
- Google Workspace, Email sender guidelines：support.google.com/a/answer/81126。所有发信人/5,000+ 批量要求、one-click、spam rate。访问 2026-11-08。
- Yahoo, Sender Best Practices：senders.yahooinc.com/best-practices。bulk SPF/DKIM/DMARC、one-click/退订时限、spam rate。访问 2026-11-08。
资料截止 2026-11-08；DMARC/发信要求以 IETF RFC、Google/Yahoo 最新页面为准；本文不构成法律、合规或采购建议。