[ SPF ]

SPF的 10 次查找限制:在修复之前跟踪评估路径

SPF限制整个路径上评估的 DNS 相关术语。嵌套包括计数、早期匹配很重要,并且缓存不会将超出限制的路径转变为合规路径。

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

[ 要点 ]

  • 十项限制适用于实际的递归评估。
  • 早期匹配和错误路径解释了不同的发件人结果。
  • 修复依赖关系,而不会丢失合法邮件或扩大权限。
在此页面上

SPF's 10 次查找限制 适用于SPF检查期间评估的指定 DNS 相关术语。这不是允许根记录中存在十个可见包含语句的规则。嵌套策略共享评估的限制,并且早期匹配可以在到达后续分支之前停止检查。

当超过计数期限限制时,结果为 permerror。有用的诊断通过适用的策略跟踪连接的发送者,并记录评估继续、匹配或失败的情况。该跟踪显示哪些依赖项需要注意以及业务仍需要哪些权限。

了解SPF含义

RFC 7208 §4.6.4 识别 包括, a, MX, 指针 和 存在,加上 重定向 修饰符,因为引起 DNS 查询的术语在评估时受到总体限制。在下面 RFC 7208 §4.1,引用的政策共享评估的全局限制,而不是接受新的独立津贴。

这 全部, ip4 和 ip6 机制不消耗该期限限制。这 经验值 尽管稍后可能会进行解释查找,但修饰符在SPF评估期间不会消耗它。其他限制和操作约束仍然适用,包括涉及MX / PTR扩展和 无效查找.

初始SPF TXT查找不应与评估的包含机制相混淆。诊断应说明其显示的数字代表什么:协议术语计数、静态扩展估计或观察到的DNS查询。

工作示例:两个包含导致第十一个术语

以下是使用保留示例域和文档 IP 地址的合成装置。它不是实时DNS ,也不是要粘贴的生产记录。

根本政策是:

v=spf1 include:billing.example.net include:messages.example.org -all

假设计费策略进一步评估三个包含,每个包含仅包含一个 ip4 机制和 -all。假设消息策略评估以相同方式构建的另外六个包含。假设每个达成的策略都有一个语法上有效的SPF TXT记录,所有DNS检索均成功,每个中间策略均以-all结尾,并且不存在其他术语。对于本示例,其授权地址均不与连接的发件人匹配。

  • 根计费包括:运行总计 1。
  • 三层嵌套计费包括:运行总计4。
  • 根消息包括:总计 5。
  • 前 5 条嵌套消息包括:总计 10 条。
  • 第六个嵌套消息包括:将超出限制,产生permerror 。

根仅包含两个可见的包含。完整的不匹配路径尝试第十一个计数项。

现在考虑与第一个嵌套计费策略匹配的不同发件人。在此装置中,在计算两次包含后即可通过。评估不会通过后面的消息服务分支继续进行,只是为了用完津贴。

这就是路径跟踪及其输入地址很重要的原因。这也是为什么静态扩展工具和接收器的特定评估可以显示不同的计数而不测量相同的东西。

追踪实际失败评估

收集连接 IP、SPF 评估的信封域、完整的相关TXT答案和接收器的诊断。保留时间:提供商的参考政策可能会在原始交付后发生更改。

记录每个计数达到的术语、引用的策略以及导致评估继续、匹配或失败的结果。区分过多的术语错误和格式错误的语法,几个 SPF记录、循环依赖或临时DNS故障。

根记录查找有助于建立起点:

挖掘TXT example.com 。 +全部 +答案

这 BIND挖掘手册 记录这些 DNS 查询/显示选项。它本身并不评估SPF或建立查找计数。 DNS查询命令不能替代跟踪。

选择可维护的校正

从过时的权限开始。在删除之前确认不再需要包含;共享服务和季节性邮件可能会使安静的时间间隔产生误导。

对于活动服务,请检查提供商支持的配置。专用的发送子域或受支持的自定义信封身份可能会减少不相关的依赖关系并改善治理,但身份和 结盟 还需要验证。

改变机制顺序可以改变评估的路径。测试代表性的合法和不匹配的输入,而不是首先移动最繁忙的服务并声明整个策略已修复。

扁平化可以用地址数据替换引用的策略并减少计数的术语。它还会产生维护工作:必须反映提供商地址的更改、删除过时的权限并检测故障。记录长度和DNS限制不会消失。不要使用宽范围或宽松的范围 +all 作为捷径。

检查对合法服务的影响

企业在向同一域添加服务多年后可能会遇到此问题。旧的包含保留,提供程序添加依赖项,并且没有人拥有完整的权限集。

请求服务级别的解释:哪些合法消息遇到失败路径,仍然需要哪些权限以及谁将维护替换。如果将提供商地址复制到其中,最便宜的表面修复可能会变得昂贵 一个记录 没有人保持最新状态。

通过恢复合法邮件和受控权限来判断结果。检查者数量减少是有用的证据,但这并不是全部业务结果。

