非官方中文译本声明：本页为 IETF RFC 7489《Domain-based Message Authentication, Reporting, and Conformance (DMARC)》 的中文译本，由 ztpop.net 整理翻译，仅供学习参考。RFC 文档由 IETF 发布，受 BCP 78 与 IETF 信托法律条款约束；本译本保留原文编号与结构，权威性以英文原文为准。英文原文见 rfc-editor.org/rfc/rfc7489。

RFC 7489：基于域的消息认证、报告与一致性（DMARC）

独立提交 · M. Kucherawy（主编）、E. Zwicky（主编）· Yahoo! · 2015 年 3 月 · 类别：Informational（信息类）· ISSN: 2070-1721

摘要

基于域的消息认证、报告与一致性（DMARC）是一种可扩展的机制，邮件发起组织可借此表达关于消息验证、处置与报告的域级策略与偏好，而邮件接收组织可利用这些信息改进邮件处理。

互联网邮件的发起者需要能够将可靠且经过认证的领域标识符与消息相关联，就使用这些标识符的消息传达策略，并对使用这些标识符的邮件进行报告。这些能力带来若干好处：接收方能够就域名的使用情况向域名所有者提供反馈；这种反馈能够为内部管理以及外部域名滥用情况提供有价值的洞察。

DMARC 并不会为经过认证的电子邮件赋予或鼓励更高的投递特权。DMARC 是一种策略分发机制，能够对未通过认证检查的邮件实施越来越严格的处理，范围从未采取任何措施，到改变投递方式，直至拒收邮件。

本备忘录的状态

本文档并非互联网标准跟踪规范，而是出于 informational（信息性）目的而发布。

本文是对 RFC 系列的贡献，独立于任何其他 RFC 流。RFC 编辑已自行决定发布本文档，且不对其实作或部署价值作出任何声明。经 RFC 编辑批准发布的文档并非任何级别互联网标准的候选；参见 RFC 5741 第 2 节。

有关本文档当前状态、任何勘误以及如何提供反馈的信息，可在 http://www.rfc-editor.org/info/rfc7489 获取。

Copyright (c) 2015 IETF 信托及被列为文档作者的个人。保留所有权利。

本文档受 BCP 78 以及 IETF 信托的《IETF 文档相关法律规定》（http://trustee.ietf.org/license-info）约束，以本文档发布之日生效的版本为准。请仔细审阅这些文档，因为它们描述了您就本文档所享有的权利与限制。

目录

1. 引言

发送方策略框架（[SPF]）与域名密钥识别邮件（[DKIM]）提供域级认证。它们使协作的电子邮件接收方能够检测出被授权使用该域名的邮件，从而允许进行差异化处理。（关于这些系统试图应对的威胁的详细讨论，见 [DKIM-THREATS]。）然而，目前还没有一种被广泛接受或公开可用的单一机制，用于向接收方传达特定域的消息处理策略，或请求对收到的邮件进行认证与处置的报告。若无法获得反馈报告，已实现电子邮件认证的发起者很难判断其认证的有效性。因此，利用认证失败来过滤邮件通常难以成功。

随着时间的推移，某些发送方与接收方之间建立了一对一的关系，通过私下沟通的方式来断言策略，并接收消息流量与认证处置报告。尽管这些临时性的做法总体上是成功的，但它们需要各方之间进行大量人工协调，而这种模式无法扩展到整个互联网的普遍使用。

本文档定义了基于域的消息认证、报告与一致性（DMARC），一种电子邮件运营者借以利用现有认证与策略通告技术，从而既能实现消息流的反馈、又能对未认证电子邮件实施策略强制的机制。

DMARC 使域名所有者与接收方能够通过以下方式开展协作：

  1. 向接收方提供关于域名所有者策略的断言；
  2. 向发送方提供反馈，使其能够监控认证并判断威胁。

DMARC 的基本轮廓如下：

  1. 域名所有者通过 DNS 发布关于域的策略断言。
  2. 接收方将邮件中的 RFC5322.From 地址与 SPF 和 DKIM 结果（若存在）以及 DNS 中的 DMARC 策略进行比对。
  3. 这些接收方可利用这些结果来决定应如何处理该邮件。
  4. 接收方向域名所有者或其指定方发送关于声称来自其域的邮件的报告。

本文档中使用的安全术语在 [SEC-TERMS] 中定义。

DMARC 与此前策略通告方法（例如 [SPF] 与 [ADSP]）的不同之处在于：

DMARC 的运营经验揭示了与电子邮件整体相关的一些互操作性问题，在部署前需要适当考量，尤其是那些可能导致邮件被拒收的配置。这些内容在第 10 节讨论。

2. 需求

DMARC 的规范由以下高层目标、安全依赖、详细需求，以及被记录为范围之外的条目所指导。

2.1. 高层目标

DMARC 具有以下高层目标：

2.2. 范围之外

若干主题与问题在该工作的初始版本中明确属于范围之外。包括以下内容：

2.3. 可扩展性

对于需要在如同当前 SMTP 电子邮件这样广泛部署的系统中运作的系统而言，可扩展性是一个主要问题。因此，DMARC 力求避免对第三方或发送方与接收方之间发送前协议的需求。这保留了当前电子邮件基础设施的积极方面。

尽管 DMARC 并未向邮件处理流程引入第三方发送方（即被授权代表某运营者发送的外部代理），但它也不排除这种代理。此类第三方可自由提供与 DMARC 配合的服务。

2.4. 反钓鱼

DMARC 旨在防止不良行为者发送声称来自合法发送方（尤其是交易类电子邮件的发送方，即关于业务交易的官方邮件）的邮件。此类伪造邮件的主要用途之一是钓鱼（通过假装是请求信息的合法服务来诱使用户提供信息）。因此，DMARC 深受正在进行的、制定大规模全网反钓鱼措施的努力的影响。

尽管 DMARC 只能直接用于打击特定形式的精确域名伪造，但 DMARC 机制已被发现有助于创建可靠且可辩护的消息流。

DMARC 并不试图解决伪造或其他欺诈性电子邮件的所有问题。特别是，它不涉及视觉相似域名（"表亲域名"）的使用，也不涉及对 RFC5322.From 人类可读的 <display-name> 的滥用。

3. 术语与定义

本节定义文档其余部分使用的术语。

本文档中的关键词"MUST（必须）"、"MUST NOT（不得）"、"REQUIRED（要求）"、"SHALL（应）"、"SHALL NOT（不应）"、"SHOULD（应该）"、"SHOULD NOT（不应该）"、"RECOMMENDED（推荐）"、"MAY（可以）"和"OPTIONAL（可选）"应按照 [KEYWORDS] 中的描述进行解释。

鼓励读者熟悉 [EMAIL-ARCH] 的内容。特别是，该文档定义了消息基础设施中各种角色，这些角色在不同上下文中可能相同或分离。例如，域名所有者可以通过 DMARC 所基于的消息安全机制，将作为域名所有者发送邮件的能力委托给具有另一角色的第三方。本文档不处理此类角色之间的区别；鼓励读者在继续之前熟悉该材料。

还使用了以下术语：

Authenticated Identifiers（已认证标识符）：使用认证技术验证的域级标识符称为"已认证标识符"。有关所支持机制的细节，见第 4.1 节。

Author Domain（作者域）：从 RFC5322.From 字段提取的、 apparent author（表观作者）的域名。

Domain Owner（域名所有者）：拥有某个 DNS 域的实体或组织。此处"拥有"一词表示该被引用的实体或组织持有该 DNS 域的注册。域名所有者既包括复杂、全球分布的组织，也包括代表非技术客户工作的服务提供商，还包括负责维护个人域的个人。本规范使用该术语，类似于 [EMAIL-ARCH] 中定义的行政管理域（Administrative Management Domain）。当报告接收方等委托方处于其直接管理域之外时，该术语也可指代此类委托方。

Identifier Alignment（标识符一致性）：当 RFC5322.From 地址中的域名与 SPF 或 DKIM（或两者）验证过的域名匹配（对齐）时，即具有标识符一致性。

Mail Receiver（邮件接收方）：接收并处理电子邮件的实体或组织。邮件接收方运营一个或多个面向互联网的邮件传输代理（MTA）。

Organizational Domain（组织域）：在域名注册商处注册的域名。在没有更准确方法的情况下，采用启发式方法来确定它，因为已注册的域名并不总是简单地等于一个顶级 DNS 域加一个组成部分（例如"example.com"，其中"com"是顶级域）。组织域通过应用第 3.2 节中的算法来确定。

Report Receiver（报告接收方）：从另一个运营者处接收报告的运营者，该运营者实做了本文档描述的报告机制。此类运营者可能正在接收关于其自身消息的报告，或关于与另一个运营者相关的消息的报告。该术语统称接收并处理这些报告的系统组件，以及运营它们的组织。

3.1. 标识符一致性

电子邮件认证技术对单个消息的各个（且不同的）方面进行认证。例如，[DKIM] 认证向消息附加签名的域名，而 [SPF] 可以认证出现在 [SMTP] 的 RFC5321.MailFrom（MAIL FROM）部分或 RFC5321.EHLO/HELO 域名中的域名，或两者兼有。这些可能是不同的域名，并且通常对最终用户不可见。

DMARC 通过要求 RFC5322.From 域名与某个已认证标识符匹配（对齐）来对该域名的使用进行认证。选择 RFC5322.From 域名作为 DMARC 机制的核心身份，是因为它是一个必需的消息头字段，因此在合规消息中保证存在；并且大多数邮件用户代理（MUA）将 RFC5322.From 字段表示为消息的发起者，并向最终用户呈现该头字段的部分或全部内容。

因此，该字段是最终用户用来识别消息来源的依据，因而成为滥用的主要目标。许多高知名度的电子邮件源（例如电子邮件服务提供商）要求发送代理在生成电子邮件之前已完成认证。因此，对于这些邮箱，本文档描述的机制为收件人最终用户提供了强有力的证据，表明该消息确实由他们与该邮箱相关联的代理所发起——前提是最终用户知道已提供了这些各种保护措施。

在此上下文中，域名应按照 [DNS-CASE] 以不区分大小写的方式进行比对。

需要注意的是，对于不符合 [MAIL] 的消息，特别是那些 RFC5322.From 字段格式错误、缺失或重复的邮件，不可能出现标识符一致性，因为在这种情况下没有可靠的方法来确定适用于该消息的 DMARC 策略。因此，DMARC 的运行以输入为有效的 RFC5322 消息对象为前提，对此类不合规情况的处理不在本规范的范围之内。进一步讨论见第 6.6.1 节。

DMARC 作为输入所依赖的每种底层认证技术，在成功时都会产出已认证的域名作为输出。从 DMARC 的视角看，每种技术都可以在"严格（strict）"模式或"宽松（relaxed）"模式下运行。如果域名所有者希望邮件接收方仅对承载的 RFC5322.From 域名与这些机制将验证的域名完全匹配的邮件应用 DMARC 处理，通常会选择严格模式。当运营者还希望影响承载已验证域名的子域的消息流时，可使用宽松模式。

3.1.1. DKIM 认证的标识符

DMARC 允许基于 DKIM 认证结果的标识符一致性为严格或宽松。（注意，这与 DKIM 的"simple"和"relaxed"规范化模式无关。）

在宽松模式下，要使标识符被视为对齐，[DKIM] 认证的签名域名（取自签名中"d="标签的值）的组织域与 RFC5322.From 域名的组织域必须相等。在严格模式下，仅当两个完全限定域名（FQDN）精确匹配才被视为产生标识符一致性。

举例说明：在宽松模式下，如果经过验证的 DKIM 签名以"d="域名"example.com"成功验证，且 RFC5322.From 地址为"alerts@news.example.com"，则 DKIM 的"d="

域名与 RFC5322.From 域名被视为"对齐"。在严格模式下，该测试会失败，因为"d="域名与地址的 FQDN 并不完全匹配。

然而，带有"d=com"值的 DKIM 签名永远不会产生"对齐"结果，因为"com"应出现在所有公共后缀列表中（见附录 A.6.1），因此不能是组织域。

需要标识符一致性，是因为一条消息可以携带来自任何域的有效签名，包括邮件列表甚至不良行为者使用的域。因此，仅携带有效签名不足以推断作者域的真实性。

注意，一封电子邮件可以包含多个 DKIM 签名，只要任一 DKIM 签名对齐并通过验证，即被视为 DMARC"通过"。

