DMARC发布13年：为何68.4%域名仍未强制执行邮件认证

一封邮件背后的信任危机

电子邮件仍是现代互联网最基础也最脆弱的通信协议之一。它诞生于一个默认信任的年代——发件人可以随意声称自己的身份，而接收方几乎没有验证机制。电子邮件的核心传输协议SMTP（Simple Mail Transfer Protocol）诞生于1982年的RFC 821，由Jon Postel和Suzanne Sluizer设计。当时的互联网（ARPANET）用户极为有限，参与者主要是学术机构和政府研究人员，彼此高度互信。SMTP的设计哲学遵循"宽容接收、严格发送"的Robustness原则，完全没有内建身份验证机制——任何人都可以在MAIL FROM字段填写任意地址，接收服务器不会也无法校验其真实性。这种设计在互联网商业化之后成为巨大的安全隐患，也是为什么40多年后我们仍需要在协议之上叠加SPF、DKIM、DMARC等补丁式认证层的根本原因。

这一根本缺陷，正是钓鱼攻击、商业邮件欺诈（BEC）和域名仿冒得以泛滥的技术温床。商业邮件欺诈是FBI互联网犯罪投诉中心（IC3）连续多年报告中损失金额最高的网络犯罪类型。2023年IC3报告显示，BEC相关投诉造成的损失超过29亿美元，远超勒索软件。典型BEC攻击中，攻击者伪装成CEO、CFO或供应商，通过伪造的邮件发件人地址指示员工进行电汇转账、修改付款账户信息或泄露敏感数据。由于这类攻击通常不携带恶意附件或链接，传统的反病毒和URL过滤难以检测，域名级别的身份认证成为最有效的第一道防线。

为了解决这一问题，业界在2012年公开发布了DMARC（Domain-based Message Authentication, Reporting and Conformance，基于域名的消息认证、报告与一致性）标准。然而13年过去，数据显示：仍有68.4%的域名没有真正强制执行DMARC策略。这意味着绝大多数域名依然对邮件伪造门户大开。

DMARC是什么：建立在SPF与DKIM之上的邮件认证框架

DMARC并不是一个孤立的技术，而是构建在两个更早的邮件认证机制之上：

• SPF（Sender Policy Framework）：通过DNS记录声明哪些IP地址有权代表某个域名发送邮件。具体来说，SPF通过在域名的DNS中发布一条TXT记录来工作，例如v=spf1 include:_spf.google.com ip4:203.0.113.0/24 -all。接收邮件服务器在收到邮件时，会检查SMTP会话中的MAIL FROM（信封发件人）地址对应的域名，查询其SPF记录，判断发送IP是否在授权范围内。SPF的关键局限包括：它验证的是信封发件人而非用户可见的From头，攻击者可以在信封层使用合法域名但在显示层伪造另一身份；邮件转发会改变发送IP，导致SPF在转发链中频繁失败；SPF记录的DNS查询次数限制为10次，复杂组织容易超出此限制导致验证失败。

• DKIM（DomainKeys Identified Mail）：使用加密签名验证邮件内容在传输过程中未被篡改，且确实来自声称的域名。DKIM使用非对称加密（通常为RSA-2048或Ed25519）来签名邮件。发送方的邮件服务器会对邮件头的指定字段和正文计算哈希值，然后用私钥加密生成签名，附在邮件头的DKIM-Signature字段中。接收方通过签名中指定的选择器（selector）和域名，从DNS查询对应的公钥，验证签名的完整性。DKIM能证明邮件内容未被篡改且确实经过了声称域名的邮件系统处理，但它的盲区在于：签名域名（d=标签）可以与用户看到的From地址完全不同，攻击者可以用自己的域名合法签名一封伪装成他人的邮件。

然而SPF和DKIM各自存在盲区。SPF在邮件转发场景下容易失效，DKIM则无法约束"发件人显示地址"（From头）与实际签名域名的一致性。DMARC的核心价值在于把这两者"粘合"起来，并引入了**对齐（alignment）**校验：只有当用户实际看到的发件域名与通过认证的域名一致时，邮件才算真正合法。

DMARC的对齐检查是其区别于SPF和DKIM的核心创新。对齐要求用户实际看到的From头域名必须与通过SPF认证的MAIL FROM域名或通过DKIM签名的d=域名相匹配。对齐有两种模式：严格模式（strict，标记为s）要求域名完全一致，而宽松模式（relaxed，标记为r，也是默认值）允许组织域名匹配即可——例如news.example.com的签名可以对齐example.com的From地址。只要SPF对齐或DKIM对齐中有一项通过，DMARC整体就判定为通过。这个机制确保了攻击者无法利用SPF和DKIM各自的盲区来绕过认证。

DMARC策略的三个等级：从监控到强制拒收

DMARC的另一大创新是它的策略指令（policy）和报告机制。域名管理员可以在DNS中发布一条p=策略，告诉全球接收方：当一封邮件未通过认证时该如何处理。

策略分为三档：

• p=none：仅监控、不采取任何拦截行动，通常用于观察期。
• p=quarantine：将可疑邮件投入垃圾箱。
• p=reject：直接拒收伪造邮件。

真正意义上的"强制执行"，指的是设置为quarantine或reject。而68.4%的域名没有做到这一点——它们要么根本没有部署DMARC记录，要么停留在p=none的观察阶段，从未真正开启防护。

