← RFC Reference

DMARC — 基于域的邮件身份验证、报告和符合性

为什么存在这个RFC

SPF和DKIM都很强大，但各自都有关键漏洞。SPF验证信封发件人域名，用户永远看不到。DKIM验证签名者选择的任何域名，可能是ESP的域名而非可见发件人。两者单独都无法防止攻击者伪造用户实际看到的From:头。

DMARC通过引入两个概念弥补了这一漏洞：

1. 标识符对齐：SPF或DKIM中至少有一个必须既通过且其认证域与From:头域对齐。
2. 域名所有者策略：域名所有者发布DNS记录，声明当对齐失败时接收方应采取的行动：监控（p=none）、隔离（p=quarantine）或拒绝（p=reject）。

DMARC还定义了聚合报告机制，允许域名所有者接收日报告，以XML格式显示其域名在互联网上如何被使用（和滥用）。

工作原理

DMARC评估流程

1. 邮件到达，From: user@example.com。
2. 接收方对信封发件人域名检查SPF。如果SPF通过且信封域与example.com匹配（或子域，取决于对齐模式），则SPF"对齐"。
3. 接收方检查DKIM。如果有效签名具有d=example.com（或子域），则DKIM"对齐"。
4. 如果SPF或DKIM中至少一个既通过且对齐，DMARC通过。
5. 如果DMARC失败，接收方查询_dmarc.example.com获取策略并应用。

DMARC DNS记录

实践中的对齐

关键技术细节

策略标签

对齐模式

宽松对齐（默认，adkim=r/aspf=r）：认证域与From:域共享同一组织域。例如，mail.example.com与example.com对齐。

严格对齐（adkim=s/aspf=s）：认证域必须完全匹配From:域。mail.example.com不与example.com对齐。

聚合报告（rua）

支持DMARC的接收方以XML格式向rua地址发送日聚合报告。这些报告包含：

• 使用您域名的发送IP地址
• 每个来源的SPF和DKIM通过/失败结果
• 应用的DMARC策略和处置（无、隔离、拒绝）
• 每个源IP的邮件计数

这些报告对于发现未授权发件人、识别配置错误的合法来源以及在将策略从none加强到reject前建立信心非常宝贵。

外部目标验证

如果您的rua或ruf地址在不同域名（例如，rua=mailto:reports@analytics.com），接收域必须发布DNS记录授权它：

没有此记录，报告发送方将不会向外部地址传递报告，这是防止将DMARC报告用作拒绝服务向量的保护措施。

常见错误

• 直接跳到p=reject：不先使用p=none监控就部署拒绝策略可能会无声地阻止来自忘记的来源（营销平台、CRM系统、代表您发送的SaaS应用）的合法邮件。始终从p=none开始，分析报告，修复对齐问题，然后升级。
• 遗漏子域策略：不设sp=，子域继承域策略。如果设置p=reject但子域发送邮件而没有正确认证，这些邮件将被拒绝。使用sp=独立控制子域策略。
• 未设置rua：没有聚合报告的DMARC形同瞎飞。报告告诉您谁以您的域名发送邮件以及认证是否正常工作。始终配置rua。
• 误解对齐：常见错误是认为SPF和DKIM通过就够了。它们还必须与From:头域对齐。如果您的ESP使用bounce@esp.com作为信封发件人并以d=esp.com签名DKIM，两者都不与您的From:头对齐，DMARC失败。
• 使用pct=0作"仅监控"：虽然pct=0技术上意味着"将策略应用于0%的失败"，但某些接收方的理解不同。使用p=none进行监控，而非pct=0配合更严格的策略。
• 邮件列表破损：传统邮件列表重写信封发件人但保留From:头，破坏SPF对齐，有时也破坏DKIM（如果列表修改邮件）。这是已知问题；ARC被创建来解决它。

投递能力影响

• 对批量发件方强制：自2024年2月以来，Gmail要求每天发送5000条以上邮件的域名拥有DMARC策略（至少p=none）。Yahoo有类似要求。这使DMARC对任何认真的发件方都是必需的。
• 品牌保护：p=reject策略防止攻击者在网络钓鱼活动中伪造您的域名。这保护您的客户和域名声誉。
• 改进收件箱投递：具有强DMARC策略（隔离或拒绝）的域名展示了认证成熟度。许多接收方将此纳入声誉评分。
• BIMI资格：品牌邮件标识（BIMI）要求DMARC策略为p=quarantine或p=reject。BIMI在支持的邮件客户端中显示邮件旁的品牌标志。
• 对邮件生态的可见性：聚合报告显示每个以您域名发送邮件的IP。仅这种可见性就值得部署DMARC，即使在p=none。

Related RFCs