3.1.2. SPF 认证的标识符

DMARC 允许基于 SPF 认证结果的标识符一致性为严格或宽松。

在宽松模式下，[SPF] 认证的域名与 RFC5322.From 域名必须具有相同的组织域。在严格模式下，仅当 DNS 域名精确匹配才被视为产生标识符一致性。

注意，RFC5321.HELO 身份通常不在 DMARC 上下文中使用（除非需要"伪造"一个原本为空的逆向路径），尽管根据 [SPF] 的"纯 SPF"实现会检查该标识符。

例如，如果一条消息以 RFC5321.MailFrom 域名"cbg.bounces.example.com"通过 SPF 检查，且 RFC5322.From 字段的地址部分包含"payments@example.com"，则已认证的 RFC5321.MailFrom 域标识符与 RFC5322.From 域在宽松模式下被视为"对齐"，但在严格模式下不是。

3.1.3. 一致性与扩展技术

如果将来 DMARC 被扩展为包含其他认证机制的使用，这些扩展将需要允许提取域标识符，以便能够验证与 RFC5322.From 域的一致性。

3.2. 组织域

组织域使用以下算法确定：

  1. 获取"公共后缀"列表，即保留用于注册的 DNS 域名列表。某些国家顶级域（TLD）有特定的注册要求，例如英国将公司注册置于".co.uk"之下；其他 TLD 如".com"出现在 IANA 的顶级 DNS 域注册表中。公共后缀列表是所有这些的并集。附录 A.6.1 包含一些关于获取公共后缀列表的讨论。
  2. 将目标 DNS 域名拆分为一组"n"个有序标签。从右到左对这些标签编号；例如，对于"example.com"，"com"为标签 1，"example"为标签 2。
  3. 在公共后缀列表中搜索与目标 DNS 域名中找到的最多标签数相匹配的名称。令该数字为"x"。
  4. 使用从公共后缀列表匹配到的名称，并在其前面加上来自目标域的"x+1"号标签，构造一个新的 DNS 域名。这个新名称就是组织域。

因此，由于"com"是 IANA 注册的 TLD，目标域"a.b.c.d.example.com"的组织域将为"example.com"。

确定后缀的过程目前是一种启发式方法。没有任何列表被保证是准确或最新的。

4. 概述

本节提供 DMARC 环境设计与运行的总体概述。

4.1. 认证机制

本版本 DMARC 支持以下用于确定已认证标识符的机制：

4.2. 关键概念

DMARC 策略由域名所有者发布，并由邮件接收方在 SMTP 会话期间通过 DNS 检索。

DMARC 的过滤功能基于 RFC5322.From 字段域名是否与来自 SPF 或 DKIM 的已认证域名对齐（匹配）。当为 RFC5322.From 字段中找到的域名发布了 DMARC 策略，且该域名未通过 SPF 或 DKIM 验证时，在投递到参与的接收方时，该消息的处置可能受到该 DMARC 策略的影响。

需要注意的是，DMARC 所采用的认证机制仅认证 DNS 域名，并不认证消息中发现的任何电子邮件地址标识符的 local-part（本地部分），也不验证消息内容的合法性。

DMARC 的反馈组件涉及收集关于声称来自组织域的收到消息的信息，用于定期向域名所有者发送聚合报告。此类报告的参数与格式在本文档后续章节讨论。

支持 DMARC 的邮件接收方也可能生成逐消息报告，其中包含与未通过 SPF 和/或 DKIM 的个别消息相关的信息。当调试部署（如果消息即使认证失败也可确定为合法）或分析攻击时，逐消息失败报告是有用的信息来源。此类服务的能力由 DMARC 启用，但定义在其他引用材料中，例如 [AFRF]。

如果至少一种受支持的认证机制满足以下条件，则消息通过 DMARC 检查：

  1. 产生"pass（通过）"结果；且
  2. 基于如第 3 节所定义的、处于对齐状态的标识符产生该结果。

4.3. 流程图

 +---------------+
 | Author Domain |< . . . . . . . . . . . . . . . . . . . . . . .
 +---------------+                        .           .         .
        |                                    .           .         .
        V                                    V           V         .
    +-----------+     +--------+       +----------+ +----------+   .
    |   MSA     |<***>|  DKIM  |       |   DKIM   | |    SPF   |   .
    |  Service  |     | Signer |       | Verifier | | Verifier |   .
    +-----------+     +--------+       +----------+ +----------+   .
        |                                    ^            ^        .
        |                                    **************        .
        V                                                 *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
     | sMTA |------->( other MTAs )----->| rMTA |         *        .
     +------+        (~~~~~~~~~~~~)      +------+         *        .
                                            |             * ........
                                            |             * .
                                            V             * .
                                     +-----------+        V V
                       +---------+   |    MDA    |     +----------+
                       |  User   |<--| Filtering |<***>|  DMARC   |
                       | Mailbox |   |  Engine   |     | Verifier |
                       +---------+   +-----------+     +----------+

     MSA = Mail Submission Agent
     MDA = Mail Delivery Agent

上图显示了消息通过支持 DMARC 的系统的简单流程。实线表示实际的消息流，点线涉及用于检索与受支持的消息认证方案相关的消息策略的 DNS 查询，星号线表示消息处理模块与消息认证模块之间的数据交换。"sMTA"是发送 MTA，"rMTA"是接收 MTA。

本质上，步骤如下：

  1. 域名所有者按照 [SPF] 构造 SPF 策略并发布在其 DNS 数据库中。域名所有者还根据 [DKIM] 配置其系统进行 DKIM 签名。最后，域名所有者通过 DNS 发布 DMARC 消息处理策略。
  2. 作者生成消息并将其交给域名所有者指定的邮件提交服务。
  3. 提交服务将相关细节传递给 DKIM 签名模块，以生成要应用于消息的 DKIM 签名。
  4. 提交服务将现已签名的消息中继到其指定的传输服务，以路由到预期的接收方。
  5. 消息可能经过其他中继，但最终到达接收方的传输服务。
  6. 接收方投递服务通过将必要数据传递给各自的模块来进行 SPF 和 DKIM 认证检查，每个模块都需要查询作者域的 DNS 数据（当标识符对齐时；见下文）。
  7. 这些结果连同作者的域名一起传递给 DMARC 模块。DMARC 模块尝试从该域的 DNS 检索策略。如果未找到，DMARC 模块确定组织域并重复尝试从 DNS 检索策略。（这在第 6.6.3 节进一步详细描述。）
  8. 如果找到策略，则将其与作者的域名以及 SPF 和 DKIM 结果组合，产生 DMARC 策略结果（"pass"或"fail"），并可选择生成两类报告之一（图中未显示）。
  9. 接收方传输服务根据 DMARC 结果将消息投递到接收方收件箱，或采取其他本地策略动作（图中未显示）。
  10. 当被请求时，接收方传输服务从消息投递会话收集数据，用于提供反馈（见第 7 节）。

5. RFC5322.From 的使用

DMARC 最受安全审视的焦点之一，是选择聚焦于一个标识符，即 RFC5322.From 地址——它是消息数据体的一部分，而在电子邮件的整个历史中，该数据体一直被轻而易举地伪造。

有几点表明，在此上下文中这样做是最正确且最安全的：

缺少单一、格式正确的 RFC5322.From 字段会使消息无效。对此类消息的处理不在本规范的范围之内。

由于通常受 DMARC 参与者保护的邮件类型往往只有单一作者，DMARC 参与者通常在该字段的预期语法方面，在 RFC5322 的一个略受限的 profile（配置）下运行。详见第 6.6 节。

6. 策略

DMARC 策略由域名所有者发布，并由邮件接收方应用。

域名所有者通过向一个或多个域添加 DNS TXT 记录（见第 6.1 节）来通告对一个或多个域的 DMARC 参与。在这样做时，域名所有者就关于声称来自域名所有者某一域的消息的处置，以及关于这些消息的反馈提供，向邮件接收方提出具体要求。

域名所有者可以选择不参与邮件接收方的 DMARC 评估。在这种情况下，域名所有者只是拒绝通告对这些方案的参与。例如，如果路径授权检查的结果不应被视为给定作者域的总体 DMARC 结果的一部分，那么域名所有者就不会发布能够产生 SPF 通过结果的 SPF 策略记录。

实现 DMARC 机制的邮件接收方在消息未通过 DMARC 测试时，应尽最大努力遵循域名所有者发布的 DMARC 策略。由于电子邮件流可能很复杂（由于转发、现有的 RFC5322.From 域伪造服务等），邮件接收方在消息处理过程中可能偏离域名所有者发布的策略，并应借助反馈报告（具体而言使用聚合报告的"PolicyOverride"特性，见第 7.2 节）向域名所有者提供偏离的事实与原因。

6.1. DMARC 策略记录

域名所有者的 DMARC 偏好作为 DNS TXT 记录存储在名为"_dmarc"的子域中。例如，"example.com"的域名所有者会在"_dmarc.example.com"的 TXT 记录中发布 DMARC 偏好。类似地，希望查询关于 RFC5322.From 域为"example.com"的邮件的 DMARC 偏好的邮件接收方，会向 DNS 发出针对子域"_dmarc.example.com"的 TXT 查询。位于 DNS 的 DMARC 偏好数据此后称为"DMARC 记录"。

DMARC 对域名系统（DNS）的使用是由 DMARC 对域名的使用及其所执行查询的性质所驱动的。该查询需求与 DNS 匹配，用于获取简单的参数化信息。它使用一种已建立的方法来存储与目标域名相关联的信息，即一个隔离的、限制在 DMARC 上下文中的 TXT 记录。将 DNS 用作查询服务的好处是复用了极其成熟的运营、管理与维护基础设施，而不是创建一个新的。

根据 [DNS]，TXT 记录可以包含多个"character-string（字符串）"对象。在这种情况发生时，执行 DMARC 评估的模块必须通过将对象按顺序连接并将结果作为单个字符串解析来连接这些字符串。

6.2. DMARC URI

[URI] 定义了用于标识资源的通用语法。DMARC 机制使用它作为域名所有者指定两种受支持报告类型的目的地的格式。

指定这些 URI 的位置（见第 6.3 节）允许提供它们的列表。报告通常按域名所有者提供的顺序发送给每个列出的 URI。接收方可以对他们将发送报告的 URI 数量施加限制，但必须支持向至少两个 URI 发送的能力。URI 列表以逗号（ASCII 0x2C）分隔。

每个 URI 可以有一个与之关联的最大报告大小，可以发送给它。这是通过在分隔逗号或终止分号之前附加一个感叹号（ASCII 0x21），后跟最大大小指示来完成的。

因此，DMARC URI 是一个 URI，其中任何逗号或感叹号都按照 [URI] 进行百分号编码，后跟一个可选的感叹号和最大大小规范，并且如果列表中有额外的报告 URI，则后跟一个逗号和下一个 URI。

例如，URI"mailto:reports@example.com!50m"将请求通过电子邮件向"reports@example.com"发送报告，只要报告负载不超过 50 兆字节。

形式化定义见第 6.4 节。

6.3. 通用记录格式

DMARC 记录遵循 DKIM [DKIM] 中定义的、基于 DNS 的密钥记录的"tag-value（标签-值）"可扩展语法。

第 11 节为已知的 DMARC 标签创建注册表，并注册本文档定义的初始集合。仅处理本文档或后续扩展中定义、从而被添加到该注册表中的标签；未知的标签必须被忽略。

引入以下标签作为初始有效的 DMARC 标签：

adkim：（纯文本；可选；默认"r"。）指示域名所有者要求严格还是宽松的 DKIM 标识符一致性模式。详见第 3.1.1 节。有效值：r（宽松模式）、s（严格模式）。

aspf：（纯文本；可选；默认"r"。）指示域名所有者要求严格还是宽松的 SPF 标识符一致性模式。详见第 3.1.2 节。有效值：r（宽松模式）、s（严格模式）。

fo：失败报告选项（纯文本；可选；默认"0"）。提供生成失败报告的请求选项。报告生成器可以选择遵循所请求的选项。如果未同时指定"ruf"标签（见下文），则必须忽略此标签的内容。该标签的值是冒号分隔的字符列表，指示失败报告选项如下：

p：请求的邮件接收方策略（纯文本；策略记录必需）。指示应域名所有者请求由接收方制定的策略。策略适用于被查询的域及其子域，除非使用"sp"标签显式描述了子域策略。此标签仅对策略记录是强制的，但对第三方报告记录不是（见第 7.1 节）。可能的值：

