[ DMARC和政策 ]

DMARC组织域:在比较身份之前追踪边界

使用当前DMARC发现规则来分离策略记录、组织域和身份比较,包括多部分后缀下的域。

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

在此页面上

一个 组织域 是一个边界,用于 DMARC 加工。当可见的发件人域没有自己的记录时,它可以帮助接收者找到策略,并且可以帮助比较宽松的身份验证身份 结盟。这些是相关的操作,但它们不是同一个问题。

“获取最后两个标签”的捷径是不可靠的。多部分公共后缀下的名称(例如co.uk )已经说明了为什么计算两个标签可以选择后缀而不是组织。当前的规范增加了避免走捷径的进一步原因: RFC 9989 定义DNS树行走而不是依赖于 公共后缀列表 独自的。

分别写下三个问题

从邮件发件人地址中的实际域开始,称为“作者域”。然后问:

  • 哪个DMARC策略记录适用于该作者域?
  • 适用的发现流程为每个比较的身份建立了哪些组织域?
  • 是否路过 SPF 或者 DKIM 身份是否满足所选的对齐方式?

直接位于作者域的有效记录将赢得策略选择。这并不能自动证明作者域是用于宽松对齐的组织域。将仅显示一个“域”字段的DNS检查器视为起始视图,并收集解释其结论所需的实际名称和响应。

这 身份链指南 帮助在发现开始之前识别发件人、信封和DKIM域。

遵循标记示例

以下是合成DNS快照。它说明了保留的 .example 命名空间下的虚构注册表;它不是实时查询结果或关于任何真实公共后缀的断言。

假设现有的作者域是invoice.harbour.registry.example 。它的消息有一个传递 DKIM签名 与d=sign.harbour.registry.example. SPF传递给不对齐的单独服务域。

查询目标说明性回应结果
_dmarc.invoice.harbour.registry.example无DMARC策略记录继续发现
_dmarc.harbour.registry.examplev=DMARC1; p=none; sp=quarantine; psd=n建立明确的组织边界并停止行走
_dmarc.registry.example停车后不查询本次步行无需进一步回复

所选策略是harbour.registry.example处的记录。由于invoice.harbour.registry.example存在并且是子域,因此其适用的评估策略是通过sp隔离。组织域是harbour.registry.example ,因为记录明确表示psd=n.

对于DKIM身份, _dmarc.sign.harbour.registry.example中的说明性查找不返回任何记录,后跟相同的psd=n边界记录。因此,经过身份验证的签名身份和作者域共享一个组织域。通过宽松的DKIM对齐,传递的DKIM签名提供了对齐的路径。严格对齐需要精确的身份相等,而这两个不同的名称不具备这一点。

该示例故意将策略选择、边界发现、身份验证和对齐保持为单独的结果可见。更改策略值不会将不相等的域字符串变成完全匹配。

了解是什么阻碍了行走

RFC 9989第 4.10 节指定了查询、记录过滤和限制。 psd=n的有效记录标识组织边界。 psd=y的有效记录标识公共后缀边界,组织域选择规则在适当时考虑其下方一个标签的域。

如果两个信号都无法解析边界,则规范提供选择和后备规则。它还限制长名称发现,以避免攻击者强制进行无限制的查找。生产实现需要完整的算法,包括无效或多个记录以及DNS错误;删除标签直到出现熟悉的名字并不能替代。

不要将psd=y复制到普通组织的记录中。它描述了一个后缀角色。 psd=n可以支持有意的组织边界,包括委托子树,但应遵循记录的名称空间决策而不是通用清单。

研究工具和接收器之间的差异

较旧的实现可能使用与以下相关的公共后缀方法 RFC 7489。较新的实现可能遵循RFC 9989树遍历。因此,当结果不一致时, DNS响应、缓存和实施支持可能很重要。

为了进行有用的比较,请保留完整的身份名称、带有时间戳的查询响应、发现的策略记录、对齐设置和接收器结果。询问工具供应商它实现了哪种发现模型。不要从发布日期推断普遍采用,也不要仅仅为了使两个仪表板标签一致而更改DNS 。

将真正的边界分歧与原始身份验证问题分开。丢失的DKIM签名、失败的签名或未经批准的发送路由将不会变得有效,因为组织域计算已更正。

使边界成为操作记录

对于具有多个业务部门或委派DNS团队的域,记录谁可以在每个边界下发布以及哪些服务可以在此处验证邮件。当应用程序获得子域、业务部门更改DNS管理或供应商退休时,请重新访问该记录。

使用 子域策略验证 检查适用的政策,以及 对齐比较 在决定哪些域关系是可接受的时。

