[ 报告与调查 ]

外部报告授权:正确发布接收域权限

从检索到的策略域和目标主机构造外部DMARC报告授权名称,然后验证接收域的权限。

由EmailAuth研究团队提供 · 7 分钟阅读

[ 要点 ]

  • 报告目标必须授权外部报告关系。
  • 精确查找使用策略域,而不是猜测的组织快捷方式。
  • DNS授权并不证明邮箱摄取或报告完整性。
在此页面上

两方建立报告关系

在域中发布报告目标 DMARC 策略表达了域所有者的请求。它并不单方面要求无关目的地接受由此产生的报告。 外部目的地验证 保护收件人不被选为不愿意的报告目标。接收方通过DNS发布权限,而报告方在使用外部目标之前检查该权限。

RFC 9990 当相关的 组织领域 比较显示了汇总报告的外部目的地。不要用发件人地址和报告地址中的字符串不同的简单测试来替换该规则。必须保留发现的策略域、目标主机和组织域上下文,以便执行验证的决策是可重现的。 RFC 9990 ,第 4 节

按正确的顺序构造所有者名称

从报告 URI 中提取目标主机。前置_report。 _dmarc ,然后添加从中检索策略的域名,并根据需要将该域转换为 A 标签。生成的DNS所有者的格式为:policy-domain._report。 _dmarc.destination-host.查询的是 TXT记录。如果构造的名称超出DNS限制,则无法做出肯定的授权确定。

此构造使用从中检索策略的实际域。不要仅仅因为熟悉的父级看起来像组织的品牌而将其缩写为熟悉的父级。同样,mailto 地址的本地部分也不会插入到DNS所有者名称中。保留原始 URI 和解析的目标主机,以便审阅者可以看到如何从输入中得出构造的名称。 RFC 9990 ,第 4 节

验证响应而不是识别熟悉的字符串

返回的记录被解析为标记值列表。强制v=DMARC1标记必须首先出现,尾随分号是可选的。未通过指定解析测试的记录将被丢弃。至少一项剩余的合格记录确立了该程序下的外部报告安排。空答案、不相关的TXT值或 一个记录 错误的版本放置不会建立权限。

DMARC版本值区分大小写: DMARC1是必需的值,而不是小写近似值或新发明的协议版本。 DNS名称比较规则不应与版本值的大小写要求混淆。审查应保留确切的答案字节和记录边界,而不是在验证之前规范化细节。 RFC 9990 ,第 4 节; RFC 9989 ,第 4.7 和 4.8 节

尊重覆盖和失败行为

授权记录可以提供程序下的报告目的地覆盖。覆盖 URI 必须使用在开始时提取的相同目标主机。此限制可防止授权响应将进程重定向到一系列不相关的收件人。如果确认包含对不同主机的覆盖,则报告生成器不得生成针对原始 URI 或覆盖 URI 的报告。

如果验证未确认授权,则必须忽略外部 URI。临时DNS错误有其自己的处理方法:接收方可能会选择暂时传送失败,以便稍后可以重复验证测试。可以保留该权限,而不是通用重试保证或经过测试的实现的描述。成功的DNS检查仍然不能证明目标邮箱存在、接受报告大小或向目标客户仪表板提供数据。 RFC 9990 ,第 4 节

区分聚合请求和故障报告请求

为了 汇总报告,该过程与 rua 相关联。故障报告在中单独指定 RFC 9991。对于外部故障报告目的地,该文档需要相同的外部验证过程,无论 rua 出现在哪里,都用 ruf 代替。不要仅仅因为聚合报告正在流动而将故障报告视为自动启用,或者复制聚合目标处理而不确认单独的报告类型。

故障报告 引起额外的数据暴露问题,因为它们的内容可能比汇总摘要更详细。正确的DNS授权记录不能替代组织关于可以共享哪些数据、与谁共享以及出于什么目的共享数据的决定。本手稿不允许请求、传输或上传实际报告。任何实际设置都必须满足适用的隐私、接收者和操作批准。 RFC 9991 ,第 5 节和第 7 节

虚构施工及验收工作表

假设从blue.example.com检索到虚构策略并通过mailto:reports@red.example.net.构造的授权所有者是blue.example.com._report._dmarc.red.example.net 。一个假设的TXT答案,其完整值为v=DMARC1;满足图示的版本优先要求。未执行任何DNS查询,并且此示例不声明这些名称已发布记录。

工作表应保留策略查找结果、发现的策略域、原始报告 URI、目标主机、组织域比较、构造的所有者、查询类型、时间戳、准确返回的记录和解析结果。为任何覆盖添加单独的字段并确认其主机限制。审阅者应该能够在不依赖提供商屏幕截图或DNS编辑器的缩写显示的情况下重建名称。

