Skip to main content

6. Policy (策略)

DMARC 策略由域所有者 (Domain Owners) 发布并由邮件接收方 (Mail Receivers) 应用。

域所有者通过向这些域添加 DNS TXT 记录 (在第 6.1 节中描述) 来宣传一个或多个域的 DMARC 参与。通过这样做，域所有者向邮件接收方提出关于声称来自域所有者域之一的消息的处置以及关于这些消息的反馈提供的具体请求。

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

实施 DMARC 机制的邮件接收方应该 (SHOULD) 在消息未通过 DMARC 测试时尽最大努力遵守域所有者发布的 DMARC 策略。由于电子邮件流可能很复杂 (由于转发、现有的 RFC5322.From 域欺骗服务等)，邮件接收方可以 (MAY) 在消息处理期间偏离域所有者发布的策略，并且应该 (SHOULD) 通过反馈报告向域所有者提供偏离的事实和原因，特别是使用聚合报告的"PolicyOverride"功能 (参见第 7.2 节)。

6.1. DMARC Policy Record (DMARC 策略记录)​

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

DMARC 对域名服务的使用是由 DMARC 对域名的使用及其执行的查询的性质驱动的。查询要求与 DNS 匹配，用于获取简单的参数信息。它使用一种已建立的存储信息的方法，与目标域名相关联，即仅限于 DMARC 上下文的隔离 TXT 记录。使用 DNS 作为查询服务的好处是重用了一个非常成熟的运营、管理和管理基础设施，而不是创建一个新的基础设施。

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

6.2. DMARC URIs (DMARC URI)​

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

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

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

因此，DMARC URI 是一个 URI，其中任何逗号或感叹号都根据 [URI] 进行百分比编码，后跟可选的 (OPTIONAL) 感叹号和最大大小规范，如果列表中有其他报告 URI，则后跟逗号和下一个 URI。

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

第 6.4 节提供了正式定义。

6.3. General Record Format (通用记录格式)​

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

第 11 节为已知的 DMARC 标签创建注册表，并注册本文档中定义的初始集合。只处理本文档或后续扩展中定义并因此添加到该注册表的标签; 必须 (MUST) 忽略未知标签。

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

adkim: (纯文本; 可选 (OPTIONAL); 默认为"r"。) 指示域所有者是否要求严格或宽松的 DKIM 标识符对齐模式。有关详细信息，请参见第 3.1.1 节。有效值如下:

  • r: 宽松模式
  • s: 严格模式

aspf: (纯文本; 可选 (OPTIONAL); 默认为"r"。) 指示域所有者是否要求严格或宽松的 SPF 标识符对齐模式。有关详细信息，请参见第 3.1.2 节。有效值如下:

  • r: 宽松模式
  • s: 严格模式

fo: 失败报告选项 (纯文本; 可选 (OPTIONAL); 默认为"0") 提供生成失败报告的请求选项。报告生成器可以 (MAY) 选择遵守请求的选项。如果还未指定"ruf"标签 (见下文)，则必须 (MUST) 忽略此标签的内容。此标签的值是冒号分隔的字符列表，指示失败报告选项如下:

  • 0: 如果所有底层认证机制都未能产生对齐的"通过 (pass)" 结果，则生成 DMARC 失败报告。
  • 1: 如果任何底层认证机制产生了除对齐的"通过 (pass)" 结果之外的任何结果，则生成 DMARC 失败报告。
  • d: 如果消息具有评估失败的签名，则生成 DKIM 失败报告，无论其对齐如何。[AFRF-DKIM] 中描述了 DKIM 特定的报告。
  • s: 如果消息未通过 SPF 评估，则生成 SPF 失败报告，无论其对齐如何。[AFRF-SPF] 中描述了 SPF 特定的报告。

p: 请求的邮件接收方策略 (纯文本; 策略记录必需 (REQUIRED))。指示接收方应根据域所有者的请求执行的策略。策略适用于查询的域和子域，除非使用"sp"标签明确描述子域策略。此标签仅对策略记录是强制性的，但对于第三方报告记录则不是 (参见第 7.1 节)。可能的值如下:

  • none: 域所有者请求不对消息的传递采取任何特定操作。
  • quarantine: 域所有者希望邮件接收方将未通过 DMARC 机制检查的电子邮件视为可疑。根据邮件接收方的能力，这可能意味着"放入垃圾邮件文件夹"、"以更高强度审查"和/或"标记为可疑"。
  • reject: 域所有者希望邮件接收方拒绝未通过 DMARC 机制检查的电子邮件。拒绝应该 (SHOULD) 在 SMTP 事务期间发生。有关 SMTP 拒绝方法及其影响的一些讨论，请参见第 10.3 节。

pct: (0 到 100 之间的纯文本整数，包括 0 和 100; 可选 (OPTIONAL); 默认为 100)。域所有者的邮件流中应用 DMARC 策略的消息百分比。但是，这不得 (MUST NOT) 应用于 DMARC 生成的报告，所有报告都必须不受阻碍地发送和接收。"pct"标签的目的是允许域所有者缓慢推出 DMARC 机制的执行。

