创建具有明确分母、覆盖信号、所有者和调查路径的运输安全警报，而不是对每个聚合故障进行寻呼。
定义阈值之前的决策
参考： RFC 8460 §4.1.
有用的警报标识了可观察到的情况以及可以调查该情况的人员。确定该情况是新的故障类别、持续的故障份额、缺少预期报告者还是直接端点故障。 TLS-RPT 是聚合和延迟的，因此它不能替代实时可用性监控。将警报的紧急程度与该证据相匹配。较晚的每日报告可能很重要，但不能证明服务现在正在失败。
使用兼容的范围和分母
参考： RFC 8460 §4, RFC 8460 §4.2.
将失败次数除以定义的报告者、策略和时间段内的成功次数加上失败次数来计算总结失败份额。保护零分母的情况。将绝对失败计数放在比率旁边：每一次失败的会话中有 1 次失败的概率为 100%，但与数千次失败相比具有不同的证据权重。不要将重叠的故障详细信息类别相加来创建分母。在细节允许的情况下，按策略域和相关接收端点进行细分，而不会为了成功而发明遗漏的细节。
行使说明性阈值
当总结失败次数至少为 20 次并且其比例至少为 5% 时，当地教学规则将启动调查。成功 980 次，失败 20 次，所占比例为 2%，因此不满足比率条件。成功 380 次，失败 20 次，比例为 5%，并且两个条件都满足。如果总会话数为零，结果就是没有速率，不健康。这些数字是任意实验室阈值，而不是EmailAuth默认值、SLA 或针对每个组织的建议。
添加覆盖范围并更改上下文
参考： RFC 8460 §4.3.1, RFC 8460 §4.3.2.
失败计数下降可能反映的是报告丢失，而不是改进。与运输结果分开跟踪预期报告者的存在和收集者的摄入量。在警报证据中包括观察窗口、到达延迟、受影响的政策以及最近的相关证书或路由更改。新的证书主机不匹配类别应路由至身份和端点检查； sts-policy-fetch-error 应路由到策略检索。将直接可用性探测保留为独特的证据流，并标记其时间戳和网络优势点。
使警报可操作且可逆
参考： RFC 8460 §4.1, RFC 8460 §7.
分配服务所有者、第一个诊断步骤和关闭条件。对同一事件的重复观察进行分组，并保留范围的变化，而不是为每个附件创建一页。不要自动削弱强制执行、启用旧协议或替换来自 汇总报告 内容。修复后，直接验证端点并评估后续观察期，同时确认迟到的报告。根据测量的流量和业务影响调整阈值，记录推理。新重新运行的离线装置仅证明规定的算术和决策边界；未创建实时警报、监控订阅或生产修复。
保留历史证据和当前检查
以下传输观察结果于 2026 年 11 月 7 日捕获并进行检查，而不是作为网络测试重新运行，以供本次审查。新的离线模型检查是单独记录的。
保留的历史注释教学报告有一个成功的会话和一个失败的会话，对应于实际的正向和主机名不匹配环回测试。其小样本故意不符合说明性的二十次失败阈值。该报告是手动编写的，而不是由报告发出的 MTA，并且没有启用通知服务。生产阈值校准、覆盖范围监控和路由警报接受仍需等待相关操作证据。历史传输运行程序需要具有加密和环回套接字的 Python。其结果是有限的实验室证据，而不是当前的服务健康状况或生产互操作性。
主要来源基础
字段定义和报告限制来自 RFC 8460 , SMTP TLS报告，第 3 节和第 4 节。操作建议与协议要求不同。