TLS-RPT

The reporting channel that tells you when encrypted delivery to your domain is failing.

TLS-RPT (SMTP TLS Reporting, RFC 8460) lets a domain ask sending servers to report the TLS problems they encounter when delivering mail to it. Participating senders mail a daily JSON summary of how many sessions were secured successfully and how many could not be.

Why it matters

Transport security without reporting fails silently. If your certificate expires or a network path is stripping STARTTLS, an MTA-STS policy in enforce mode means compliant senders will stop delivering, and without TLS-RPT the first symptom is missing mail rather than an alert. The reports also make active interference visible: a downgrade attempt shows up as a cluster of starttls-not-supported failures coming from one network path, which is exactly the pattern the standard was designed to surface.

In practice

One DNS record turns it on:

_smtp._tls.example.com  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Each day, senders that support the standard (Google and Microsoft both do) send a JSON report covering that day's sessions to your domain: a count of successful sessions, a count of failures, and a reason for each failure class such as certificate-expired, validation-failure, starttls-not-supported, or an MTA-STS policy mismatch. You publish one record; the world's largest mail senders do the instrumenting for you. The usual deployment order is TLS-RPT first, then MTA-STS in testing mode, then enforce once the reports run clean.

How Email Fast handles it

Email Fast ingests TLS-RPT reports for your domains automatically and surfaces the failure counts and reasons in the dashboard, so a broken certificate or a policy typo is a graph you notice, not mail you lose. It sits alongside the automatic DMARC aggregate-report ingestion as part of the same reporting pipeline.