pct：（0 到 100 之间含端点的纯文本整数；可选；默认 100）。对域名所有者的邮件流中应用 DMARC 策略的消息百分比。但是，这不得应用于 DMARC 生成的报告，所有报告都必须不受阻碍地发送和接收。"pct"标签的目的是允许域名所有者对 DMARC 机制的强制实施进行缓慢的滚动推出。"全有或全无"的前景被认为阻碍了許多组织试验强基于认证的机制。详见第 6.6.4 节。注意，基于该百分比的随机选择（例如以下伪代码）是足够的：

 if (random mod 100) < pct then
   selected = true
 else
   selected = false

rf：用于特定于消息的失败报告的格式（冒号分隔的纯文本值列表；可选；默认"afrf"）。该标签的值是域名所有者请求的一个或多个报告格式的列表，当消息同时未通过 [SPF] 和 [DKIM] 测试以报告个别失败的细节时使用。这些值必须出现在第 11 节定义的报告格式注册表中；观察到不同值的邮件接收方应忽略它，或可以忽略整个 DMARC 记录。对于此版本，目前仅支持"afrf"（[AFRF] 中定义的认证失败报告类型）。详见第 7.3 节。为互操作性，必须支持认证失败报告格式（AFRF）。

ri：聚合报告之间的请求间隔（纯文本 32 位无符号整数；可选；默认 86400）。指示对接收方的请求，以不超过请求秒数的间隔生成聚合报告。DMARC 实现必须能够提供每日报告，并且当被请求时应能够提供每小时报告。然而，除每日报告之外的任何报告都被理解为在尽力而为的基础上提供。

rua：聚合反馈的发送地址（DMARC URI 的逗号分隔纯文本列表；可选）。作为此类 DMARC URI 一部分的逗号或感叹号必须根据 [URI] 第 2.1 节进行编码，以区别于列表分隔符或可选的大小限制。第 7.1 节讨论了当 URI 的域名与通告策略的域名不同时适用的考量。额外的考量见第 12.5 节。可以指定任何有效的 URI。邮件接收方必须实现对"mailto:"URI 的支持，即通过电子邮件发送 DMARC 报告的能力。如果未提供，邮件接收方不得生成聚合反馈报告。邮件接收方不支持的 URI 必须被忽略。聚合反馈报告格式在第 7.2 节描述。

ruf：报告特定于消息的失败信息的地址（DMARC URI 的逗号分隔纯文本列表；可选）。如果存在，域名所有者请求邮件接收方以特定方式（见上文"fo"标签）发送关于未通过 DMARC 评估的消息的详细失败报告。要生成的消息格式必须遵循为"rf"标签指定的格式。第 7.1 节讨论了当 URI 的域名与通告策略的域名不同时适用的考量。邮件接收方必须实现对"mailto:"URI 的支持，即通过电子邮件发送 DMARC 报告的能力。如果未提供，邮件接收方不得生成失败报告。额外的考量见第 12.5 节。

sp：对所有子域请求的邮件接收方策略（纯文本；可选）。指示应域名所有者请求由接收方制定的策略。它仅适用于被查询域的子域，而不适用于域本身。其语法与上述"p"标签相同。如果缺失，则必须对子域应用"p"标签指定的策略。注意，由于第 6.6.3 节描述的 DMARC 策略发现机制的效果，"sp"对于发布在组织域子域上的 DMARC 记录将被忽略。

v：版本（纯文本；必需）。将检索到的记录标识为 DMARC 记录。它必须具有值"DMARC1"。此标签的值必须精确匹配；如果它不匹配或缺失，则必须忽略整个检索到的记录。它必须是列表中的第一个标签。

DMARC 策略记录必须符合第 6.4 节中的形式化规范，即"v"和"p"标签必须存在且必须按该顺序出现。未知的标签必须被忽略。记录其余部分中的语法错误应被丢弃，转而使用默认值（如果有）或直接忽略。

注意，鉴于上一段的规则，将新标签添加到已注册的标签列表中本身不需要生成 DMARC 的新版本（相应地更改"v"标签的值），但对任何现有标签的更改确实需要 DMARC 的新版本。

6.4. 形式化定义

使用 [ABNF] 的 DMARC 格式的形式化定义如下：

     dmarc-uri       = URI [ "!" 1*DIGIT [ "k" / "m" / "g" / "t" ] ]
                       ; "URI" is imported from [URI]; commas (ASCII
                       ; 0x2C) and exclamation points (ASCII 0x21)
                       ; MUST be encoded; the numeric portion MUST fit
                       ; within an unsigned 64-bit integer

     dmarc-record    = dmarc-version dmarc-sep
                       [dmarc-request]
                       [dmarc-sep dmarc-srequest]
                       [dmarc-sep dmarc-auri]
                       [dmarc-sep dmarc-furi]
                       [dmarc-sep dmarc-adkim]
                       [dmarc-sep dmarc-aspf]
                       [dmarc-sep dmarc-ainterval]
                       [dmarc-sep dmarc-fo]
                       [dmarc-sep dmarc-rfmt]
                       [dmarc-sep dmarc-percent]
                       [dmarc-sep]
                       ; components other than dmarc-version and
                       ; dmarc-request may appear in any order

     dmarc-version   = "v" *WSP "=" *WSP %x44 %x4d %x41 %x52 %x43 %x31

     dmarc-sep       = *WSP %x3b *WSP

     dmarc-request   = "p" *WSP "=" *WSP
                       ( "none" / "quarantine" / "reject" )

     dmarc-srequest  = "sp" *WSP "=" *WSP
                       ( "none" / "quarantine" / "reject" )

     dmarc-auri      = "rua" *WSP "=" *WSP
                       dmarc-uri *(*WSP "," *WSP dmarc-uri)

     dmarc-furi      = "ruf" *WSP "=" *WSP
                       dmarc-uri *(*WSP "," *WSP dmarc-uri)

     dmarc-adkim     = "adkim" *WSP "=" *WSP
                       ( "r" / "s" )

     dmarc-aspf      = "aspf" *WSP "=" *WSP
                       ( "r" / "s" )

     dmarc-ainterval = "ri" *WSP "=" *WSP 1*DIGIT

     dmarc-fo        = "fo" *WSP "=" *WSP
                       ( "0" / "1" / "d" / "s" )
                       *(*WSP ":" *WSP ( "0" / "1" / "d" / "s" ))

     dmarc-rfmt      = "rf"  *WSP "=" *WSP Keyword *(*WSP ":" Keyword)
                       ; registered reporting formats only

     dmarc-percent   = "pct" *WSP "=" *WSP
                       1*3DIGIT

"Keyword"从 [SMTP] 的第 4.1.2 节导入。

dmarc-uri 中的大小限制（如果提供）被解释为单位计数，后跟一个可选的单位大小（"k"表示千字节、"m"表示兆字节、"g"表示吉字节、"t"表示太字节）。没有单位时，该数字被假定为基本字节计数。注意，这些单位被视为 2 的幂；千字节是 2^10，兆字节是 2^20，依此类推。

6.5. 域名所有者动作

为实现 DMARC 机制，域名所有者唯一需要做的动作是在 DNS 中创建 DMARC 策略记录。然而，为了有意义地使用 DMARC，域名所有者至少必须建立用于接收报告的地址，或者部署认证技术并确保标识符一致性。大多数域名所有者会希望两者都做。

DMARC 报告体积相当大，且接收它们的地址是公开可见的，因此我们鼓励域名所有者建立专用的电子邮件地址来接收和处理报告，并根据需要在这类电子邮件地址上部署滥用对策。

认证技术在 [DKIM]（另见 [DKIM-OVERVIEW] 和 [DKIM-DEPLOYMENT]）与 [SPF] 中讨论。

6.6. 邮件接收方动作

本节描述 DMARC 环境中的接收方动作。

6.6.1. 提取作者域

RFC5322.From 字段中的域名被提取为要由 DMARC 评估的域。如果该域名以 UTF-8 编码，则必须将其转换为 A-label（如 [IDNA] 第 2.3 节所述），以便进一步处理。

为了被 DMARC 处理，一条消息通常恰好需要包含一个 RFC5322.From 域名（一个单一的 From: 字段，其中包含一个域名）。并非所有消息都满足此要求，对它们的处理不在本文档的范围之内。典型的例外情况，以及 DMARC 参与者历史上处理它们的方式如下：

句法上有效的多值 RFC5322.From 字段的情况带来了特殊挑战。这种情况下的过程是：使用在 RFC5322.From 字段中找到的每个域名作为作者域来应用 DMARC 检查，并应用在所失败的检查中选出的最严格策略。

6.6.2. 确定处理策略

为了确定单条消息的策略，邮件接收方必须执行以下动作或其语义等价物。步骤 2-4 可以并行完成，而步骤 5 和 6 需要来自先前步骤的输入。

步骤如下：

  1. 从消息中提取 RFC5322.From 域名（如上）。
  2. 查询 DNS 以获取 DMARC 策略记录。如果找到则继续，否则终止 DMARC 评估。详见第 6.6.3 节。
  3. 执行 DKIM 签名验证检查。一封电子邮件可能包含多个 DKIM 签名。此步骤的结果传递给算法的其余部分，并且必须包含每个被检查 DKIM 签名的"d="标签的值。
  4. 执行 SPF 验证检查。此步骤的结果传递给算法的其余部分，并且必须包含用于完成 SPF 检查的域名。
  5. 执行标识符一致性检查。在完成了认证检查和策略发现之后，邮件接收方检查已认证标识符是否如第 3 节所述处于对齐状态。如果有一个或多个已认证标识符与 RFC5322.From 域名对齐，则该消息被视为通过 DMARC 机制检查。所有其他情况（认证失败、标识符不匹配）均被视为 DMARC 机制检查失败。
  6. 应用策略。未通过 DMARC 机制检查的电子邮将依据发现的域名所有者的 DMARC 策略进行处置。详见第 6.3 节。

在域名所有者未使用 SPF 或 DKIM 的情况下应用的启发式方法（例如 [Best-Guess-SPF]）不应被使用，因为可能存在这样的情况：域名所有者希望消息接收方根本不考虑该底层认证协议的结果。

DMARC 评估只能在一个底层认证机制针对对齐的标识符通过之后才产生"pass"结果。如果两者都未通过，并且其中一个或两个由于暂时性错误而失败，则评估该消息的接收方无法得出结论说 DMARC 机制发生了永久性失败；因此他们无法应用已通告的 DMARC 策略。在其他适当的情况下，接收方可以发送关于暂时性错误的反馈报告。

对于 SPF 和/或 DKIM 评估遇到永久性 DNS 错误的消息的处理，留给邮件接收方自行决定。

6.6.3. 策略发现

如上所述，DMARC 机制使用 DNS TXT 记录来通告策略。策略发现是通过类似于 SPF 记录使用的方法完成的。该方法，以及 DMARC 与 SPF 机制之间的重要区别，讨论如下。

为了平衡支持通配、允许子域策略覆盖以及限制 DNS 查询负载这几项相互冲突的需求，采用了以下 DNS 查询方案：

  1. 邮件接收方必须查询 DNS，以获取与消息中 RFC5322.From 域名匹配的 DNS 域上的 DMARC TXT 记录。返回一组可能为空的结果。
  2. 不以标识 DMARC 当前版本的"v="标签开头的记录被丢弃。
  3. 如果集合现在为空，邮件接收方必须查询 DNS，以获取与组织域（而非消息中的 RFC5322.From 域名，若不同）匹配的 DNS 域上的 DMARC TXT 记录。该记录可以包含要为组织域的子域断言的策略。返回一组可能为空的结果。
  4. 不以标识 DMARC 当前版本的"v="标签开头的记录被丢弃。
  5. 如果剩余集合包含多条记录或没有记录，则策略发现终止，并且不对本条消息应用 DMARC 处理。
  6. 如果检索到的策略记录不包含有效的"p"标签，或包含无效的"sp"标签，则：
    1. 如果存在"rua"标签并包含至少一个语法有效的报告 URI，邮件接收方应表现得如同检索到一条包含有效"v"标签和"p=none"的记录，并继续处理；
    2. 否则，邮件接收方不对本条消息应用 DMARC 处理。

如果上述机制产生的集合不包含 DMARC 策略记录（即，任何表明没有这样的记录、而非暂时性 DNS 错误的指示），邮件接收方不应将 DMARC 机制应用于该消息。

