[ 报告与调查 ]

为什么有些接收者没有发送您期望的报告

将接收器覆盖范围差距与损坏的报告请求分开。

由EmailAuth研究团队提供

[ 要点 ]

  • 没有报告是证据差距,而不是测量的零。
  • 在指责参与之前验证请求、交付和解析。
  • 保持明确的预期报告者证据和关键路线限制。
在此页面上

发布的 rua 请求不会对每个目的地进行完整的人口普查。接收者可能不参与报告,可能没有相关观察,或者可能遇到生成或传递问题。将缺席记者视为调查问题,而不是零邮件或零滥用的证据。

定义预期的接收者群体

首先在审核的时间间隔内发送日志和经过验证的目的地。根据已知的实际接收基础设施对它们进行分组;收件人域和报告生成者身份不需要具有一对一的关系。外包邮件托管和网关可能会使基于品牌的记者名单产生误导。

记录支持每个期望的内容:早期报告、当前第一方文档、受控交付或发件人日志。将假设分开。不要根据另一个提供商的行为发明一个提供商的报告时间表或能力。

排除请求和收集缺陷

参考: RFC 9990 §4, RFC 9990 §3.5.

验证适用的策略和 rua 目的地,然后需要外部授权。检查接收邮箱日志、隔离和解析器故障。如果报告到达收集器但未显示,则接收器确实报告了;差距属于收集过程。

发送到同意的测试邮箱的新受控消息可以确定特定路径接收了邮件。其可信身份验证结果有助于诊断消息,但不能证明消息确实存在 汇总报告 将在保证时间生成或到达。

诚实地对不确定性进行分类

参考: RFC 9990 §3.1, RFC 9989 §5.3.8.

使用不同的状态,例如先前报告但迟到、请求无效、交付被拒绝、解析器失败和参与未确认。这可以防止不同的团队将每个丢失的条目视为相同的中断。 RFC 9990 描述了每日或更频繁的反馈,但实际覆盖范围仍取决于实际参与系统和成功收集。

说明性案例:报告从收件人 A 和 B 到达,而发件人日志也显示 C 处已接受的邮件。不存在来自 C 的报告。如果没有进一步的证据,将 C 分类为汇总报告中未观察到的。不要将零故障率分配给 C 或从 A 的报告中推断其政策实施情况。

根据现有证据做出决定

优先考虑关键流程缺失的覆盖范围、最近的基础设施变化以及之前可靠贡献的接收者。使用发件人日志、授权消息样本和传送诊断来补充报告。不要仅仅为了让未经证实的记者出现而多次更改有效记录。

发布观察到的发现和覆盖范围限制。如果缺席的接收者对执行决定产生重大影响,请获取该路线的更好证据或记录剩余的不确定性和决策所有者。结果应该是一个有说服力的证据图,而不是承诺每个邮箱提供商都有代表。

维护预期报告者登记册

对于每个重要的接收者,记录预期参与的原因、观察到的最后间隔、历史到达行为和当前证据质量。将经过验证的提供程序更改与基于丢失文件的本地猜测分开。在发件人迁移或收件人托管更改后查看注册表,因为相关报告基础架构可能会在客户电子邮件地址不发生变化的情况下发生变化。无法证实的期望应该被标记为“未证实”。这为下一位分析师提供了一个具体的起点,而不是反复出现的无法解释的警报。

继续调查

使用 汇总报告演练 解释底层字段和 对准诊断指南 当原始身份验证通行证不满足时 DMARC.

执行综合证据

以下是本地重新运行的离线合成装置,而不是实时DNS 、 SMTP或客户观察。它的 XML 输入是用 Python 的标准库解析的,断言检查结果字段和计算。模拟的DNS和邮件阶段提供测试输入,而不是真实接收者执行这些操作的证据。完整的模式验证和生产源身份验证不在这个小装置之外;现场证据仍有待确定。

