一个 组织域 是一个边界,用于 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.example | v=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快照和结果,以便其他操作员可以重现比较。