SMTP TLS Reporting

TLS-RPT Make transport failures visible

TLS-RPT lets sending mail servers report when an encrypted delivery fails. This view creates the early warning system without which MTA-STS and DANE would be operated blindly.

_smtp._tls TXT record
_smtp._tls.example.de. IN TXT "v=TLSRPTv1; rua=mailto:tls-rpt@conbool.com"

Without TLS-RPT, a failed transport encryption stays invisible. Only the reports make problems measurable before messages are lost.

MTA-STS and DANE can block deliveries when something is wrong. TLS-RPT answers the decisive question before and after: where exactly does the encryption fail, and which sender is reporting a problem? It is precisely this visibility that keeps an overly strict policy from silently holding back legitimate mail.

What TLS-RPT is

TLS-RPT stands for SMTP TLS Reporting and is standardized in RFC 8460. A TXT record under _smtp._tls of the domain names an address to which sending servers deliver aggregated reports. These reports show how many connections were established with encryption and which ones failed due to a certificate or TLS problem.

Why reports are indispensable

Transport security without feedback is a risk. TLS-RPT closes this gap.

Safe rollout

In the testing mode of MTA-STS, the reports show whether all senders encrypt cleanly before the policy is set to enforce.

Early warning

An expired certificate or a broken TLS configuration stands out immediately, instead of only through missing messages.

Evidence

Over time, the reports demonstrate that email transport is actually encrypted, and they support audits.

Evaluate reports with Conbool

Raw reports in JSON format are unwieldy. Conbool MailGuard turns them into actionable insights.

Receipt and storage

The reports from the large senders are received centrally and retained.

Preparation

Success and failure rates are presented clearly by sender and time period.

Failure causes

Failed connections are categorized by cause, such as certificate errors or missing TLS support.

Interplay with MTA-STS

The evaluation feeds directly into the decision on whether a policy is tightened or observed for now.

Frequently asked questions about TLS-RPT

What does TLS-RPT mean?
TLS-RPT stands for SMTP TLS Reporting under RFC 8460. It defines how sending mail servers report back to the recipient domain on the success or failure of encrypted deliveries.
How is TLS-RPT set up?
A single TXT record under _smtp._tls of the domain is enough, naming an address for the reports. The correct notation with a dot between _smtp and _tls is important. Conbool sets up the record and the receipt of the reports.
Does TLS-RPT block emails?
No. TLS-RPT is purely reporting and does not intervene in delivery. Enforcement is handled by MTA-STS and DANE. TLS-RPT provides the visibility that makes their safe operation possible in the first place.
Who sends the reports?
Large senders such as Google and Microsoft evaluate the recipient domain and usually send one aggregated report per day. The reports contain no message content, only statistics on transport.
Is TLS-RPT worthwhile without MTA-STS or DANE?
Yes, as a diagnostic. On its own, TLS-RPT already shows whether the incoming transport is reliably encrypted. Its full value, however, comes as a companion to an MTA-STS or DANE rollout.
How can the TLS-RPT record be checked?
The free Mail Check from Conbool verifies whether a valid _smtp._tls record is present, and returns the result as a report.

No longer flying blind on transport failures

The free Mail Check shows whether TLS-RPT and the transport encryption of your own domain are set up correctly.