近日，一封来自某国际安全研究机构的报告在网络安全圈引发关注：邮件认证协议DMARC新引入的“NP”标签，在与DNSSEC（域名系统安全扩展）共同部署时，可能导致邮件验证失败或误判。这一问题直接影响了依赖双重安全机制的邮件系统的稳定性，甚至可能成为攻击者利用的新盲区。
DMARC的进化与“NP”标签的使命
DMARC（基于域的消息认证、报告与一致性）自2012年标准化以来，已成为对抗邮件欺诈、钓鱼攻击的核心手段。它通过DNS发布策略，告诉接收方如何处理未通过SPF或DKIM验证的邮件。传统DMARC策略分为三个等级：p=none（无动作）、p=quarantine（隔离）和p=reject（拒绝）。
然而，随着域名体系不断扩展，许多组织拥有大量子域，逐一为每个子域配置DMARC策略既不现实也易出错。为此，IETF在2023年更新的RFC中引入了新的np（no policy）标签。该标签允许父域为所有未显式设置DMARC策略的子域定义一个默认行为——例如，np=reject意味着所有子域的未验证邮件都将被拒绝。这一设计本意是简化安全管理，却无意中与DNSSEC的认证机制产生了深层冲突。
DNSSEC的“信任链”与DMARC查询的“盲区”
DNSSEC通过数字签名确保DNS查询结果的真实性和完整性。当邮件服务器查询子域的DMARC TXT记录时，若该域名启用了DNSSEC，则服务器会要求响应附带签名。问题恰恰出现在子域未配置DMARC时。
按照DMARC协议，若子域没有显式的DMARC记录，父域的np标签会生效。但在DNSSEC环境下，查询子域的DMARC记录时，服务器可能收到两种应答：一种是该子域不存在DMARC记录（通过DNSSEC的NSEC或NSEC3记录证明）；另一种是子域本身不存在（NXDOMAIN），同样通过DNSSEC证明。
第一种情况：子域存在但无DMARC记录。DNSSEC的NSEC记录会返回该子域的所有记录类型，明确显示没有TXT类型的DMARC记录。此时，DMARC验证器本应转向父域的np策略。但一些实现中的DNS解析器在处理NSEC记录时，可能会错误地将“没有DMARC记录”视为“该域不可达”或“查询失败”，从而中止流程，而非触发np标签。
第二种情况：子域不存在。DNSSEC同样会返回经过签名的NXDOMAIN指示。此时，np标签的触发机制与DNSSEC的认证之间存在时序问题。如果邮件服务器优先执行DNSSEC验证并得到“域不存在”的结论，它可能直接拒绝邮件，而忽略父域的np标签；反之，若优先执行DMARC逻辑，则会应用np策略，但后续DNSSEC验证又可能因域不存在而报错，造成策略矛盾。
现实案例：一次安全连锁反应
测试表明，某主流邮件安全网关在同时启用DNSSEC和DMARCnp=reject时，曾将来自合法第三方子域的正常邮件误判为欺诈邮件。原因是：该第三方子域在DNS中确实存在，但未配置DMARC记录；DNSSEC的NSEC记录正确返回了该事实，但网关的DMARC解析器未能正确解析NSEC记录中的类型信息，最终将查询状态标记为“失败”，而非“未找到策略”，进而触发了默认的p=none而非父域设置的np=reject，导致本应拦截的恶意邮件通过验证。
更具讽刺意味的是，攻击者可以利用这一歧义：通过注册一个不存在于父域但被DNSSEC签名覆盖的“幽灵子域”（利用NSEC记录的列举特性），诱导邮件服务器在DNSSEC验证和DMARC查询之间产生逻辑盲区，从而绕过np=reject的保护。
专家建议：并非不可调和
安全专家指出，问题的根源在于DMARC协议和DNSSEC协议在解析“不存在”这一状态时存在语义差异。DMARC的np标签依赖于对DNS响应的“存在性”判断，而DNSSEC的认证强度却可能干扰这一判断。
对于已部署或计划部署np标签的组织，建议采取以下措施：
- 升级DNS解析库：确保使用最新版本的DNS解析器，支持RFC 6840中关于DNSSEC与查询结果的一致处理，特别是正确处理NSEC类型。
- 细化子域策略：避免完全依赖
np标签，尽可能为关键子域单独配置显式DMARC记录，并独立签注DNSSEC。 - 测试环境先行：在生产环境启用
np前，在启用了DNSSEC的测试域名下进行全链路验证，模拟正常邮件和恶意邮件场景。 - 关注厂商更新：主要邮件安全厂商（如Cisco、Mimecast、Proofpoint）已开始发布针对此问题的补丁，应及时更新。
结语
DMARC的np标签本是为了简化管理，却在与DNSSEC的交织中暴露出新的复杂性。在邮件安全日益“零信任”化的今天，协议间的协同远比单一协议的正确性更重要。对于安全管理员而言，理解这些底层细节，才能避免让“更安全”变成“更脆弱”。