[ DMARC和政策 ]

DMARC p=none:在执行之前可以进行哪些监控

监控有助于识别观察到的发件人、身份验证漏洞和策略影响。它并不能证明完全覆盖或使固定的等待期足以被拒绝。

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

[ 要点 ]

  • 监控窗口涵盖观察到的流量,而不是每个潜在的发送者。
  • 保留未知的归属,直到证据解决为止。
  • 选择使用关键路由、间接邮件和恢复准备的策略。
在此页面上

在下面 RFC 9989 §4.7, a DMARC 的政策 p=none 表示域所有者对DMARC故障没有处理偏好。配置和审查报告时,它创造了一个机会来了解哪些服务使用该域、合法消息在哪里失败以及策略更改可能会影响什么。

通过调查,监控变得有用。报告需要到达收集系统,来源需要所有者,未解决的故障需要决策。经过的时间或一个高通过率并不能确定每一项重要服务都已涵盖。

使报告集合可观察

对于开始受监控部署的域,示例性策略是:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

该示例假设预期 _dmarc 出版物和有效的同域收藏地址。如果该域已经有更强大的批准策略,请不要仅仅为了匹配示例而削弱它。使用 记录工作流程 来验证实际配置。

下列的 RFC 9990 §4 获得外部许可和 RFC 9989 §5.3.8 对于收件人报告,请检查报告目标、任何所需的外部目标权限、邮件传送和解析。保留报告者身份、期间和相关配置历史记录。收到来自一个提供商的报告表明了该观察的工作路径;它并不能证明全民覆盖。

对服务进行分类并保留不确定性

对于每个有意义的源模式,调查应用程序、客户特定帐户或路由、可见域、信封身份、签名身份和所有者。

使用明确的工作类别:

  • 类别:已批准的服务,具有预期的一致路径;下一步行动:保留所有权并监控变更
  • 类别:已批准的服务未通过身份验证或 结盟;下一步操作:更正并测试支持的配置
  • 类别:合法间接路线;下一步行动:分析转发、修改和接收者处理
  • 类别:来源不明;下一步行动:保留不确定性并进行调查
  • 类别:已确认未经授权的使用;下一步行动:记录支持证据和回应

云提供商名称、 ASN或国家/地区不足以批准发件人。同样,失败的行不足以声明每个关联的消息都是恶意的。

工作示例:安静的窗口错过了工资单

考虑一个示例性组织,该组织审查十天的员工和营销邮件。报告看起来很健康。在此期间,月薪服务尚未发送,其签名配置尚未经过测试。

正确的结论是,观察到的流在这十天内看起来很健康。这并不是说整个领域已经准备好接受更严格的政策。

该团队可以直接调查和测试薪资路线,识别任何其他定期服务并扩展其证据。观察窗口应反映实际的商业周期和相关的互操作性考虑因素,而不是从仪表板中选择的通用数字。

选择适合域的策略

该决定比通过率目标更广泛。需要关键服务覆盖、负责任的所有者、评估的间接邮件群体、解决高影响力的故障和恢复过程。

RFC 9989 §7.4 明确警告不要 p=reject 用于通用电子邮件并讨论用户参与 Internet 邮件列表的域。其互操作性指南包括针对这些领域的具体观察和比较步骤。不要用每个受监控域最终都应被拒绝的通用承诺来取代该指南。

严格控制的事务发送域和用于一般员工通信的域可以具有不同的操作约束。单独的身份流服务于真正的治理目的,同时验证生成的配置和实际消息。

定义下一个决策的证据

执行审查应该用证据回答这些问题:

  • 重要的合法服务是否已被识别、拥有并经过测试?
  • 每个受影响的服务是否都有受支持的对齐路径?
  • 是否考虑了周期性和小流量?
  • 邮件列表、转发和其他间接路由是否被理解?
  • 是否描述了报告覆盖范围,而没有将其视为所有已发送的电子邮件?
  • 例外情况是否已确定范围、拥有并计划进行审查?
  • 团队能否批准、验证提议的变更并从中恢复?

该决定可能是改进发件人、改变域分离、继续监控或应用适合域记录使用的策略。将推理与变更记录一起保存。

为调查结果分配所有者

询问团队希望了解什么以及谁将根据研究结果采取行动。为企业提供哪些服务?哪些关键消息失败?哪些明显的发件人仍未识别?什么证据将决定下一步?

包括 IT 团队直接视图之外的工作。每月工资单通知或年度续订通知可能很重要,但对总体消息总数的贡献却很小。