查询 DMARC 策略记录时 DNS 错误的处理留给邮件接收方自行决定。例如，为确保对邮件流的最小干扰，暂时性错误可能导致消息被投递（"fail open/失败开放"），或者可能导致消息被暂时拒收（即 SMTP 4yx 回复），这会邀请发送 MTA 在情况可能清除后重试，从而能够得出确定的 DMARC 结论（"fail closed/失败关闭"）。

6.6.4. 消息采样

如果策略记录中存在"pct"标签，邮件接收方不得在超过受影响消息总量中所述百分比的消息上实施所请求的策略（"p"标签或"sp"标签）。然而，无论是否存在"pct"标签，邮件接收方必须在生成的任何报告中包含所有相关消息数据。

如果电子邮件受 DMARC"quarantine"策略约束，邮件接收方应对该消息进行隔离。如果电子邮件不受"quarantine"策略约束（由于"pct"标签），邮件接收方应照常应用本地消息分类。

如果电子邮件受 DMARC"reject"策略约束，邮件接收方应拒收该消息（见第 10.3 节）。如果电子邮件不受"reject"策略约束（由于"pct"标签），邮件接收方应将该电子邮件视为应用了"quarantine"策略。此行为允许域名所有者在不放宽现有策略的情况下，逐步试验越来越强的策略。

邮件接收方通过统计机制实现"pct"，这些机制能够接近请求的百分比，并在一个报告期内提供有代表性的样本。

6.6.5. 存储 DMARC 处理的结果

基于邮件接收方的 DMARC 处理结果应被存储，以便最终以聚合反馈报告的形式呈现回域名所有者。第 6.3 节和第 7.2 节讨论聚合反馈。

6.7. 策略强制实施考量

即使电子邮件通过了 DMARC 机制检查，邮件接收方也可以选择拒收或隔离电子邮件。DMARC 机制不会告知邮件接收方某个电子邮件流是否"良好"。鼓励邮件接收方维持反滥用技术，以应对启用 DMARC 的犯罪活动的可能性。

即使域名所有者已发布"reject"策略，邮件接收方也可以选择接受未通过 DMARC 机制检查的电子邮。如果邮件接收方选择不遵守域名所有者的 reject（违反策略），他们需要尽最大努力不增加接受滥用邮件的可能性。至少，在投递失败邮件时，建议添加 Authentication-Results 头字段（见 [AUTH-RESULTS]）。当这样做时，如此记录的 DNS 域名必须编码为 A-label。

邮件接收方仅有义务在因 DMARC 策略而到期的聚合反馈报告中报告 reject 或 quarantine 策略动作。他们不需要报告作为本地策略结果的 reject 或 quarantine 动作。如果暴露了本地策略信息，滥用者可以洞察垃圾邮件活动的有效性和投递率。

消息的最终处置始终是一个本地策略问题。例如，希望将 DMARC 策略置于 SPF 策略之上的运营者将忽略 SPF 策略，因为实施由 SPF 决定的拒收会阻止 DKIM 的评估；否则 DKIM 可能通过，从而满足 DMARC 评估。这样做存在权衡，即以接受并处理整个消息体来换取 DMARC 提供的增强保护。

合规的邮件接收方通常会忽略作为认证机制一部分发现的任何邮件处理指令（例如 Author Domain Signing Practices (ADSP)、SPF），前提是同时也发现了指定非"none"策略的 DMARC 记录。偏离此做法会在 DMARC 运营者之间引入消息处理的不一致。然而，这种偏离并未被禁止。

为使域名所有者能够在不影响现有邮件处理的情况下接收 DMARC 反馈，发现的"p=none"策略不应修改现有的邮件处置处理。

即使在缺乏 DKIM 报告 [AFRF-DKIM] 或 SPF 报告 [AFRF-SPF] 请求的情况下，邮件接收方也应实施 DMARC 的报告指令。此外，此类请求的存在不应影响 DMARC 报告。

7. DMARC 反馈

以反馈的形式让域名所有者了解邮件接收方如何实施和强制 DMARC 机制，对于建立和维护准确的认证部署至关重要。当域名所有者能够看到其策略和实践产生了什么效果时，他们更愿意并且能够更好地使用 quarantine 和 reject 策略。

7.1. 验证外部投递目标

可以为不同的报告指定位于提出请求的域名所有者权威之外的投递目标。这允许不运营邮件服务器的域请求报告，并将它们发送到能够处理它们的地方。

如果没有检查，这将允许不良行为者发布一条 DMARC 策略记录，请求将报告发送到受害地址，然后向各种目的地发送大量将同时未通过 DKIM 和 SPF 检查的邮件；受害方反过来会被不想要的报告淹没。因此，包含了一个验证机制。

当邮件接收方在 DNS 中发现 DMARC 策略，并且发现该记录的Organizational Domain 与"rua"或"ruf"标签中指定的 [URI] 的 authority 组件的 host 部分的 Organizational Domain 不完全相同时，应采取以下验证步骤：

  1. 提取 URI 的 authority 组件的 host 部分。称之为"destination host（目标主机）"，因为它指代一个 Report Receiver（报告接收方）。
  2. 前置字符串"_report._dmarc"。
  3. 前置从中检索策略的域名（如果需要，在转换为 A-label 之后）。
  4. 在构造的名称处查询 DNS 以获取 TXT 记录。如果此请求的结果是某种暂时性 DNS 错误（例如超时），邮件接收方可以选择暂时使投递失败，以便稍后重复验证测试。
  5. 对于返回的每个记录，将结果解析为一系列"tag=value"对，即与策略记录相同的整体格式（见第 6.4 节）。特别是，"v=DMARC1"标签是强制的，且必须出现在列表首位。丢弃未通过此测试的任何记录。
  6. 如果结果不包含通过基本解析的 TXT 资源记录，则无法对外部报告关系做出正面判定；停止。
  7. 如果解析后集合中至少剩余一个 TXT 资源记录，则外部报告安排已由报告接收方授权。
  8. 如果因此发现了"rua"或"ruf"标签，则用在此记录中找到的值替换从域的 DMARC 策略记录中提取的对应值。这允许报告接收方覆盖报告目标。但是，为防止循环或间接滥用，覆盖 URI 必须使用第一步中的相同目标主机。

例如，如果对"blue.example.com"的 DMARC 策略查询包含"rua=mailto:reports@red.example.net"，则从后者提取的 host（"red.example.net"）与"blue.example.com"不匹配，因此执行此过程。发出对"blue.example.com._report._dmarc.red.example.net"的 TXT 查询。如果返回单个回复，其中包含"v=DMARC1"标签，则两者之间的关系得到确认。此外，"red.example.net"有机会在需要时覆盖"blue.example.com"请求的报告目标。

在上述算法未能确认外部报告已由报告接收方授权的情况下，生成报告的邮件接收方必须忽略该 URI。此外，如果确认记录包含其 host 再次不同于发布该覆盖的域的 URI，则生成报告的邮件接收方不得向原始 URI 或覆盖 URI 中的任何一个生成报告。

报告接收方如果希望接收其他域的报告，会在其 DNS 中发布这样的记录。

愿意接收任何域报告的报告接收方可以使用通配 DNS 记录。例如，"*._report._dmarc.example.com"处的 TXT 资源记录，至少包含"v=DMARC1"，确认 example.com 愿意接收任何域的 DMARC 报告。

如果报告接收方被数量压垮，它可以简单地移除确认 DNS 记录。然而，由于正向缓存，该更改可能需要长达记录上生存时间（TTL）的时间才能生效。

邮件接收方可能决定不实施此过程，例如，如果它依赖于允许外部报告地址的域的本地列表。

7.2. 聚合报告

DMARC 聚合反馈报告旨在为域名所有者提供关于以下方面的精确洞察：

聚合 DMARC 反馈提供了域名所有者就发布 DMARC 策略做出明智决策所需的对现实世界电子邮件流的可见性。当域名所有者知道他们正在发送什么合法邮件、这些邮件的认证结果是什么、以及接收方收到的伪造邮件是什么时，他们可以就所需的策略以及启用这些策略所需的步骤做出更好的决策。当域名所有者适当设置策略并了解其效果时，邮件接收方可以自信地对其采取行动。

可见性以每日（或更频繁）的、由邮件接收方生成的反馈报告的形式出现，这些报告包含与域名所有者相关的消息流的聚合数据。此信息包括关于通过 DMARC 认证的消息以及未通过认证的消息的数据。

这些报告的格式在附录 C 中定义。

报告应包括以下数据：

注意，域名所有者或其代理可能随时更改域或子域的已发布 DMARC 策略。从邮件接收方的角度来看，这将发生在报告期内，并可能在该期间内、在生成报告时的该期间结束时、或在后续报告期内被注意到，这一切取决于邮件接收方的实现。在这些条件下，邮件接收方有可能执行以下任何操作：

对于任何给定域，此类策略更改预计不频繁，而对邮件接收方更严格的策略监控要求会在互联网规模上产生非常大的负担。因此，报告消费者和域名所有者的责任是意识到这种情况，并允许在新策略传播到邮件接收方期间出现此类混合报告。

当所有聚合报告覆盖一个共同的时间段时，它们最有用。相比之下，当这些来自多个生成器的报告覆盖不一致的时间段时，对它们进行关联是困难或不可能的。报告生成器应在可能的情况下，遵守其使用的报告期的小时边界。例如，在 00:00 开始每日报告；在 00:00、01:00、02:00 开始每小时报告；等等。强烈鼓励使用 24 小时报告期的报告生成器在 00:00 UTC 开始该期间，而不管本地时区或报告生成时间，以便于关联。

邮件接收方在查找与收到邮件的 RFC5322.From 域相对应的 DMARC 策略记录时，发现报告请求。存在"rua"标签指定了发送反馈的位置。

7.2.1. 传输

当"rua"标签中指定的 URI 未另行指定时，生成反馈报告的邮件接收方应采用安全传输机制。

邮件接收方在准备好报告后，必须按照给定顺序评估所提供的报告 URI。任何包含被生成报告超出（在压缩之后，以及在特定传输机制所需的任何编码之后）的大小限制的报告 URI 不得被使用。必须尝试将聚合报告投递到每个剩余的 URI，直至接收方对受支持 URI 的限制。

如果由于已发布 URI 所通告的服务无法接受报告（例如，URI 引用了无法访问的服务，或所有提供的 URI 都指定了被生成记录超出的大小限制）而无法进行传输，邮件接收方应发送一份简短报告（见第 7.2.2 节），指明有报告可用但无法发送。邮件接收方可以缓存该数据并在以后重试，或者可以丢弃无法发送的数据。

7.2.1.1. 电子邮件

由邮件接收方生成的消息必须是按照 [MIME] 格式化的 [MAIL] 消息。聚合报告本身必须包含在消息的其中一个部分中。可以包含一个人类可读的部分作为 MIME 部分（例如 text/plain 部分）。

聚合数据必须是 XML 文件，应接受 GZIP 压缩。拒绝应用压缩可能导致报告过大而无法被接收方处理（常见观察到的接收方限制是十兆字节）；进行压缩以一定的计算成本增加了报告被接受的机会。如果压缩了，聚合数据应使用媒体类型"application/gzip"（见 [GZIP]），否则使用"text/xml"。文件名通常使用以下 ABNF 构造：

     filename = receiver "!" policy-domain "!" begin-timestamp
                "!" end-timestamp [ "!" unique-id ] "." extension

     unique-id = 1*(ALPHA / DIGIT)

     receiver = domain
                ; imported from [MAIL]

     policy-domain   = domain

     begin-timestamp = 1*DIGIT
                       ; seconds since 00:00:00 UTC January 1, 1970
                       ; indicating start of the time range contained
                       ; in the report

     end-timestamp = 1*DIGIT
                     ; seconds since 00:00:00 UTC January 1, 1970
                     ; indicating end of the time range contained
                     ; in the report

     extension = "xml" / "xml.gz"

对于普通 XML 文件，扩展名必须是"xml"，对于使用 GZIP 压缩的 XML 文件，必须是"xml.gz"。

"unique-id"允许由邮件接收方生成的可选唯一 ID，以区分同一域名所有者内由不同来源同时生成的多个报告。

例如，这是来自邮件接收方"mail.receiver.example"的、发往域名所有者"example.com"的报告的 gzip 文件的可能文件名：

     mail.receiver.example!example.com!1013662812!1013749130.gz

