Valimail：新 DMARC np= 标签如何封堵「不存在子域」仿冒

RFC 9989 修订的 DMARC 规范新增 np= 策略标签，专门面向 DNS 中并不存在的子域设定 DMARC 策略（none/quarantine/reject），堵住攻击者伪造 hr、payroll、invoices 等虚构子域发信的漏洞。

📖 原文翻译与解读。原文：What the new DMARC np= tag means for email security（Valimail，2026 年 7 月）

一、执行摘要

DMARC 仍在持续演进。RFC 9989（修订后的 DMARC 规范）引入了一个全新的可选策略标签 np=，专门用于「并不存在的子域」。表面上看这似乎多此一举——如果一个子域根本不存在，声称来自它的邮件难道不该被自动拦截吗？事实并非如此。

互联网邮件的一个怪癖是：用户可见的 From 地址中的域名，并不要求在 DNS 中真实解析。攻击者可以发送一封自称来自 ceo@payroll.company.com 的邮件，即便 payroll.company.com 从未存在过；同理也能凭空编造 billing@secure-login.company.com 之类地址。在 RFC 9989 之前，域名所有者并没有一个专门机制，为这些「不存在的子域」发布 DMARC 策略。

二、np= 标签的语义

RFC 9989 新增的 np= 标签，其取值与既有 DMARC 策略完全一致：可设为 none、quarantine 或 reject。它与另外两个标签共同构成分层策略：

这种粒度让域名所有者得以向接收方邮件服务商更精确地传达意图。

三、为什么应发布 np=reject

多数组织并不会把域名下所有可能的子域都创建出来，这意味着攻击者拥有一个事实上的无限命名空间来编造可信的发件地址：hr.company.com、payroll.company.com、invoices.company.com、executive.company.com。收件人无法判断这些子域是否合法，他们只看到一个熟悉的品牌。

发布 np=reject 等于告诉参与协作的接收方：如果一封邮件声称来自某个并不存在的子域，且未通过 DMARC 认证，则首选处理方式是拒收。这为滥用你品牌的仿冒者又增加了一道障碍。

四、np= 与 sp= 的区别

此前，答案取决于接收方如何解读 DMARC 规范。RFC 9989 通过给「不存在的子域」一个显式专属策略，消除了这种歧义：已委托的真实子域继续使用 sp=，不存在的子域现在可以用 np= 单独治理。

例如某组织发布 p=reject, sp=none, np=reject，它对邮件服务商的诉求是：拒收冒用组织域的仿冒邮件；允许已委托子域自行定义策略；拒收冒用「根本不存在的子域」的仿冒邮件。这种区分在以前是不可能实现的。

五、邮件系统防护启示

对邮件系统管理员与域名所有者：① 在既有 p=/sp= 之外，补上 np=reject，形成组织域、已存在子域、不存在子域三层全覆盖，最大化封堵品牌仿冒；② 需注意 np= 是「标准化表达意图」的补充信号，多个大型邮件服务商本就基于自身反滥用策略对不存在域名的邮件持怀疑态度，np= 让这一处理在协议层面可被明确要求；③ 与 SPF、DKIM 协同，np= 只是 DMARC 体系的一环，单靠它无法阻止钓鱼，但能为收件箱前的识别与拒收再添一层依据。详见 转发邮件为何破坏 SPF、DKIM 如何化解 与 BIMI AVP 标签。

参考来源

  1. Valimail — What the new DMARC np= tag means for email security
  2. IETF RFC 9989 — Domain-based Message Authentication, Reporting, and Conformance (DMARC)
  3. Valimail — Why forwarded emails break SPF (and how DKIM solves it)

了解更多行业资讯，请访问 行业资讯首页 或致电 021-69753778 获取安全咨询服务。

相关文章


—— ztpop.net 编辑团队 译