Create transport-security alerts with a clear denominator, coverage signal, owner and investigation path instead of paging on every aggregate failure.
Define the decision before the threshold
References: RFC 8460 §4.1.
A useful alert identifies an observable condition and a person who can investigate it. Decide whether the condition is a new failure category, a sustained failure share, a missing expected reporter or a direct endpoint failure. TLS-RPT is aggregated and delayed, so it is not a substitute for real-time availability monitoring. Match the alert’s urgency to that evidence. A late daily report may be important without proving that a service is failing right now.
Use compatible scope and denominators
References: RFC 8460 §4, RFC 8460 §4.2.
Calculate a summary failure share as failures divided by successful plus failed sessions for a defined reporter, policy and period. Guard the zero-denominator case. Keep the absolute failure count beside the ratio: one failed session out of one is 100 percent, but has different evidence weight from thousands of failures. Do not sum overlapping failure-detail categories to create the denominator. Segment by policy-domain and relevant receiving endpoint when details permit, without inventing missing detail for successes.
Exercise an illustrative threshold
The local teaching rule opens an investigation when summary failures are at least 20 and their share is at least 5 percent. With 980 successes and 20 failures, the share is 2 percent, so the ratio condition is not met. With 380 successes and 20 failures, the share is 5 percent and both conditions are met. With zero total sessions, the result is no rate, not healthy. These numbers are arbitrary lab thresholds, not EmailAuth defaults, an SLA or a recommendation for every organization.
Add coverage and change context
References: RFC 8460 §4.3.1, RFC 8460 §4.3.2.
A falling failure count can reflect lost reports rather than improvement. Track expected reporter presence and collector intake separately from transport outcomes. Include the observation window, arrival delay, affected policy and recent relevant certificate or routing changes in the alert evidence. A new certificate-host-mismatch category should route to identity and endpoint checks; sts-policy-fetch-error should route to policy retrieval. Keep direct availability probes as a distinct evidence stream and label their timestamps and network vantage points.
Make alerts actionable and reversible
References: RFC 8460 §4.1, RFC 8460 §7.
Assign a service owner, a first diagnostic step and a closure condition. Group repeated observations from the same incident and retain changes in scope instead of creating one page per attachment. Do not automatically weaken enforcement, enable legacy protocols or replace certificates from aggregate report content. After a repair, verify the endpoint directly and assess subsequent observation periods while acknowledging late reports. Tune thresholds from measured traffic and business impact, recording the reasoning. The newly rerun offline fixture proves only the stated arithmetic and decision boundaries; no live alert, monitoring subscription or production remediation was created.
Retained historical evidence and current checks
The transport observations below were captured on 7 November 2026 and inspected, not rerun as network tests, for this review. The new offline model checks are recorded separately.
The retained historical annotated teaching report has one successful and one failed session corresponding to the actual positive and hostname-mismatch loopback tests. Its small sample deliberately does not meet the illustrative twenty-failure threshold. The report is manually authored, not emitted by a reporting MTA, and no notification service was enabled. Production threshold calibration, coverage monitoring and routed alert acceptance remain held pending relevant operational evidence. The historical transport runner requires Python with cryptography and loopback sockets. Its outcomes are bounded lab evidence, not current service health or production interoperability.
Primary-source basis
The field definitions and reporting limits come from RFC 8460, SMTP TLS Reporting, sections 3 and 4. The operational recommendations are distinguished from protocol requirements.