rf: 用于消息特定失败报告的格式 (冒号分隔的纯文本值列表; 可选 (OPTIONAL); 默认为"afrf")。此标签的值是域所有者请求的一种或多种报告格式的列表，用于在消息未通过 SPF 和 DKIM 测试时报告单个失败的详细信息。目前仅定义了"afrf" ([AFRF] 中定义的 auth-failure 报告类型)。

ri: 聚合报告之间请求的间隔 (纯文本 32 位无符号整数; 可选 (OPTIONAL); 默认为 86400)。向接收方指示生成至少由请求的秒数分隔的聚合报告的请求。DMARC 实施必须 (MUST) 能够提供每日报告，并且应该 (SHOULD) 能够在请求时提供每小时报告。但是，除每日报告之外的任何内容都被理解为尽最大努力提供。

rua: 应将聚合反馈发送到的地址 (逗号分隔的 DMARC URI 纯文本列表; 可选 (OPTIONAL))。应将聚合反馈发送到的 DMARC URI 的逗号分隔列表 (有关 DMARC URI 的规范，请参见第 6.2 节)。可以指定任何有效的 URI。邮件接收方必须 (MUST) 实施对"mailto:" URI 的支持，即通过电子邮件发送 DMARC 报告的能力。如果未提供，邮件接收方不得 (MUST NOT) 生成聚合反馈报告。邮件接收方不支持的 URI 必须 (MUST) 被忽略。聚合反馈报告应该 (SHOULD) 使用第 7.2 节中描述的格式。

ruf: 应将消息特定失败信息报告到的地址 (逗号分隔的 DMARC URI 纯文本列表; 可选 (OPTIONAL))。应将消息特定失败报告发送到的 DMARC URI 的逗号分隔列表 (有关 DMARC URI 的规范，请参见第 6.2 节)。如果未提供，邮件接收方不得 (MUST NOT) 生成失败报告。邮件接收方可以 (MAY) 选择以 [AFRF] 以外的格式发送失败报告。

sp: 所有子域的请求邮件接收方策略 (纯文本; 可选 (OPTIONAL))。指示接收方应根据域所有者的请求执行的策略。它仅适用于查询域的子域，而不适用于域本身。其语法与上面定义的"p"标签相同。如果不存在，则必须 (MUST) 对子域应用由"p"标签指定的策略。

v: 版本 (纯文本; 必需 (REQUIRED))。将检索到的记录标识为 DMARC 记录。它必须 (MUST) 具有"DMARC1"的值。此标签的值必须 (MUST) 首先出现在 DMARC 记录中。示例: "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

6.4. Formal Definition (正式定义)​

(有关完整的 ABNF 语法，请参阅 RFC 7489)

6.5. Domain Owner Actions (域所有者操作)​

要参与 DMARC，域所有者需要:

  1. 为域部署 SPF 和/或 DKIM。

  2. 确保 RFC5322.From 域与 SPF 和/或 DKIM 认证的域对齐。

  3. 在 DNS 中发布 DMARC 策略。

  4. 监控反馈报告并根据需要调整策略。

6.6. Mail Receiver Actions (邮件接收方操作)​

邮件接收方通过查询 DNS 中的 DMARC 策略记录并将请求的策略应用于未通过 DMARC 评估的消息来实施 DMARC。

6.6.1. Extract Author Domain (提取作者域)​

邮件接收方需要从 RFC5322.From 头字段中提取域。要评估的域是 RFC5322.From 字段的域部分。

6.6.2. Determine Handling Policy (确定处理策略)​

邮件接收方通过以下方式确定消息的适当处理策略:

  1. 在 "_dmarc.{RFC5322.From 域}" 处检查策略。
  2. 如果未找到，应用第 3.2 节中的算法来确定组织域，并在 "_dmarc.{组织域}" 处检查策略。
  3. 如果仍未找到，邮件接收方应用其自己的本地策略。

6.6.3. Policy Discovery (策略发现)​

域所有者可以在其域层次结构的任何点发布 DMARC 策略记录。邮件接收方在 "_dmarc.{域}" 处查询 DNS 以获取 DMARC TXT 记录。如果未找到，则确定组织域并对组织域重复查询。

6.6.4. Message Sampling (消息采样)​

"pct"标签允许域所有者通过指定仅应对一定百分比的消息应用策略来逐步部署 DMARC。"pct"机制未选择的消息被视为"p"标签设置为"none"。

6.7. Policy Enforcement Considerations (策略执行考虑)​

邮件接收方在执行 DMARC 策略时应考虑以下内容:

  1. 邮件列表 (Mailing Lists): 许多邮件列表以破坏 DKIM 签名并导致 SPF 检查失败的方式修改消息。

  2. 转发 (Forwarding): 简单转发不会破坏 DKIM 签名，但会导致 SPF 检查失败。

  3. 本地策略 (Local Policy): 邮件接收方可以根据本地知识或策略选择覆盖已发布的 DMARC 策略。

  4. 报告 (Reporting): 在覆盖策略时，邮件接收方应通过聚合报告中的 PolicyOverride 功能报告此情况。

Last updated on