有用的结果是一个可重现的链:这些是消息身份,这些DNS响应建立了相关边界,应用了此策略,并且此传递的身份是否对齐。猜测的域标签无法提供该证据。

使用边界决策卡

使用此卡进行组织域选择,而不是替代策略发现。首先检查作者域的政策。即使对齐需要不同的边界计算,也可以应用直接策略。

指定步行期间的观察边界决定
有效记录包含psd=n停止;该记录的域是组织域。
有效记录包含远离起始域的psd=y停止;选择该公共后缀下方的域标签。
psd=y is at the starting domain步行停止,但“下面一个标签”规则不适用于该起始记录。应用选择规则,而不是发明子域。
有效记录的存在没有决定性的边界信号选择名称中标签最少的有效记录。不要自动选择第一个祖先记录。
未确定组织域使用初始目标域作为组织域。此后备不会创建策略记录。
主题名有很多标签应用八个查询界限:保留初始查询,然后根据指定缩短。不要查询任意长名称的每个祖先。

这些行总结了 RFC 9989第 4.10–4.10.2 节;记录过滤和 DNS 错误处理仍然适用。在策略发现期间未找到策略意味着DMARC不适用,即使对齐算法具有边界回退也是如此。

作为第二个虚构的跟踪,假设a.mail.example.com的遍历在mail.example.com和example.com中找到了有效记录,既没有psd=n也没有psd=y,并且在其他地方都没有找到。所选的组织域是example.com 。如果mail.example.com相反发出psd=n,则步行会在那里停止,并且更具体的边界获胜。保留DNS快照和结果,以便其他操作员可以重现比较。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

单独记录策略和一致性。

一项发现的记录可以回答策略选择,而需要进一步的身份分析才能轻松对齐。

后续步骤

  1. 保留准确的查询名称和响应。
  2. 确认接收器或工具发现模型。
  3. 边界更改后测试实际消息。

CISO / SecOps

审查授权所带来的信任。

谁控制子树可以影响哪些经过身份验证的身份共享DMARC边界。

后续步骤

  1. 将DNS委托映射到负责任的所有者。
  2. 检查有意的psd=n边界。
  3. 评估协调决策以及供应商许可。

创始人/非技术人员

使域结构可解释。

复杂的命名空间需要有记录的操作边界,以便收购、供应商或业务部门不会引入无法解释的邮件故障。

后续步骤

  1. 分配委派域的所有权。
  2. 要求提供有效的身份和政策跟踪。
  3. 在服务启动中包含命名空间更改。

[ 常见问题解答 ]

常见问题

组织域总是最后两个标签吗?

不可以。多部分后缀已经使该快捷方式变得不可靠,并且当前的RFC 9989发现还使用DNS记录和定义的边界规则。

发件人域中的记录是否会使该域成为组织域?

它选择直接策略记录。松弛对齐的组织域确定是第 4.10.2 节管辖的一个单独问题。

psd=n在工作示例中意味着什么?

它明确地将harbour.registry.example标识为组织边界并停止所示的行走。

普通公司应该发布psd=y?

不要将该值复制到普通公司记录中。它表示公共后缀域角色,并且可以更改边界确定。

宽松对齐是否意味着任何两个子域都可以匹配?

否。将实际的组织域发现规则应用于身份,然后比较结果域。授权或明确的界限可能很重要。

为什么老检查员可能不同意当前接收员的意见?

他们可能会实现不同的发现模型或看到不同的DNS数据。在选择修复之前保留查询响应、时间戳和接收者的可信结果。

严格对齐是否需要组织域匹配?

严格对齐将相关身份与作者域进行精确比较。它不允许仅仅因为两者位于同一组织域下而使用不同的名称。

边界调查应保留哪些证据?

保留 From、 SPF和DKIM域、相关DNS响应、所选策略、发现模型和对齐结果,以及时间戳和受影响的服务所有者。

[ 来源 ]

来源

  1. RFC 9989 : DMARC核心协议

[ 词汇表 ]

词汇表

组织领域
适用的DMARC发现和宽松的对齐规则使用的域边界。通过最后两个标签并不总是能找到它。
作者域
DMARC评估的邮件可见发件人地址中的域。
DMARC对齐
可见发件人域与传递的SPF或DKIM身份之间所需的关系。严格对齐需要精确的域匹配;宽松的对齐使用适用的组织域关系。
权威DNS
负责相关公共区域的委派服务器。在不同提供商的非活动面板中进行编辑不会更改他们的答案。

企业出处

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

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

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

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

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

知识库