不需要特定的 MIME 消息结构。假定聚合报告地址将配备为提取具有规定媒体类型和文件名的 MIME 部分，并忽略其余部分。

承载 DMARC 反馈数据的电子邮件流必须符合 DMARC 机制，从而产生对齐的"pass"（见第 3.1 节）。这种做法使报告消费者处理欺诈性报告的风险最小化。

单个报告提交的 RFC5322.Subject 字段应符合以下 ABNF：

     dmarc-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
                     %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
                     domain-name 1*FWS               ; from RFC 6376
                     %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
                     1*FWS domain-name 1*FWS
                     %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
                     msg-id                          ; from RFC 5322

第一个 domain-name 指示生成报告所关于的 DNS 域名。第二个 domain-name 指示代表生成报告的邮件接收方的 DNS 域名。该字段的 Report-ID: 部分的目的是使域名所有者能够识别并忽略可能由邮件接收方发送的重复报告。

例如，这是来自邮件接收方"mail.receiver.example"的、发往域名所有者"example.com"的报告的可能 Subject 字段。它按照 [MAIL] 允许的方式进行了换行：

     Subject: Report Domain: example.com
         Submitter: mail.receiver.example
         Report-ID: <2002.02.15.1>

当反馈数据大小超过生成方或消费方的最大允许附件大小时，此传输机制可能遇到问题。进一步讨论见第 7.2.2 节。

7.2.1.2. 其他方法

如所撰写的规范允许在后续版本中支持添加其他已注册的 URI 方案。

7.2.2. 错误报告

当邮件接收方无法通过域名所有者列出的任何 URI 完成报告投递时，邮件接收方应生成错误消息。必须尝试将此报告发送到所有列出的"mailto"URI，并且也可以发送到任何其他或所有其他列出的 URI。

错误报告必须按照 [MIME] 格式化。必须包含一个 text/plain 部分，其中包含类似 [DSN] 第 2 节中找到的字段-值对。所需的字段（可以按任何顺序出现）如下：

Report-Date：一个 [MAIL] 格式化的日期表达式，指示传输失败发生的时间。

Report-Domain：生成失败报告所关于的域名。

Report-ID：报告尝试使用的 Report-ID:。

Report-Size：无法发送的报告的字节大小。这必须表示邮件接收方尝试发送的字节数。当尝试了多个传输系统时，大小可能不同；在这种情况下，必须生成单独的错误报告，以使此值与实际进行的尝试相匹配。

Submitter：代表生成但无法提交的报告的邮件接收方的域名。

Submitting-URI：邮件接收方尝试但未能提交报告的 URI。

可以包含一个额外的 text/plain 部分，提供人类可读的说明。

可以包含一个额外的 text/plain 部分，提供对上述内容的、人类可读的解释，并且也可以包含一个可用于寻求帮助的 URI。

7.3. 失败报告

失败报告通常在邮件接收方检测到 DMARC 失败后几乎立即生成并发送。与等待聚合报告不同，这些报告对于在出现认证失败时快速通知域名所有者很有用。无论失败是由于基础设施问题还是消息不真实，失败报告都比聚合报告中可用的信息提供更多关于失败消息的信息。

这些报告应包括来自未通过认证的消息的任何 URI。这些报告应包括尽可能多的消息和消息头，以支持域名所有者调查消息认证失败的原因并追踪发送方。

当域名所有者出于取证分析的目的请求失败报告，并且邮件接收方愿意提供此类报告时，邮件接收方使用 [AFRF] 中描述的格式生成并发送消息；本文档更新了该报告格式，如第 7.3.1 节所述。

报告的目标和性质由第 6.3 节定义的"ruf"和"fo"标签定义。

当选择了多个 URI 来接收失败报告时，报告生成器必须尝试向每个 URI 投递。

一个明显的考量是拒绝服务攻击，攻击者可发送大量声称来自预期受害域名所有者、但 SPF 和 DKIM 均失败的消息；这将导致参与的邮件接收方向域名所有者或其委托方发送可能海量的失败报告。因此，鼓励参与的邮件接收方尽可能多地聚合这些报告，使用滥用报告格式（[ARF]）的 Incidents 字段。各种聚合技术是可能的，包括：

7.3.1. 报告格式更新

实现本规范的运营者还实现如下增强版本的 [AFRF]：

  1. DMARC 失败报告包含以下 ARF 头字段，具有指示的规范性要求级别：
    • Identity-Alignment（必需；定义如下）
    • Delivery-Result（可选）
    • DKIM-Domain、DKIM-Identity、DKIM-Selector（如果消息由 DKIM 签名，则必需）
    • DKIM-Canonicalized-Header、DKIM-Canonicalized-Body（如果消息由 DKIM 签名，则可选）
    • SPF-DNS（必需）
  2. "Identity-Alignment"字段定义为包含一个逗号分隔的认证机制名称列表，这些机制产生了对齐的标识符；如果没有，则为关键字"none"。ABNF： 
         id-align     = "Identity-Alignment:" [CFWS]
                    ( "none" /
                      dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) )
                    [CFWS]

     dmarc-method = ( "dkim" / "spf" )
                    ; each may appear at most once in an id-align
  3. 定义了认证失败类型"dmarc"，当由于部分或全部认证机制未能产生对齐的标识符而生成失败报告时使用。注意，失败报告生成器也可以独立地为任何或所有底层认证方法生成 AFRF 消息。

8. 最低实现要求

DMARC 的最低实现具有以下特征：

9. 隐私考量

本节讨论特定于可能包含在作为 DMARC 一部分的交互中的私有数据的安全问题。

9.1. 数据暴露考量

聚合报告的范围限于 DMARC 策略和处置结果、与底层认证机制相关的信息，以及参与 DMARC 验证的标识符。

失败消息报告提供与认证失败相关的特定于消息的细节。单个报告可以包含消息内容以及跟踪头字段。域名所有者能够分析单个报告，并尝试确定认证机制失败的根本原因，深入了解电子邮件和网络基础设施的错配或其他问题，或检查消息以洞察滥用行为。

两种报告类型都可能暴露发送方和接收方标识符（例如 RFC5322.From 地址），并且尽管用于失败消息报告的 [AFRF] 格式支持编辑（redaction），失败消息报告能够将整个消息暴露给报告接收方。

请求报告的域名所有者将收到关于声称来自他们的邮件的信息，其中包括事实上并非来自他们的邮件。因此，关于邮件最终目的地的信息（否则可能被中间系统掩盖）将被暴露。

当存在消息转发安排时，请求报告的域名所有者还将收到关于转发到原本不属于其消息收件人列表的域的邮件的信息。这意味着域名所有者先前未知的目目的地现在可能变得可见。

关于消息的信息披露首先是由生成电子邮件的实体（即域名所有者，而非邮件接收方）请求的，因此这可能并不完全符合现有的隐私政策条款。对于某些提供商，聚合报告和失败消息报告被视为类似于关于垃圾邮件或钓鱼的投诉报告的功能，并在隐私政策下被类似对待。鼓励报告生成器（即邮件接收方）在启用 DMARC 报告之前，根据此类政策审查其报告限制。

9.2. 报告接收方

DMARC 记录可以指定将报告发送到代表域名所有者运营的 intermediary（中介）。当域名所有者与某个实体签订合同以监控邮件流的滥用和性能问题时，会这样做。此类数据被第三方接收，可能被允许，也可能不被邮件接收方的隐私政策、使用条款或其他类似管辖文件所允许。域名所有者和邮件接收方都应审查并理解他们自己的内部政策是否约束 DMARC 报告的使用和传输。

报告接收方进行流量分析存在一定可能性，从而可能获得关于接收方流量的元数据。除了验证是否符合政策之外，接收方在将报告发送给第三方之前需要考虑这一点。

10. 其他主题

本节讨论有关 DMARC 开发中所做选择的一些主题，主要是为了将历史记录存档。

10.1. SPF 特有议题

尽管 DMARC 不会从根本上改变 SPF 策略记录的语义，但历史上对此类策略的宽松强制实施导致许多人发布包含许多大型网络范围的极宽泛记录。强烈鼓励域名所有者在发布 DMARC 记录之前仔细审查其 SPF 记录，以了解哪些网络被授权代表域名所有者发送。

某些接收方架构可能在任何 DMARC 操作之前实现 SPF。这意味着发送方 SPF 机制上的"-"前缀（例如"-all"）可能导致该拒收在处理的早期生效，从而在发生任何 DMARC 处理之前导致消息被拒收。选择使用"-all"的运营者应当意识到这一点。

10.2. DNS 负载与缓存

DMARC 策略使用 DNS 进行通信，因此继承了与 DNS 缓存相关的若干考量。从邮件接收方的角度来看，应考虑新鲜度与缓存对减少 DNS 查询开销的影响之间的内在冲突。如果域名所有者发布 TTL 极短的 DNS 记录，可能通过注入大量消息来刺激邮件接收方压垮域名所有者的 DNS。尽管这不是 DMARC 特有的问题，但在发布 DMARC 策略时应考虑极短 TTL 的影响。

相反，长 TTL 会导致记录被缓存很长时间。这可能导致域名所有者通告的 DMARC 参数的关键更改在 TTL 的整个长度内（等待 DNS 缓存过期时）不被注意。避免此问题可能意味着更短的 TTL，但会带来上述潜在问题。应寻求平衡，以在保持 DNS 缓存好处的同时，维持 DMARC 偏好变更的响应性。

10.3. 拒收消息

本提案要求在某种情况下在 SMTP 会话期间拒收消息。这比生成投递状态通知（[DSN]）更可取，因为使用 DMARC 捕获并拒收的欺诈性消息随后会导致恼人地生成此类失败报告，返回到 RFC5321.MailFrom 地址。

这种同步拒收通常以下列两种方式之一完成：

这些方法各自都有代价。例如，静默丢弃有助于防止 backscatter（反弹风暴），但它实际上也意味着必须将 SMTP 服务器编程为给出错误结果，这可能使外部调试工作感到困惑。

类似地，SMTP 回复的文本部分可能很重要，需要考虑。例如，拒收消息时，透露拒收原因可能会给攻击者足够的信息，以便在以后的尝试中绕过这些努力，尽管它也可能帮助合法客户端确定导致拒收的某个本地问题的来源。

在后一种情况下，在进行 SMTP 拒收时，提供清晰的提示有助于解决问题。接收方可以通过在回复文本某处使用"DMARC"一词，以纯文本指示拒收原因。许多系统能够扫描 SMTP 回复文本以确定拒收的性质。因此，提供机器可检测的拒收原因，允许自动化系统适当地解决导致拒收的问题。例如：

       550 5.7.1 Email rejected per DMARC policy for example.com

如果邮件接收方由于无法检索或应用 DMARC 策略而选择延迟投递，最好使用 4xy SMTP 回复代码。

10.4. 标识符一致性考量

DMARC 机制允许 DKIM 和 SPF 认证的标识符都代表域名所有者、并可能代表不同子域对电子邮件进行认证。如果恶意或不知情的用户能够获得对子域的 SPF 记录或 DKIM 选择器记录的控制权，则该子域可用于代表组织域生成通过 DMARC 的电子邮件。

例如，控制"evil.example.com"的 SPF 记录的攻击者可以发送 RFC5322.From 字段包含"foo@example.com"的邮件，该邮件可以通过对"example.com"的认证和 DMARC 检查。

组织域管理员应小心不要委托子域的控制权（如果这是一个问题），并在适当时考虑使用"strict"标识符一致性选项。

10.5. 互操作性问题

DMARC 限制了哪些端到端场景可以实现"pass"结果。

由于 DMARC 依赖 [SPF] 和/或 [DKIM] 来实现"pass"，它们的限制也适用。

当消息被某些中介（例如邮件列表）处理时，会出现额外的 DMARC 约束。经过中介通常会导致认证失败或丢失标识符一致性。这些转换可能符合标准，但仍将阻止 DMARC"pass"。

除了中介之外，由授权的独立第三方发送的邮件可能没有以标识符一致性方式发送，同样阻止"pass"结果。

关于与 DKIM 一起使用策略机制的特定问题在 [DKIM-LISTS]（特别是第 5.2 节）中进一步讨论。

11. IANA 考量

本节描述 IANA 完成的动作。

11.1. Authentication-Results 方法注册表更新

IANA 已在"Email Authentication Methods"注册表中添加以下内容：

11.2. Authentication-Results 结果注册表更新

IANA 已在"Email Authentication Result Names"注册表中添加以下内容：

