[ 运输安全 ]

没有收到TLS报告：检查支持、流量和收集

当TLS报告不存在时，将丢失的发件人观察与发现、传送、完整性、解析和仪表板故障分开。

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

[ 要点 ]

  • 沉默并不能区分不受支持的发送方和损坏的收集方。
  • 跟踪发现、入口、验证、解析和显示分开进行。
  • 在更改DNS之前使用报告内部时间范围和证据。
在此页面上
  1. 要点
  2. 外卖
  3. 按角色
  4. 常见问题
  5. 来源
  6. 词汇表
  7. 相关指南

[ 外卖 ]

使用流量、参与和收集证据来查找缺失的阶段，而不是将空图表视为传输失败的证据。

[ 按角色 ]

这对您意味着什么

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

IT/邮件管理员

找到缺失的阶段

报告可以到达但永远不会出现在仪表板中。

后续步骤

  1. 检查公共发现和实际接收流量。
  2. 通过邮箱或 HTTP 入口跟踪报告 ID。
  3. 保留解析器和过滤器结果。

CISO / SecOps

保持完整性检查完好无损

数据缺失并不能成为接受未经验证或不安全报告的理由。

后续步骤

  1. 保留SMTP报告所需的DKIM验证。
  2. 将有效负载视为不受信任的输入。
  3. 记录覆盖范围差距，但没有宣布普遍成功。

创始人/非技术人员

设定合理的报告期望

低流量和选择性参与可以产生合法的安静期。

后续步骤

  1. 确定预期的发件人和业务流量。
  2. 为每个收集阶段分配所有权。
  3. 需要基于证据的结案决定。

[ 常见问题解答 ]

常见问题

没有TLS-RPT数据证明MTA-STS已禁用吗？

不会。报告和执行是分开的。发送方参与、流量和收集方行为可以独立于传输策略来解释沉默。

RFC 8460

新记录应多快生成报告？

没有普遍的截止日期。报告应涵盖 UTC 日并有延迟；生成取决于参与和观察到的流量。

RFC 8460

刷新我的本地DNS缓存对外部记者有帮助吗？

它不会清除其他系统的缓存。将权威出版物和相关递归观察结果与时间戳进行比较。

RFC 2308

邮箱是否可以包含收集器正确忽略的报告？

是的。必须忽略缺少有效所需DKIM签名的SMTP报告；其他记录的完整性条件也会影响验收。

RFC 8460

一封测试电子邮件是否证明收集器有效？

普通电子邮件并不能证明报告MIME 、压缩、签名验证和解析是端到端工作的。标记每个建议测试的范围。

RFC 8460

我是否应该在每个配置的 URI 上收到报告？

不可以。一名记者只能投递至一个受支持的目的地。在宣布所有报告损坏之前，请检查其他批准的端点。

RFC 8460

文件名和报告不一致时由哪个时间范围控制？

当文件名或主题元数据不一致时，报告本身具有权威性。检查其内部间隔和仪表板时区过滤器。

RFC 8460

如果发布两个有效的TLS-RPT策略记录会发生什么？

丢弃不以文字前缀“ v=TLSRPTv1; ”开头的TXT资源记录后，发送者必须准确找到一条剩余记录。如果发现零个或多个 1， RFC 8460要求其假定TLS-RPT未实现。记录边界很重要：一个TXT记录中的多个字符串本身并不意味着多个策略记录。

RFC 8460第 3 节

[ 来源 ]

来源

  1. RFC 2308

    部分 §5。缓存否定答案

  2. RFC 8460

    部分 §3。报告政策 · §4.1 报告时间范围 · §4.3 结果类型 · §5.2 压缩 · §5.3 电子邮件传输 · §5.4 HTTPS 传输 · §5.5 传送重试 · §5.6 元数据差异 · §7.安全考虑

[ 词汇表 ]

词汇表

参与
发送系统是否为相关流量生成TLS-RPT观察结果。

RFC 8460

入口
邮箱或 HTTP 收集器接收报告的阶段。
归因
将解析的观察结果与正确的策略域和帐户关联的过程。
覆盖差距
缺少可用报告证据的时间间隔或发送者群体。

企业出处

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

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

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

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

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

知识库