提供的请求是 _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example"。这些保留的示例域被假定为夹具中单独的组织域。两个综合授权答案是 brand.example._report._dmarc.collector.example TXT "v=DMARC1" 和 brand.example._report._dmarc.archive.example TXT "v=DMARC1"。本地模型与提供的授权所有者名称及其版本值相匹配 RFC 9990 §4。它不执行DNS查询或完整的授权算法。生产实现必须执行完整的发现和授权过程,而不是假设这些域边界。

保留的报告具有 ID R1、策略域brand.example 、date_range 开始 1772409600 和结束 1772496000、源 IP 192.0.2.10和计数 100。其评估一致 DKIM 结果通过并对齐 SPF 是失败。原始SPF结果通过了vendor.example ,说明了为什么原始成功与对齐成功不同。这些字段是从 XML 解析的,而不是从仪表板推断的。

正控制receiver.example有一个模拟的已接受收据,解析计数为 100。第二个合成接收者unobserved.example有 20 个提供的发件人提交,但没有收据,也没有解析计数。该断言将计数保留为空而不是零。完成的请求解析器正控制表明模型的收集器可以处理一份报告;它并不能证明失踪的接收者参与或尝试交付。在更改该分类之前,实时调查必须获取自己的邮箱和提供商证据。

使结果保持在测试范围内

提供的本地演示仅验证其小型合成解析器、提供的阶段输入和计算。没有测试真正的DNS授权、 SMTP传送、收集器迁移、提供商参与或生产数据库行为。原始输入仍被存档,任何实时比较都需要其自己受保护的证据和负责任的批准。

[ 外卖 ]

没有报告是证据差距,而不是测量的零。在指责参与之前验证请求、交付和解析。保持明确的预期报告者证据和关键路线限制。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

验证实际请求和收集器。

保留基础观察结果并使用上述工作流程将实际故障阶段与假设分开。

后续步骤

  1. 验证实际请求和收集器。
  2. 按观察阶段对差距进行分类。
  3. 与受控消息证据相关联。

CISO / SecOps

避免从沉默中提出零风险主张。

在根据这些调查结果做出安全决策之前,请保持覆盖范围、来源和剩余不确定性可见。

后续步骤

  1. 避免从沉默中提出零风险主张。
  2. 审查关键收件人的覆盖范围。
  3. 保留一张注明日期的证据图。

创始人/非技术人员

识别重要的未观察路线。

将此报告任务与自己的业务决策联系起来,并需要与其影响相称的证据。

后续步骤

  1. 识别重要的未观察路线。
  2. 询问承保索赔背后的证据。
  3. 根据剩余的不确定性分配决策。

[ 常见问题解答 ]

常见问题

rua 是否要求每个接收者都发送报告?

发布请求后不提供通用交付保证。

RFC 9989 §5.3.8 RFC 9990 §3.5

没有报告是否意味着没有邮件到达?

不。检查独立邮件流证据。

托管域可以使用其他身份进行报告吗?

生成报告的基础设施可能与接收者品牌不同;验证关系。

测试消息可以强制上报吗?

不。它为经过测试的路径提供消息级证据。

RFC 9989 §5.3.8

如果报告被隔离怎么办?

那是收集失败,而不是接收者没有报告的证据。

丢失的接收器是否应该实现零故障?

不可以。未知的观测值不得编码为测量值为零。

应如何记录预期参与?

使用注明日期的主要文件、历史报告或实际控制观察结果。

差距何时会影响决策?

当未观察到的关键路线可能会改变风险评估或拟议的政策行动时。

[ 来源 ]

来源

  1. RFC 9989

    部分 §5.3.8

  2. RFC 9990

    部分 §3.1 · §3.5 · §4

[ 词汇表 ]

词汇表

未被观察到的接收器
接收方未按规定范围收集报告的;这种运行状态并不意味着零流量或故障。
举报参与
接管人报告须遵守报告规范和实际参与限制;已发布的请求并非普遍覆盖。

RFC 9989 §5.3.8

企业出处

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

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

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

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

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

知识库