代码：none（现有）。Auth Method：dmarc（已添加）。含义：没有为对齐的标识符发布 DMARC 策略记录，或者无法提取对齐的标识符。Status：active。

代码：pass（现有）。Auth Method：dmarc（已添加）。含义：为对齐的标识符发布了 DMARC 策略记录，并且至少一个认证机制通过。Status：active。

代码：fail（现有）。Auth Method：dmarc（已添加）。含义：为对齐的标识符发布了 DMARC 策略记录，但没有认证机制通过。Status：active。

代码：temperror（现有）。Auth Method：dmarc（已添加）。含义：DMARC 评估期间发生暂时性错误。稍后的尝试可能产生最终结果。Status：active。

代码：permerror（现有）。Auth Method：dmarc（已添加）。含义：DMARC 评估期间发生永久性错误，例如遇到语法不正确的 DMARC 记录。稍后的尝试不太可能产生最终结果。Status：active。

11.3. 反馈报告头字段注册表更新

已在"Feedback Report Header Fields"注册表中添加以下内容：

11.4. DMARC 标签注册表

已创建名为"Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters"的新注册表树。在其中，已创建名为"DMARC Tag Registry"的新子注册表。

DMARC 标签的名称必须在此新子注册表中向 IANA 注册。仅当值已以满足 [IANA-CONSIDERATIONS] 中 Specification Required 条款的方式记录时，才分配新条目。每个注册必须包括标签名称；定义它的规范；简要描述；以及其状态，必须是"current"、"experimental"或"historic"之一。指定专家需要确认所提供的规范充分描述了新标签，并清晰地呈现了域名所有者和邮件接收方将如何在 DMARC 上下文中使用它。

为避免版本兼容性问题，添加到 DMARC 规范的标签在处理时，应避免改变由符合先前规范的实现所处理的现有记录的语义。

此注册表中的初始条目集如下：

Tag NameReferenceStatusDescription
adkimRFC 7489currentDKIM alignment mode
aspfRFC 7489currentSPF alignment mode
foRFC 7489currentFailure reporting options
pRFC 7489currentRequested handling policy
pctRFC 7489currentSampling rate
rfRFC 7489currentFailure reporting format(s)
riRFC 7489currentAggregate Reporting interval
ruaRFC 7489currentReporting URI(s) for aggregate data
rufRFC 7489currentReporting URI(s) for failure data
spRFC 7489currentRequested handling policy for subdomains
vRFC 7489currentSpecification version

11.5. DMARC 报告格式注册表

同样在"Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters"中，已创建名为"DMARC Report Format Registry"的新子注册表。

DMARC 失败报告格式的名称必须在此注册表中向 IANA 注册。仅当值满足 [IANA-CONSIDERATIONS] 中 Specification Required 的定义时，才分配新条目。除了对永久规范的引用外，每个注册必须包括格式名称；简要描述；以及其状态，必须是"current"、"experimental"或"historic"之一。指定专家需要确认所提供的规范充分描述了报告格式，并清晰地呈现了域名所有者和邮件接收方将如何在 DMARC 上下文中使用它。

此注册表中的初始条目如下：

Format NameReferenceStatusDescription
afrfRFC 7489currentAuthentication Failure Reporting Format (see [AFRF])

12. 安全考量

本节讨论 DMARC 的安全问题以及可能的补救措施（在可用的情况下）。

12.1. 认证方法

DMARC 所使用的认证方法的安全考量通过引用并入此处。

12.2. 针对报告 URI 的攻击

发布在 DNS TXT 记录中的 URI 是众所周知的可能攻击目标。诸如 [DNS] 和 [ROLES] 之类的规范暴露或导致暴露可能被攻击者淹没的电子邮件地址，例如；MX、NS 和 DNS 中找到的其他记录通告潜在的攻击目的地；常见的 DNS 名称（如"www"）清楚地标识了可找到特定服务的位置，为定向拒绝服务或渗透攻击提供目的地。

因此，域名所有者需要加固这些地址以抵御各种攻击，包括但不限于：

12.3. DNS 安全

DMARC 机制及其底层技术（SPF、DKIM）依赖于 DNS 的安全性。为降低由于基于 DNS 的利用而导致 DMARC 机制被颠覆的风险，域名所有者和邮件接收方都应认真考虑在部署 DMARC 的同时并行部署 DNSSEC。

使用 DNSSEC 发布数据与域名所有者和第三方报告接收方相关。支持 DNSSEC 的解析与邮件接收方和报告接收方相关。

12.4. 显示名攻击

消息滥用中的一种常见攻击是在 RFC5322.From 字段的 display-name（显示名）部分呈现虚假信息。例如，该字段中的电子邮件地址可能是任意地址或域名，同时在显示名中包含知名的名称（个人、品牌、角色等），意图欺骗最终用户相信该名称是被合法使用的。该攻击基于这样一个观念：大多数常见 MUA 在显示名和电子邮件地址都可用时，会显示显示名而不是电子邮件地址。

一般而言，显示名攻击不在 DMARC 的范围之内，因为需要进一步探索针对这些攻击的可能防御措施。

有一些可能的机制试图缓解这些攻击，例如：

12.5. 外部报告地址

为避免不良行为者的滥用，报告地址通常必须位于请求报告的域内部。为了适应特殊情况（例如需要获取关于实际上无法接收邮件的域的报告），第 7.1 节描述了一种基于 DNS 的机制，用于验证已批准的外部报告。

这里明显的考量是针对被声称是外部接收方的域的 DNS 负载增加。负面缓存将缓解此问题，但只是在有限程度上，主要取决于域的 SOA 记录中的默认 TTL。

在可能的情况下，外部报告最好通过将报告定向到能够接收邮件的域，并简单地将其自动转发到所需的外部目的地来实现。

注意，"ruf"标签中显示的地址会接收更多可能被视为私有数据的信息，因为实际电子邮件内容可能出现在失败报告中。因此，在那里标识的 URI 比"rua"标签中找到的 URI 更具吸引力的入侵尝试目标。此外，攻击主题域的 DNS 以导致失败数据被欺诈性地路由到攻击者系统可能是一个有吸引力的前景。如果这是一个问题，建议部署 [DNSSEC]。

第 7.1 节中提出的验证机制目前不是强制性的（"MUST"），但强烈推荐（"SHOULD"）。有可能在后来的安全审查中将其提升为"MUST"。

12.6. 安全协议

本文档鼓励使用安全传输机制，以防止私有数据丢失给可能能够监视此类传输的第三方。应避免未加密的机制。

特别是，最初被加密或以其他方式保护的消息可能出现在未安全发送的报告，这可能暴露私有信息。

13. 参考文献

13.1. 规范性参考文献

13.2. 资料性参考文献

附录 A. 技术考量

本节记录了在 DMARC 开发过程中做出的一些设计决策。具体而言，此处讨论了一些曾被考虑、但未纳入设计的建议。包含此文本是为了解释为何曾考虑它们、又为何未纳入本版本。

A.1. S/MIME

S/MIME，即可安全多用途互联网邮件扩展（Secure Multipurpose Internet Mail Extensions），是一种对消息中 MIME 数据进行加密与签名的标准。它曾被建议并考虑作为用于认证消息来源的第三种安全协议。

DMARC 聚焦于域级认证（即由域名所有者对消息负责），而 S/MIME 实际上面向用户到用户的认证与加密。仅此一点似乎就使其难以契合 DMARC 的目标。

S/MIME 还深受公钥基础设施（PKI）这一"重量级"问题的困扰，这意味着用于验证签名的密钥分发机制必须被纳入。在许多情形下，仅此一点便是难以逾越的障碍。尽管一直有关于 PKI 可用性与部署将会改善的承诺，但这些承诺至今尚未兑现。DMARC 可以在这些障碍被扫清之后再重新审视这一选择。

S/MIME 在特定细分市场（例如政府）中有广泛部署，但在整个通用互联网上并未享有类似的广泛部署，且没有任何改变的迹象。DKIM 与 SPF 都在通用互联网上广泛部署，且其采用率持续保持正向增长。

最后，实验表明，在 DMARC 的初始版本中包含 S/MIME 支持，既不会导致、也不会促成整体机制准确性的大幅提升。

A.2. 方法排除

曾有人建议 DMARC 包含一种机制，使域名所有者能够告知消息接收方不要尝试用某一种受支持的方法进行验证（例如"检查 DKIM，但不检查 SPF"）。

具体而言，设想一个已部署了其中一种技术、且该技术对某些消息会验证失败的域名所有者，但此类失败并不会触发强制处置动作。部署 DMARC 将对除 "none" 之外的策略触发强制处置动作，这似乎会将该域名所有者排除在参与之外。

DMARC 开发团队多次评估了策略例外机制的构想，并始终得出一致结论：没有足够强有力的用例足以将其纳入。DMARC 的特定目标受众似乎并不担心其中一种或另一种技术的失败模式会成为 DMARC 采用的障碍。

在上述场景中，域名所有者有几种选择：

  1. 收紧其基础设施，以最小化所部署单一技术的失败模式；
  2. 部署另一种受支持的认证机制，以抵消第一种机制的失败模式；
  3. 以仅报告（reporting-only）模式部署 DMARC。

A.3. Sender 头字段

在若干消息认证工作中，有人建议检查 Sender 头字段以寻找感兴趣的标识符，因为标准将此指示为表明内容被重新邮寄（例如通过邮件列表）的正确方式。最近一次，它曾是 DomainKeys 的协议级选项，但在演进到 DKIM 时，该属性被移除了。

DMARC 开发团队考虑了这一点，并决定不支持这样做，理由如下：

  1. 主要的用户保护思路是关注消息在渲染时用户所看到的内容。对于 Sender 字段的内容（如果存在）应如何处理，各类 MUA（邮件用户代理）之间并没有一致的行为。因此，支持检查 Sender 标识符意味着将策略应用于最终用户可能永远不会实际看到的标识符，这可能通过简单地伪造一个包含 DMARC 会认可的标识符的 Sender 字段，从而形成针对最终用户的攻击向量。
  2. 尽管 Sender 字段的用途确实如此，但以这种方式使用它同样不可靠，使其成为纳入 DMARC 评估算法的糟糕候选。
  3. 允许多种发现策略的方式，会在"应适用哪项策略、以及何时适用"方面，给 DMARC 评估算法引入不可接受的歧义。

A.4. 域名存在性测试

MTA 运营者之间的一种常见做法（事实上也是在 [ADSP] 中有所记载的做法）是：在进行任何更耗费资源的处理之前，先测试域名是否存在。这通常通过对正在评估的名称查询 DNS 的 MX、A 或 AAAA 资源记录来完成，并且如果可以确定该域名没有发布此类记录，就假定该域名不存在。

本协议的预标准化初始版本包含了一项此类性质的检查，且该检查是强制性的。它最终被移除，因为该方法在没有大量人工调优与启发式工作的情况下错误率过高。本工作确实需要处理的某些用例，这种方法会针对一个希望获得报告的域名返回否定结果——例如一个已注册、但从不发送合法邮件、因而在 DNS 中没有任何此类记录的域名。

A.5. ADSP 运营中的问题

DMARC 被形容为一种某种意义上的"超级 ADSP"。

DMARC 的贡献者根据运营经验，汇编了一份与 ADSP 相关的问题清单，这些问题影响了 DMARC 的方向：

  1. ADSP 不支持子域，即 example.com 的 ADSP 记录并不会显式或隐式地适用于 subdomain.example.com。如果不使用通配，那么垃圾邮件发送者便可以通过从未设置 ADSP 记录的子域发送，轻而易举地绕过 ADSP。
  2. 不存在的子域在 ADSP 中明确属于范围之外。ADSP 中没有任何内容声明接收方应简单地拒收来自 NXDOMAIN（不存在域名）的邮件，无论 ADSP 策略如何（这当然允许垃圾邮件发送者通过从不存在的子域发送电子邮件，轻而易举地绕过 ADSP）。
  3. ADSP 没有关于何时查找 ADSP 记录的运营建议。
  4. ADSP 不支持将 SPF 作为 DKIM 的辅助机制来使用。
  5. ADSP 不支持缓慢 rollout（渐进式推出），即无法配置接收方应在其上面应用策略的邮件百分比。这对大批量发送方而言很重要。
  6. ADSP 没有对"接收方隔离（例如投递到收件人的"垃圾邮件"文件夹）而非拒收邮件"这一中间阶段提供显式支持。
  7. "From" 头字段域名与 DKIM 之间的绑定对 ADSP 而言过于严格；二者必须精确匹配。