避免自动倒计时采取更强有力的政策。一周几乎没有明显的故障可能意味着发送正常、报告不完整或服务尚未发送。为维护的库存和已结束的调查结果付费,而不仅仅是为过去的天数付费。

政策变更后继续监控

新软件、供应商变更、密钥轮换和DNS编辑可能会造成新的差距。在任何政策更改后继续调查新的发件人和合法失败。

向企业领导者解释剩余风险:接收者保留自己的处理选择 RFC 9989 §5.4,并且域身份验证并不能阻止所有相似的消息、帐户泄露或欺诈请求。对于证据解释,请使用 汇总报告演练。对于原始通道失败,请使用 对齐指南.

实用的外卖

监控的输出应该是拥有的发送者清单、经过验证的关键路线和合理的政策决策。随着环境的变化不断监控,以便以后的应用程序、密钥或网关更改不会悄悄地重新打开相同的差距。

记录决定及其限制

对于虚构的十天窗口,将每月工资单保留为未经测试,而不是将其标记为健康。添加其所有者、下一个代表性工作流程以及缩小差距所需的证据。如果收集工作正常但应用程序从未发送,则对相同报告的更多分析无法建立其身份验证。没有为此插图收集任何报告或工资测试。

[ 外卖 ]

监控窗口涵盖观察到的流量,而不是每个潜在的发送者。保留未知的归属,直到证据解决为止。选择使用关键路由、间接邮件和恢复准备的策略。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

使收集和分类过程可见。

验证目标和摄取路径,保留报告上下文并根据消息和服务配置调查源模式。明确未知的归属。

后续步骤

  1. 在需要时检查外部目标权限。
  2. 直接测试定期服务而不是盲目等待。
  3. 保留支持每个发件人分类的证据。

CISO / SecOps

选择域记录使用的策略。

一般通信域和严格控制的事务身份可以具有不同的约束。在批准政策之前,请审查当前的互操作性指南和关键流程证据。

后续步骤

  1. 评估邮件列表、转发和例外情况。
  2. 需要所有权、恢复条件和审查日期。
  3. 任何政策决定后继续监测。

创始人/非技术人员

将监控变成有名的工作。

观察应确定您的企业使用的服务以及需要注意的重要消息。询问团队将学到什么、谁将采取行动以及什么证据将支持下一个决定。

后续步骤

  1. 在库存中包括每月和季节性服务。
  2. 优先考虑严重故障而不是看上去健康的故障总数。
  3. 询问已结束的调查结果,而不仅仅是过去的监测天数。

[ 常见问题解答 ]

常见问题

p=none是否会禁用SPF或DKIM检查?

不会。这些机制和DMARC评估仍然可以运行。该策略没有表示域所有者对DMARC失败的处理偏好;它不是跳过身份验证的指令。

RFC 9989 §4.7

当域使用p=none?

是的。接收者可以应用自己的过滤、信誉、收件人和其他策略。 None 不是保证交付设置。

RFC 9989 §5.4

监控策略是否会自动生成有用的报告?

不可以。报告请求、目的地许可(如果适用)、交付、解析和操作审查必须有效。接收者在报告参与方面也存在差异。

RFC 9989 §5.3.8 RFC 9990 §4

通过率高就足以离开监控吗?

否。检查基础人口、重要服务、未解决的所有权和间接路线。高容量的健康流可以隐藏失败的关键流。

观察期应该持续多长时间?

将其与域的发送周期、相关标准指南和证据需求相匹配。请勿单独使用经过时间作为承保范围或安全性的证明。

每个域最终都应该发布拒绝吗?

没有普遍的进展是合适的。 RFC 9989对通用域和邮件列表互操作性发出警告。根据域使用、合法流量和适用指南选择策略。

RFC 9989 §7.4

一旦实施更强有力的政策,监控是否应该停止?

不会。新服务、更改的路线和过时的权限可能会在以后带来问题。维护收集、所有权和根据调查结果采取行动的流程。

监测的有用结果是什么?

拥有的发件人库​​存、经过验证的合法路线、解决了重大差距、了解了限制并记录了政策决策,以及更改和恢复流程。

[ 来源 ]

来源

  1. RFC 9989

    部分 §4.7 · §5.3.8 · §5.4 · §7.4

  2. RFC 9990

    部分 §3.1 · §4

[ 词汇表 ]

词汇表

报告范围
报告所代表的接收者和观察期;汇总报告并不是对已发送邮件的完整普查。

RFC 9989 §5.3.8 RFC 9990 §3.1

来源不明
尚未归因于已批准的服务或已确认的滥用的观察结果;不确定性仍待调查。

企业出处

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

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

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

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

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

知识库