[ DMARC和政策 ]

DMARC permerror :在编辑策略之前识别持久性缺陷

将不可恢复的评估错误与有效身份验证失败、策略缺失和DNS可用性问题分开,然后修复负责层。

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

[ 要点 ]

  • 保留可信的方法特定错误和准确的诊断。
  • 在正确的阶段应用识别、语法和策略后备。
  • 修复已确定的原因并重新测试相同的工作流程。
在此页面上

在下面 RFC 9989 §9.2, dmarc=permerror 结果表明接收系统遇到了一个评估错误,它认为在以后的尝试中不太可能解决。这并不意味着每个合法发件人都未经授权,并且在没有证据支持的情况下无法识别确切的修复情况。

阅读完整的结果、其可信来源和相关的诊断文本。然后将策略解析、发现和底层身份验证分开,以便在正确的层修复持久缺陷。

保留观察到的结果及其来源

对于已送达的邮件,请保留原始邮件和可信收件人的完整信息 Authentication-Results 下的字段 RFC 8601 §7.1。记录其身份验证服务标识符、方法名称、结果以及任何关联的属性或说明。

对于被拒绝的邮件,保留完整返回的SMTP文本和发送平台事件。可能没有交付的标头。 SMTP故障中的“永久”一词本身并不能证明接收方报告了dmarc=permerror.

附加可见的发件人域、发送帐户、邮件参考、收件人和时间。这些详细信息可以让另一个操作员重现相关查找并评估相同的路线。

区分五种情况

以下综合调查矩阵描述了不同的证据,但不保证每个产品都有标签:

  • 案例:政策候选格式不正确;保留的证据:精确返回的字符串和解析器解释;修复方向:纠正已识别的语法缺陷
  • 案例:多个政策候选者针对一个目标;要保留的证据:完整 TXT记录 设置和发现踪迹;修复方向:协调候选人并检查任何后备方案
  • 案例:发现没有发现策略;需要保留的证据:否定答案的上下文和被询问的姓名;修复方向:制定预期的政策发布
  • 案例:所需的DNS查询不可用;要保留的证据:响应状态、解决者和时间;修复方向:调查分辨率和基础设施
  • 案例:有效策略,未传递对齐身份;保留证据:消息身份和认证结果;修复方向:纠正合法发送者支持的配置

有效的 DMARC 失败与评估错误不同。缺少策略也不同于无法回答查询的服务器。

使用 对齐指南 当证据显示普通原始认证或 结盟 失败而不是破坏策略处理。

在概括错误之前检查记录

在下面 RFC 9989 §4.7,版本标记必须首先具有精确值DMARC1 。使用注册的小写标签名称和每个标签的定义值规则。检查实际记录边界,而不是手动连接的屏幕截图。

不要将每一个缺陷都变成普遍的permerror声明。 RFC 9989 定义忽略的未知标签、特定于标签的默认值和条件策略处理。在下面 RFC 9989 §4.10.1,其当前的发现规则继续为 p=none 当 p 缺失或无效,或者 sp 或 np 无效时,仅当 rua 包含至少一个语法上有效的报告 URI 时。否则,根据这些规则, DMARC处理不会应用于该邮件。

这一条件并不是对任意格式错误的记录的普遍赦免。首先确定记录已达到相关解析和发现阶段。记录哪个规范和实现产生了观察到的分类。

通过发现检查重复的候选者

在下面 RFC 9989 §4.10,当前的树遍历规则会丢弃为单个目标返回的多个DMARC策略记录。他们不合并这些值。

第一次查询时缺少有效策略可能会导致进一步发现。然后,在另一个适用位置找到的策略可以管理该消息。仅显示第一个目标的工具尚未确定完整的结果。

保留实际的接收器诊断并比较完整的查找路径。 子域指南 当受影响的 From 域不同于 组织域.

不要将SPF permerror与DMARC permerror混淆

Authentication-Results方法有其自己的结果。 spf=permerror表示 SPF 对其评估身份的评估问题;它不会自动成为接收系统的DMARC结果。

例如,在成功DMARC策略发现的综合案例中, SPF语法缺陷可以与有效对齐的语法共存。 DKIM签名。该签名可以提供消息级DMARC传递路径 RFC 9989 §5.3.5。修复SPF缺陷并评估更广泛的参与要求,但不要重新标记观察到的DMARC结果。

同样,确定是否报告 DKIM 错误涉及密钥、签名或查找。保留特定于机制的证据,而不是假设一次DNS编辑可以修复每种方法。

修复一个已确定的缺陷并重新测试

保存完整的之前状态和预期批准的记录集。确定确切的负责所有者名称和DNS权限。报告集成或管理编辑可能造成了持续存在的问题。