A.6. 组织域发现的问题

尽管像 ADSP 这样的协议对于"保护"某个特定域名是有用的，但它们对于保护子域却无能为力。如果有人希望通过 ADSP 要求所有携带 RFC5322.From 域 "example.com" 的邮件都被签名，从而"保护"该域；然而，他人随后可以构造一封 RFC5322.From 域为 "security.example.com" 的电子邮件，而 ADSP 将不提供任何保护。可以使用 DNS 通配，但这可能会不当地干扰其他 DNS 活动；也可以在发现欺诈性域名时添加 ADSP 记录，但此解决方案无法扩展，且纯粹是一种针对滥用的被动应对措施。

DNS 并未提供一种方法，能在给定任意域名的情况下，确定"登记在册的域"（即实际向域名注册商注册的域）。曾有建议试图从 SOA 或 NS 资源记录中获取此类信息，但这些同样并非完全可靠，因为 DNS 的分区并非总是发生在行政边界上。

当基于任意域名寻求特定于域的策略时，可以"攀爬树"（climb the tree），从名称左端逐层剥离标签，直到到达根或发现某项策略；但这样一来，他人又可以构造一个带有大量无意义标签的名称，这将导致邮件接收方为寻找策略记录而尝试大量查询。发送许多此类消息即构成了一种放大式拒绝服务攻击。

组织域机制是 DMARC 目标所必需的组成部分。第 3.2 节描述的方法远非完美，但在不向 DNS 添加不当负担或语义的情况下，较好地服务于这一目的。如果创建出一种比使用公共后缀列表更可靠、更安全的方法，DMARC 应在其普遍可用后尽快修订以采用该方法。

A.6.1. 公共后缀列表

用于确定组织域的公共后缀列表可从多种来源获取。最常见的一个由 Mozilla 基金会维护，并在 <http://publicsuffix.org> 公开提供。管辖该列表使用的许可条款可在该 URI 处获取。

请注意，如果运营者使用多种不同的公共后缀列表，互操作性将难以或无法得到保证。

附录 B. 示例

本节同时展示 DMARC 交换中域名所有者一侧与邮件接收方一侧的情形。

B.1. 标识符一致性示例

以下示例说明 DMARC 机制对标识符一致性的运用。为简洁起见，仅展示消息头，因为在执行 DMARC 检查时并不考虑消息体。

B.1.1. SPF

以下 SPF 示例假设 SPF 产生了通过（pass）的结果。

示例 1：SPF 处于一致状态：

        MAIL FROM: <sender@example.com>

        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，RFC5321.MailFrom 参数与 RFC5322.From 字段拥有完全相同的 DNS 域。因此，标识符处于一致状态。

示例 2：SPF 处于一致状态（父域）：

        MAIL FROM: <sender@child.example.com>

        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，RFC5322.From 参数包含一个作为 RFC5321.MailFrom 域父域的 DNS 域。因此，若域名所有者请求宽松 SPF 模式，则标识符处于一致状态；若请求严格 SPF 模式，则不一致。

示例 3：SPF 不一致：

        MAIL FROM: <sender@example.net>

        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，RFC5321.MailFrom 参数包含的 DNS 域既不同于、也非 RFC5322.From 域的父域。因此，标识符不一致。

B.1.2. DKIM

以下示例假设 DKIM 签名通过了验证。与未通过验证的 DKIM 签名不可能存在一致性。

示例 1：DKIM 处于一致状态：

        DKIM-Signature: v=1; ...; d=example.com; ...
        From: sender@example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，DKIM 的 "d=" 参数与 RFC5322.From 字段拥有完全相同的 DNS 域。因此，标识符处于一致状态。

示例 2：DKIM 处于一致状态（父域）：

        DKIM-Signature: v=1; ...; d=example.com; ...
        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，DKIM 签名的 "d=" 参数包含一个作为 RFC5322.From 域父域的 DNS 域。因此，标识符在宽松模式下处于一致状态，在严格模式下则不一致。

示例 3：DKIM 不一致：

        DKIM-Signature: v=1; ...; d=sample.net; ...
        From: sender@child.example.com
        Date: Fri, Feb 15 2002 16:54:30 -0800
        To: receiver@example.org
        Subject: here's a sample

在此情形下，DKIM 签名的 "d=" 参数包含的 DNS 域既不同于、也非 RFC5322.From 域的父域。因此，标识符不一致。

B.2. 域名所有者示例

希望使用 DMARC 的域名所有者应当已经部署并测试了 SPF 与 DKIM。下一步是发布一条 DNS 记录，为其组织域通告 DMARC 策略。

B.2.1. 整个域，仅监控

域名 "example.com" 的所有者已在其消息基础设施上部署了 SPF 与 DKIM。该所有者希望开始使用 DMARC，采用一项策略，在征求接收方聚合反馈的同时，不影响消息的处理方式，以便：

域名所有者通过构造如下策略记录来实现这一点：

当使用常见的命令行工具检索时，DMARC 策略记录可能如下所示：

     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

要发布此类记录，域名所有者的 DNS 管理员可在相应的区域文件中创建如下条目（遵循常规的区域文件格式）：

     ; DMARC record for the domain example.com

     _dmarc  IN TXT ( "v=DMARC1; p=none; "
                      "rua=mailto:dmarc-feedback@example.com" )

B.2.2. 整个域，仅监控，逐消息报告

前一示例中的域名所有者已利用聚合报告发现了一些尚未正确实施 DKIM 的消息系统，但他们仍然看到间歇性的认证失败。为了诊断这些偶发问题，他们希望在发生认证失败时请求逐消息失败报告。

并非所有接收方都会遵从此类请求，但域名所有者认为其收到的任何报告都足以证明其发布该记录的价值。默认的逐消息报告格式（[AFRF]）在此场景中满足了域名所有者的需求。

域名所有者通过在其附录 B.2 的策略记录中添加以下内容来实现这一点：

当使用常见的命令行工具检索时，DMARC 策略记录可能如下所示（所示输出本应显示为一行，但为发布需要在此处换行）：

     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
      ruf=mailto:auth-reports@example.com"

要发布此类记录，域名所有者的 DNS 管理员可在相应的区域文件中创建如下条目（遵循常规的区域文件格式）：

    ; DMARC record for the domain example.com

    _dmarc  IN TXT ( "v=DMARC1; p=none; "
                     "rua=mailto:dmarc-feedback@example.com; "
                     "ruf=mailto:auth-reports@example.com" )

B.2.3. 定向至第三方的逐消息失败报告

前一示例中的域名所有者保持着相同策略，但现在希望由一个第三方来接收并处理逐消息失败报告。同样，并非所有接收方都会遵从这一请求，但那些遵从的接收方可能实施额外检查，以验证该第三方确实希望接收此域的失败报告。

域名所有者需要按如下方式修改其附录 B.2.2 中的策略记录：

当使用常见的命令行工具检索时，DMARC 策略记录可能如下所示（所示输出本应显示为一行，但为发布需要在此处换行）：

     % dig +short TXT _dmarc.example.com.
     "v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com;
      ruf=mailto:auth-reports@thirdparty.example.net"

要发布此类记录，域名所有者的 DNS 管理员可在相应的区域文件中创建如下条目（遵循常规的区域文件格式）：

     ; DMARC record for the domain example.com

     _dmarc IN TXT ( "v=DMARC1; p=none; "
                     "rua=mailto:dmarc-feedback@example.com; "
                     "ruf=mailto:auth-reports@thirdparty.example.net" )

由于 "ruf" 标签中使用的地址位于发布此记录的域的组织域之外，符合规范的接收方将实施第 7.1 节所述的额外检查。为通过这些额外检查，第三方需要按如下方式发布一条额外的 DNS 记录：

当使用常见的命令行工具检索时，生成的 DNS 记录可能如下所示（所示输出本应显示为一行，但为发布需要在此处换行）：

     % dig +short TXT example.com._report._dmarc.thirdparty.example.net
     "v=DMARC1"

要发布此类记录，example.net 的 DNS 管理员可在相应的区域文件中创建如下条目（遵循常规的区域文件格式）：

     ; zone file for thirdparty.example.net
     ; Accept DMARC failure reports on behalf of example.com

     example.com._report._dmarc   IN   TXT    "v=DMARC1"

中介与其他第三方应参阅第 7.1 节以获取该机制的完整细节。

B.2.4. 子域、抽样与多个聚合报告 URI

域名所有者已在一个用于消息服务预生产测试的子域中实施了 SPF 与 DKIM。现在它希望请求参与的接收方拒收来自该子域、且未通过认证的消息。

作为第一步，它将要求把一部分（本示例中为 1/4）未通过认证的消息隔离，以便对投递到参与接收方托管的邮箱中的消息进行检查。聚合反馈报告将被发送至组织域内的一个邮箱，以及由域名所有者选定并授权接收的第三方处的一个邮箱。发送至第三方的聚合报告被限制为最大十兆字节。

域名所有者将通过构造如下策略记录来实现这一点：

当使用常见的命令行工具检索时，DMARC 策略记录可能如下所示（所示输出本应显示为一行，但为发布需要在此处换行）：

     % dig +short TXT _dmarc.test.example.com
     "v=DMARC1; p=quarantine; rua=mailto:dmarc-feedback@example.com,
      mailto:tld-test@thirdparty.example.net!10m; pct=25"

要发布此类记录，域名所有者的 DNS 管理员可在相应的区域文件中创建如下条目：

     ; DMARC record for the domain example.com

     _dmarc IN  TXT  ( "v=DMARC1; p=quarantine; "
                       "rua=mailto:dmarc-feedback@example.com,"
                       "mailto:tld-test@thirdparty.example.net!10m; "
                       "pct=25" )

B.3. 邮件接收方示例

希望使用 DMARC 的邮件接收方应当已经在检查 SPF 与 DKIM，并且具备从各个邮件处理阶段收集相关信息、以便向域名所有者（可能经由报告接收方）提供反馈的能力。

B.3.1. SMTP 时段的处埋

一个最优的、启用 DMARC 的邮件接收方会在 [SMTP] 会话期间执行认证与标识符一致性检查。

在返回对 DATA 命令的最终回复之前，邮件接收方的 MTA 已经执行了：

  1. 一次 SPF 检查，以确定一个经过 SPF 认证的标识符；
  2. 一次或多次 DKIM 检查，产生一个或多个经过 DKIM 认证的标识符；
  3. 一次 DMARC 策略查找。

存在作者域 DMARC 记录，表明邮件接收方应在返回对 DATA 命令的回复之前，继续进行 DMARC 特定的处理。

给定一条 DMARC 记录与一组已认证标识符，邮件接收方检查这些已认证标识符是否与作者域对齐（将 DMARC 记录中发现的任何严格或宽松选项考虑在内）。

例如，以下示例数据被视为来自 "example.com" 的域名所有者所发出的一封电子邮件：

     Author Domain: example.com
     SPF-authenticated Identifier: mail.example.com
     DKIM-authenticated Identifier: example.com
     DMARC record:
       "v=DMARC1; p=reject; aspf=r;
        rua=mailto:dmarc-feedback@example.com"

在上述示例中，经过 SPF 认证的标识符与经过 DKIM 认证的标识符都与作者域对齐。邮件接收方认为上述电子邮件通过了 DMARC 检查，从而避免了将适用于未通过 DMARC 检查的电子邮件的 "reject" 策略。

如果没有任何已认证标识符与作者域对齐，则邮件接收方应用 DMARC 记录所指定的策略。然而，在采取此动作之前，邮件接收方可以咨询外部信息以覆盖域名所有者的策略。例如，如果邮件接收方知道这封特定电子邮件来自一个已知且受信任的转发方（它恰好同时破坏了 SPF 与 DKIM），那么邮件接收方可以选择忽略域名所有者的策略。

邮件接收方现已准备回复 DATA 命令。如果 DMARC 检查得出消息应被拒收，则邮件接收方以 5xy 代码回复，以告知发送方失败。如果 DMARC 检查因暂时性网络错误而无法解析，则邮件接收方以 4xy 代码回复，以告知发送方需要稍后重新尝试投递。如果 DMARC 检查得出消息通过，则邮件接收方继续正常的邮件处理流程。

B.4. 聚合反馈的利用：示例