使用第二个接受部分进行收集:预期帐户、目标邮箱、授权报告类型和管道所有者。这些字段描述了计划的验证工作流程,而不是完整的摄取证据。使DNS关系结果与接收、解析、租户归属和仪表板呈现区分开来。权限检查可能会成功,而收集路径的另一部分仍未解决。

发布和实施保留

该目录需要从源域和目标域构建精确的授权查找并验证其答案。本草案仅提供虚构的结构。实际答案、原始查询记录和接收域实现仍然开放。没有发布DNS记录,没有访问邮箱,也没有传输报告。

在作为操作演练发布之前,获取确切生产关系的授权证据,并让合格的审阅者确认策略发现上下文、版本解析和覆盖处理。保留源日期并将标准要求与提供商特定的帐户入门区别开来。所有六个发布大门均保持开放,包括原始证据、人工审查、来源适用性、生产路线、视觉可及性和所有者发布。

稍后对目标域或策略发现域的更改可能会更改所需的授权所有者。将其视为新的范围关系进行验证,而不是假设旧的肯定检查涵盖了每个未来的报告地址。有用的结果是可审核的权限链,而不仅仅是复制的TXT值。

[ 外卖 ]

与发送者的报告请求和收集管道分开验证确切的接收域权限。

[ 按角色 ]

这对您意味着什么

选择您的角色以执行后续实际步骤。

域名所有者

请求预定目的地

报告请求本身并不授权无关的接收者。

后续步骤

  1. 保留发现的策略域。
  2. 批准收件人和报告类型。

举报消费者

发布范围权限

接收域控制确认答案。

后续步骤

  1. 验证确切的所有者和价值。
  2. 查看任何覆盖主机。

实施审核员

将DNS与摄取分开

授权并不能证明仪表板功能正常。

后续步骤

  1. 保留准确的查询证据。
  2. 独立检查收集和归属。

[ 常见问题解答 ]

常见问题

谁发布外部许可?

报告使用者在其接收域DNS中发布确认记录。

RFC 9990 : DMARC聚合报告

哪个源域进入查找?

从中检索策略的域,如果需要,将转换为 A 标签。

RFC 9990 : DMARC聚合报告

邮箱本地部分是否输入所有者姓名?

否。该构造使用目标主机。

RFC 9990 : DMARC聚合报告

v=DMARC1必须放在第一位吗?

是的。外部授权解析需要强制的第一个标签。

RFC 9990 : DMARC聚合报告

dmarc1 是等效的版本值吗?

否。指定的DMARC1版本值区分大小写。

RFC 9989: DMARC

覆盖可以使用另一个目标主机吗?

否。覆盖仅限于原始目标主机。

RFC 9990 : DMARC聚合报告

该程序是否也适用于 ruf?

RFC 9991要求RFC 9990过程中使用 ruf 代替 rua 作为外部故障目的地。

RFC 9991 : DMARC故障报告

虚构的答案是否已在DNS中得到验证?

不会。实际构建和答案验证仍保留原始证据。

[ 来源 ]

来源

  1. RFC 9989: DMARC

    部分 §4.4 标识符对齐说明 · §4.7 DMARC策略记录格式 · §4.8 正式定义 · §5 DMARC参与

  2. RFC 9990 : DMARC聚合报告

    部分 §3.1 汇总报告 · §3.3 报告期间的策略变更 · §3.4 报告请求发现 · §3.5 报告传送 · §4 验证外部目标 · §5 可扩展报告 · §8.1 将内容报告为攻击 · §8.2 虚假信息 · §9 操作注意事项 · §9.3 报告存储 · 附录 A DMARC XML 架构

  3. RFC 9991 : DMARC故障报告

    部分 §2 DMARC故障报告 · §4 报告格式更新 · §5 验证外部目标 · §7 隐私注意事项

[ 词汇表 ]

词汇表

策略域
从中检索DMARC策略以进行此授权构建的域。

RFC 9990 : DMARC聚合报告

目的主机
从报告 URI 中提取的主机,用于外部验证过程。

RFC 9990 : DMARC聚合报告

授权拥有者
构造的DNS名称查询接收域权限。

RFC 9990 : DMARC聚合报告

收款验证
授权报告到达预期系统并由其处理的单独证据。

企业出处

为什么顶级金融机构和政府 退役了他们的电子邮件安全仪表板。

传统的电子邮件身份验证平台会向您出售仪表板并要求您的工程师来完成这项工作。在高风险环境中,手动监督意味着延迟执行、配置漂移和不受监控的影子域。

EmailAuth是代理电子邮件来源平台。 我们的代理人强制执行 p=reject,保持第三方发件人一致并将您的域名移至完整状态 RFC 9989 合规性、新的DMARC标准,以及人机交互审核能力。

政府 大型企业 一级金融机构

SaaS · 专用租赁 · 气隙本地部署 · BYOK 加密

知识库