进行有针对性的修正,并验证所得的权威数据。检查相关的递归观察并允许缓存早期数据。然后通过相同的帐户和路由发送受控代表消息并检查新的可信结果。

如果结果仍然存在,请将新证据与原始证据进行比较。不同阶段的新故障是诊断的进步,但仍需要自己的解释和修复。

以特定原因结束事件

“ DMARC已损坏”不是一个有用的关闭。更强有力的记录说明哪个记录或依赖性导致了观察到的错误、如何纠正错误以及重新测试确定了什么。

保留任何仍然重要的实现差异。当前RFC 9989要求和旧版接收器行为可能有所不同;不要承诺未经测试的更改将在各处产生一个标签。

永久性错误最好作为精确配置或评估结果来处理。恢复有效的操作路径,然后返回到维护合法对齐邮件的单独工作。

将决定和证据分开

在 SPF 错误固定装置中,记录spf=permerror和单独建立的dmarc=pass而不是用一种方法的结果替换另一种方法的结果。即使邮件具有幸存的对齐DKIM路径,也请保持SPF修复打开。对于缓存的更改, RFC 8767 §4 允许在过期后使用合格的陈旧答案。没有声称真正的接收机诊断或维修。

[ 外卖 ]

保留可信的方法特定错误和准确的诊断。在正确的阶段应用识别、语法和策略后备。修复已确定的原因并重新测试相同的工作流程。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

将方法、阶段和结果放在一起。

SPF 、 DKIM 、策略发现和DMARC评估可以产生不同的结果。

后续步骤

  1. 保留完全可信的结果和返回的SMTP文本。
  2. 精确应用当前的后备规则。
  3. 更正已识别的记录或依赖性并重新测试。

CISO / SecOps

需要可重复的闭合。

原因应该不会被未看到原始仪表板的人审查。

后续步骤

  1. 保留解析器和DNS证据。
  2. 记录实施假设。
  3. 将恢复的评估与更广泛的参与准备程度分开。

创始人/非技术人员

询问受影响的服务和确定的原因。

通用错误标签不会显示客户工作流程是否已恢复。

后续步骤

  1. 让发送服务所有者参与事件。
  2. 需要有代表性的恢复测试。
  3. 单独跟踪剩余的发件人缺陷。

[ 常见问题解答 ]

常见问题

dmarc=permerror是什么意思?

它表示该尝试被认为无法恢复的评估错误,例如格式不正确的策略。如果不进行相关更改,稍后重试不太可能产生最终结果。

RFC 9989 §9.2

DMARC永久错误与dmarc=fail?

否。有效失败意味着在适用的处理下未建立合格的通过对齐身份。一个永久性的错误与评估本身有关。

RFC 9989 §5.3.5 RFC 9989 §9.2

SMTP 5xx 响应是否证明dmarc=permerror?

不会SMTP拒绝可能有其他原因。在分配DMARC结果之前保留完整的返回文本和特定于方法的证据。

RFC 5321 §4.2.1

在RFC 9989下,每个格式错误的 p 值是否都不可避免地会产生permerror ?

否。当前的发现规则使用语法上有效的 rua URI 定义条件无处理,以处理丢失或无效的 p、或无效的 sp 或 np。其他畸形病例必须在各自阶段进行评估。

RFC 9989 §4.10.1

SPF permerror可以与DMARC pass 共存吗?

是的,例如,当策略发现起作用并且有效的对齐DKIM签名提供消息级传递路径时。 SPF缺陷仍然需要修复。

RFC 9989 §5.3.5 RFC 7208 §2.6.7

我是否应该添加另一条DMARC记录来覆盖无效记录?

否。协调完整的预期记录集。根据当前的树遍历规则,一个目标的多个候选政策将被丢弃而不是合并。

RFC 9989 §4.10

哪些证据使得修复可以进行审查?

保留原始响应、精确的记录集缺陷、批准的前后配置、权威和递归观察以及受控消息重新测试。

当DNS检查器变绿时,我可以关闭事件吗?

还要确认受影响的应用程序收到或返回的消息结果。仅凭有效的DNS观察并不能验证完整的邮件路由。

[ 来源 ]

来源

  1. RFC 9989

    部分 §4.7 · §4.10 · §4.10.1 · §5.3.5 · §9.2 · §3.2.6

  2. RFC 8601

    部分 §2.2 · §7.1

  3. RFC 7208

    部分 §2.6.7

  4. RFC 5321

    部分 §4.2.1

  5. RFC 8767

    部分 §4

[ 词汇表 ]

词汇表

DMARC政策记录
DNS TXT记录支持验证并表达适用域的处理首选项和可选报告请求。

RFC 9989 §3.2.6

dmarc=permerror
不可恢复的评估错误,如果不进行相关更改,以后的尝试不太可能产生最终结果。

RFC 9989 §9.2

企业出处

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

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

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

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

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

知识库