聚合反馈由域名所有者消费，用以核实域名所有者对其域在邮件接收方处被如何处理的理解。关于通过了所有 DMARC 所支持的认证检查的电子邮件的聚合报告数据，被域名所有者用来验证其认证实践是否保持准确。例如，如果某第三方正代表域名所有者发送邮件，域名所有者可以利用聚合报告数据来核实该第三方的持续认证实践。

仅部分通过底层认证检查的电子邮件的数据，提供了对需要由域名所有者解决的问题的可见性。例如，如果 SPF 或 DKIM 其中之一未能通过，域名所有者将获得足够的信息，要么直接纠正问题，要么了解认证破坏性的变更是在邮件传输路径的何处被引入的。如果由于邮件传输路径导致的认证破坏性变更无法直接纠正，那么域名所有者至少能够理解基于 DMARC 的策略对其电子邮件所产生的影响。

未通过所有底层认证检查的电子邮件的数据，提供了关于域名所有者的域在邮件接收方处如何被接收的基线可见性。基于此可见性，域名所有者可以开始在未覆盖的邮件源上部署认证技术。此外，域名所有者可能由此理解其域正如何被滥用。

B.5. mailto 传输示例

DMARC 记录可以包含一个 "mailto" 报告地址，例如：

     mailto:dmarc-feedback@example.com

来自 mail.receiver.example 的邮件接收方的一份聚合报告样例如下：

     DKIM-Signature: v=1; ...; d=mail.receiver.example; ...
     From: dmarc-reporting@mail.receiver.example
     Date: Fri, Feb 15 2002 16:54:30 -0800
     To: dmarc-feedback@example.com
     Subject: Report Domain: example.com
         Submitter: mail.receiver.example
         Report-ID: <2002.02.15.1>
     MIME-Version: 1.0
     Content-Type: multipart/alternative;
         boundary="----=_NextPart_000_024E_01CC9B0A.AFE54C00"
     Content-Language: en-us

     This is a multipart message in MIME format.

     ------=_NextPart_000_024E_01CC9B0A.AFE54C00
     Content-Type: text/plain; charset="us-ascii"
     Content-Transfer-Encoding: 7bit

     This is an aggregate report from mail.receiver.example.

     ------=_NextPart_000_024E_01CC9B0A.AFE54C00
     Content-Type: application/gzip
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment;
         filename="mail.receiver.example!example.com!
                   1013662812!1013749130.gz"

     <gzipped content of report>

     ------=_NextPart_000_024E_01CC9B0A.AFE54C00--

上例中未显示的是，邮件接收方的反馈应当使用 SPF 进行认证。此外，"filename" MIME 参数的值在本规范中为便于打印而进行了换行，但在正常情况下应作为单个连续字符串出现。

附录 C. DMARC XML 模式

以下是为本文档所述的 XML 格式聚合报告所提议的初始模式。

注意：根据 XML 的定义，除下文模式中有特别指定外，每个元素的 minOccurs 与 maxOccurs 值均设为 1。

   <?xml version="1.0"?>
   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
     targetNamespace="http://dmarc.org/dmarc-xml/0.1">

   <!-- The time range in UTC covered by messages in this report,
        specified in seconds since epoch. -->
   <xs:complexType name="DateRangeType">
     <xs:all>
       <xs:element name="begin" type="xs:integer"/>
       <xs:element name="end" type="xs:integer"/>
     </xs:all>
   </xs:complexType>

   <!-- Report generator metadata. -->
   <xs:complexType name="ReportMetadataType">
     <xs:sequence>
       <xs:element name="org_name" type="xs:string"/>
       <xs:element name="email" type="xs:string"/>
       <xs:element name="extra_contact_info" type="xs:string"
                   minOccurs="0"/>
       <xs:element name="report_id" type="xs:string"/>
       <xs:element name="date_range" type="DateRangeType"/>
       <xs:element name="error" type="xs:string" minOccurs="0"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <!-- Alignment mode (relaxed or strict) for DKIM and SPF. -->
   <xs:simpleType name="AlignmentType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="r"/>
       <xs:enumeration value="s"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- The policy actions specified by p and sp in the
        DMARC record. -->
   <xs:simpleType name="DispositionType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="quarantine"/>
       <xs:enumeration value="reject"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- The DMARC policy that applied to the messages in
        this report. -->
   <xs:complexType name="PolicyPublishedType">
     <xs:all>
       <!-- The domain at which the DMARC record was found. -->
       <xs:element name="domain" type="xs:string"/>
       <!-- The DKIM alignment mode. -->
       <xs:element name="adkim" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The SPF alignment mode. -->
       <xs:element name="aspf" type="AlignmentType"
                   minOccurs="0"/>
       <!-- The policy to apply to messages from the domain. -->
       <xs:element name="p" type="DispositionType"/>
       <!-- The policy to apply to messages from subdomains. -->
       <xs:element name="sp" type="DispositionType"/>
       <!-- The percent of messages to which policy applies. -->
       <xs:element name="pct" type="xs:integer"/>
       <!-- Failure reporting options in effect. -->
       <xs:element name="fo" type="xs:string"/>
     </xs:all>
   </xs:complexType>

   <!-- The DMARC-aligned authentication result. -->
   <xs:simpleType name="DMARCResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- Reasons that may affect DMARC disposition or execution
        thereof. -->
   <xs:simpleType name="PolicyOverrideType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="forwarded"/>
       <xs:enumeration value="sampled_out"/>
       <xs:enumeration value="trusted_forwarder"/>
       <xs:enumeration value="mailing_list"/>
       <xs:enumeration value="local_policy"/>
       <xs:enumeration value="other"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- How do we allow report generators to include new
        classes of override reasons if they want to be more
        specific than "other"? -->
   <xs:complexType name="PolicyOverrideReason">
     <xs:all>
       <xs:element name="type" type="PolicyOverrideType"/>
       <xs:element name="comment" type="xs:string"
                   minOccurs="0"/>
     </xs:all>
   </xs:complexType>

   <!-- Taking into account everything else in the record,
        the results of applying DMARC. -->
   <xs:complexType name="PolicyEvaluatedType">
     <xs:sequence>
       <xs:element name="disposition" type="DispositionType"/>
       <xs:element name="dkim" type="DMARCResultType"/>
       <xs:element name="spf" type="DMARCResultType"/>
       <xs:element name="reason" type="PolicyOverrideReason"
                   minOccurs="0" maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <!-- Credit to Roger L. Costello for IPv4 regex
        http://mailman.ic.ac.uk/pipermail/xml-dev/1999-December/
             018018.html -->
   <!-- Credit to java2s.com for IPv6 regex
        http://www.java2s.com/Code/XML/XML-Schema/
             IPv6addressesareeasiertodescribeusingasimpleregex.htm -->
   <xs:simpleType name="IPAddress">
     <xs:restriction base="xs:string">
       <xs:pattern value="((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]).){3}
                   (1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])|
                   ([A-Fa-f0-9]{1,4}:){7}[A-Fa-f0-9]{1,4}"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="RowType">
     <xs:all>
       <!-- The connecting IP. -->
       <xs:element name="source_ip" type="IPAddress"/>
       <!-- The number of matching messages. -->
       <xs:element name="count" type="xs:integer"/>
       <!-- The DMARC disposition applying to matching
            messages. -->
       <xs:element name="policy_evaluated"
                   type="PolicyEvaluatedType"
                   minOccurs="1"/>
     </xs:all>
   </xs:complexType>

   <xs:complexType name="IdentifierType">
     <xs:all>
       <!-- The envelope recipient domain. -->
       <xs:element name="envelope_to" type="xs:string"
                   minOccurs="0"/>
       <!-- The RFC5321.MailFrom domain. -->
       <xs:element name="envelope_from" type="xs:string"
                   minOccurs="1"/>
       <!-- The RFC5322.From domain. -->
       <xs:element name="header_from" type="xs:string"
                   minOccurs="1"/>
     </xs:all>
   </xs:complexType>

   <!-- DKIM verification result, according to RFC 7001
        Section 2.6.1. -->
   <xs:simpleType name="DKIMResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
       <xs:enumeration value="policy"/>
       <xs:enumeration value="neutral"/>
       <xs:enumeration value="temperror"/>
       <xs:enumeration value="permerror"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="DKIMAuthResultType">
     <xs:all>
       <!-- The "d=" parameter in the signature. -->
       <xs:element name="domain" type="xs:string"
                   minOccurs="1"/>
       <!-- The "s=" parameter in the signature. -->
       <xs:element name="selector" type="xs:string"
                   minOccurs="0"/>
       <!-- The DKIM verification result. -->
       <xs:element name="result" type="DKIMResultType"
                   minOccurs="1"/>
       <!-- Any extra information (e.g., from
            Authentication-Results). -->
       <xs:element name="human_result" type="xs:string"
                   minOccurs="0"/>
     </xs:all>
   </xs:complexType>

   <!-- SPF domain scope. -->
   <xs:simpleType name="SPFDomainScope">
     <xs:restriction base="xs:string">
       <xs:enumeration value="helo"/>
       <xs:enumeration value="mfrom"/>
     </xs:restriction>
   </xs:simpleType>

   <!-- SPF result. -->
   <xs:simpleType name="SPFResultType">
     <xs:restriction base="xs:string">
       <xs:enumeration value="none"/>
       <xs:enumeration value="neutral"/>
       <xs:enumeration value="pass"/>
       <xs:enumeration value="fail"/>
       <xs:enumeration value="softfail"/>
       <!-- "TempError" commonly implemented as "unknown". -->
       <xs:enumeration value="temperror"/>
       <!-- "PermError" commonly implemented as "error". -->
       <xs:enumeration value="permerror"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="SPFAuthResultType">
     <xs:all>
       <!-- The checked domain. -->
       <xs:element name="domain" type="xs:string" minOccurs="1"/>
       <!-- The scope of the checked domain. -->
       <xs:element name="scope" type="SPFDomainScope" minOccurs="1"/>
       <!-- The SPF verification result. -->
       <xs:element name="result" type="SPFResultType"
                   minOccurs="1"/>
     </xs:all>
   </xs:complexType>

   <!-- This element contains DKIM and SPF results, uninterpreted
        with respect to DMARC. -->
   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

   <!-- This element contains all the authentication results that
        were evaluated by the receiving system for the given set of
        messages. -->
   <xs:complexType name="RecordType">
     <xs:sequence>
       <xs:element name="row" type="RowType"/>
       <xs:element name="identifiers" type="IdentifierType"/>
       <xs:element name="auth_results" type="AuthResultType"/>
     </xs:sequence>
   </xs:complexType>

   <!-- Parent -->
   <xs:element name="feedback">
     <xs:complexType>
       <xs:sequence>
         <xs:element name="version"
                     type="xs:decimal"/>
         <xs:element name="report_metadata"
                     type="ReportMetadataType"/>
         <xs:element name="policy_published"
                     type="PolicyPublishedType"/>
         <xs:element name="record" type="RecordType"
                     maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
   </xs:schema>

PolicyOverrideType 各取值的说明：

根据本规范生成的报告的 "version" 必须为值 1.0。

致谢

DMARC 以及提交给独立提交编辑（Independent Submission Editor）的本文档草案，是一个非正式的产业联盟——DMARC.org（见 <http://dmarc.org>）——长期努力的成果。参与的公司包括 Agari、American Greetings、AOL、Bank of America、Cloudmark、Comcast、Facebook、Fidelity Investments、Google、JPMorgan Chase & Company、LinkedIn、Microsoft、Netease、PayPal、ReturnPath、The Trusted Domain Project 以及 Yahoo!。尽管贡献者与支持者众多、难以一一列举，但以下个人做出了显著的贡献：J. Trent Adams、Michael Adkins、Monica Chew、Dave Crocker、Tim Draegen、Steve Jones、Franck Martin、Brett McDowell 以及 Paul Midgen。贡献者还希望感谢 J.D. Falk 在早期提供的宝贵意见与指导。

在 IETF 框架内的额外贡献由 Kurt Anderson、Michael Jack Assels、Les Barstow、Anne Bennett、Jim Fenton、J. Gomez、Mike Jones、Scott Kitterman、Eliot Lear、John Levine、S. Moonesamy、Rolf Sonneveld、Henry Timmes 以及 Stephen J. Turnbull 做出。

作者地址

Murray S. Kucherawy（主编）
EMail: superuser@gmail.com

Elizabeth Zwicky（主编）
Yahoo!
EMail: zwicky@yahoo-inc.com