验证生成的权限和DMARC对齐

需要维护服务到权限地图、负责任的变更以及所有受影响合法路线的证据。询问该修复是否引入了新的实时DNS依赖项、外包维护或保留了不必要的基础设施访问。

跟踪每项许可的原因和退休条件。技术上有效的SPF策略仍然可能授权过多。也没有成立 发件人信誉 或消息内容的安全性。

纠正后,重新评估之前失败的输入和代表性合法流量。然后验证 DMARC 分别对齐。对于不相关的信封域恢复的原始SPF通行证无法修复 对齐失败.

实用的外卖

成功的更正表明对相关输入的合规评估和持续的合法发送。保留依赖关系跟踪以及每个保留权限的原因。然后验证真实消息的对齐情况;修复后的原始SPF结果只是DMARC的一部分。

记录下一个决定

不匹配的赛程有 1+3+1+6=11 次尝试计数;第六个嵌套消息包含超过10条后的限制。早期计费匹配只需要两个包含。通过与评估路径计数分开的任何工具比较和标签图扩展来保留此假设集。这些示例没有执行评估器或网络查询。

[ 外卖 ]

十项限制适用于实际的递归评估。早期匹配和错误路径解释了不同的发件人结果。修复依赖关系,而不会丢失合法邮件或扩大权限。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

跟踪输入而不是计算可见包含。

收集连接 IP 和 SPF 评估身份,然后遵循相关策略中达到的每个计数术语。保留答案和时间安排,因为依赖关系可能会发生变化。

后续步骤

  1. 检查嵌套包含并重定向处理。
  2. 测试早期匹配和非匹配路径。
  3. 纠正后验证合法发送和DMARC对齐。

CISO / SecOps

查看留下的权限。

有效计数可以与过度授权共存。查看服务到权限映射、维护模型和重新设计创建的例外情况。

后续步骤

  1. 保留权限需要有业务原因。
  2. 避免使用宽范围或+all作为捷径。
  3. 跟踪依赖性和提供者变更的责任。

创始人/非技术人员

询问出了什么问题以及谁将维护修复。

随着新服务的添加和旧权限的保留,这个问题通常会累积。可持续的修复可以识别受影响的消息并保持依赖于提供商的数据最新。

后续步骤

  1. 询问哪个合法工作流程到达失败路径。
  2. 在删除权限之前确认过时的服务。
  3. 任何扁平化或地址刷新过程都需要所有者。

[ 常见问题解答 ]

常见问题

SPF限制 10 是否包含我的根记录中的语句?

否。Count 评估了整个路径中与 DNS 相关的术语,包括引用的策略。两个可见的包含项可能会导致超过十个计数项。

RFC 7208 §4.1 RFC 7208 §4.6.4

SPF是否包含单独的 10 个津贴?

不会。评估时会全局跟踪总体限制,包括递归包含和重定向处理。

RFC 7208 §4.1 RFC 7208 §4.6.4

ip4 和 ip6 消耗相同的查找余量吗?

它们不消耗指定的依赖于 DNS 的期限限制。这并不意味着猜测或过于宽泛的地址权限可以安全地替代维护的服务配置。

RFC 7208 §4.6.4

DNS缓存会修复超限SPF策略吗?

不。协议限制涉及评估的术语,而不仅仅是缓存未命中或出站DNS数据包。缓存的答案不会从评估中删除该术语。

RFC 7208 §4.6.4

为什么一个发件人可以通过,而另一个发件人则达到permerror ?

早期匹配机制可以在以后的依赖关系之前停止评估。不同的输入可能会到达路径的更多部分并遇到限制或其他错误。

RFC 7208 §4.6.2 RFC 7208 §4.6.4

我可以通过创建第二条SPF记录来解决此问题吗?

不会。多个适用的SPF策略会造成另一个错误情况。更正单个预期策略及其依赖性。

RFC 7208 §4.5

我们应该立即为SPF扁平化付出代价吗?

首先建立失败路径,删除真正过时的权限并评估支持的服务设计。扁平化可以有所帮助,但其地址刷新和维护职责需要明确的所有者和验证。

成功的修复应该展示什么?

对相关测试输入的合规评估、保留的合法发送、合理的权限、维护的依赖模型以及实际消息的预期DMARC对齐。

[ 来源 ]

来源

  1. RFC 7208

    部分 §2.4 · §4.1 · §4.5 · §4.6.2 · §4.6.4 · §5.2 · §5.6

  2. RFC 9989

    部分 §4.4 · §4.4.2

  3. BIND挖掘手册

    部分 dig 概要和查询选项

[ 词汇表 ]

词汇表

SPF
连接 IP 和相关SMTP身份的授权评估。

RFC 7208 §2.4

评估期限限制
一次SPF评估中最多 10 个指定的 DNS 查询引发术语,包括递归。

RFC 7208 §4.1 RFC 7208 §4.6.4

企业出处

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

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

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

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

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

知识库