为什么DMARC部署13年后进展依然缓慢

配置复杂度是首要障碍

DMARC的部署链条并不轻松。管理员需要先正确配置SPF和DKIM，再逐步收紧DMARC策略，并持续分析海量的聚合报告（aggregate reports）来排查合法邮件被误拦的风险。DMARC聚合报告（rua）是接收方邮件系统每日发送给域名管理员的XML格式报告，包含该域名在全球范围内的邮件认证统计。报告内容包括：发送IP地址、邮件数量、SPF和DKIM的通过/失败状态、对齐结果、以及接收方实际执行的处置动作。一个中等规模组织可能每天收到数十至数百份来自不同邮件服务商的报告，每份报告包含数百条记录。手动分析这些XML数据几乎不可能，这催生了Valimail、dmarcian、Agari（现为Fortra旗下）等专业DMARC报告分析平台的市场。

对于一个业务复杂、使用了多个第三方邮件服务（如营销平台、CRM、工单系统）的组织而言，任何一环遗漏都可能导致合法邮件被自己拦截。这种"改错了就断业务"的风险，让很多组织长期停留在p=none阶段——部署了、但从不敢真正启用强制策略。

缺乏直接的痛感驱动

与其他安全措施不同，未强制DMARC的损害往往不落在域名所有者自己身上，而是转嫁给被冒充的受害者——客户、合作伙伴或公众。这种外部性削弱了组织主动升级的动力。只要没有发生足够严重的品牌事故，p=none的现状就容易被无限期维持。

从博弈论的视角来看，邮件认证本质上是一个多方博弈系统。DMARC未强制执行的问题可以用"公地悲剧"和"负外部性"来解释：每个域名所有者不执行DMARC策略的成本由整个生态系统承担——被钓鱼的用户、被冒充的品牌、以及为处理垃圾邮件而投入资源的接收方。这种结构性的激励失调意味着，单靠市场力量难以推动全面采用，往往需要平台强制（如Google/Yahoo的政策）、行业监管（如PCI DSS 4.0对支付行业的DMARC要求）或重大安全事件作为催化剂。

认知与资源的双重不足

对于大量中小域名、个人站点和历史遗留系统，管理员可能根本不了解DMARC的存在，或缺乏专业能力去维护它。DNS记录一经设置便长期无人问津，成为互联网上沉默的安全短板。

68.4%未强制执行意味着什么

这个数字的严峻之处在于：邮件安全是一个接收方与发送方共同参与的博弈。即便主流邮件服务商（如Gmail、Outlook）已经在接收端严格校验DMARC，只要发送域名一方不发布强制策略，接收方也无从判断一封伪造邮件是否应被拒绝——它只能"猜"。

换句话说，未强制执行DMARC的域名，等于主动放弃了保护自己品牌不被冒充的权利。攻击者可以肆无忌惮地以该域名的名义发送钓鱼邮件，而全球的邮件系统在缺乏明确策略指令的情况下，往往会选择放行。

说个细节，Google和Yahoo已对批量发件人提出了强制DMARC要求。2024年2月起，Google和Yahoo正式实施了针对批量发件人（每日向Gmail/Yahoo用户发送超过5000封邮件的域名）的新要求：必须部署DMARC记录（至少p=none）、通过SPF和DKIM双重认证、且实现DMARC对齐。不满足要求的发件人会遭遇投递率显著下降或邮件被直接拒收。这一政策首次将DMARC从"最佳实践"提升为"准入门槛"，迫使大量此前忽视邮件认证的商业组织在短期内完成部署。然而这一要求的门槛仍然是p=none，距离真正的强制执行（reject/quarantine）还有相当距离，对于长尾的海量域名而言，这一压力尚未真正传导下去。

从p=none到p=reject：循序渐进的实施路径

对于希望改善现状的组织，可行的推进路径如下：

1. 先监控：以p=none部署DMARC记录，收集聚合报告，摸清所有代表本域名发信的合法来源。
2. 修复认证链：确保每一个合法发信源都正确通过SPF或DKIM验证，并满足对齐要求。
3. 逐步收紧：从p=quarantine过渡到p=reject，可配合pct参数分批次生效以降低风险。DMARC记录中的pct（percentage）参数允许管理员指定策略应用于多大比例的邮件。例如p=reject; pct=10意味着只有10%未通过认证的邮件会被拒收，其余90%仍按none处理。这为组织提供了一个安全的渐进路径：可以先设置pct=5观察一周，确认无合法邮件被误拦后逐步提高到25%、50%、100%。Google建议组织在每次调整后至少观察一周的聚合报告数据再继续收紧。
4. 持续运维：DMARC不是一次性任务，新增邮件服务、更换供应商都需要重新验证配置。

结语

DMARC公开13年，技术本身早已成熟，标准清晰、工具齐全。真正的瓶颈从来不是技术，而是配置门槛、组织惯性和责任外部性的叠加。68.4%这个数字提醒我们：一项好的安全标准存在多久，与它被真正落地执行，完全是两回事。

在钓鱼与身份仿冒攻击持续升级的当下，把DMARC策略从none推进到reject，或许是许多组织性价比最高、却最容易被忽视的一项邮件安全投资。

核心要点