Introduction to TLSRPT

SMTP TLS Reporting (TLSRPT or, improperly, TLS-RPT) is a reporting mechanism by which sending email servers can share statistics and details about SMTP connection failures to recipient domains owners.

In particular, TLSRPT is focused on secure email delivery and helps identify attacks or misconfigurations that prevent an encrypted SMTP connection from being established during the delivery of email messages.

As a domain owner, you can set up TLSRPT and receive reports with statistics about inbound email delivery.

TLSRPT works together with MTA-STS or DANE, meaning that at least one of the two mechanisms usually needs to be set up in order to receive meaningful TLS reports for a domain.

TLS Reporting is defined by RFC8460, which was published in September 2018 as a Proposed Standard together with MTA-STS.

What TLSRPT covers

TLSRPT works best when paired with MTA-STS or DANE, two mechanisms that let domain owners enforce secure SMTP connections in inbound email delivery.

In this case, TLSRPT helps identify issues with the MTA-STS or DANE configuration (e.g. the MTA-STS policy couldn’t be fetched) and other validation failures that may prevent the delivery of the emails.

In addition to this, a mail server can also report other general failures that may occur during the TLS session negotiation.

On the other hand, the RFC specifically mentions that transient errors due to other conditions, like «too-busy networks, TCP timeouts, etc.» are not required to be reported.

Enabling TLSRPT

To enable TLS reporting on a domain, domain owners must publish a TXT DNS record on the _smtp._tls subdomain.

The value of the record should be in the following format:

v=TLSRPTv1; rua=mailto:tlsrpt@example.com;

The rua tag contains the location where the reports should be delivered and can be either:

• An email address (mailto:).
• An HTTPS URL to which POST requests will be sent (https).

Here’s an example of what this record could look like:

Reports contents

TLS reports are formatted in the JSON format and contain useful statistics to assess the correct configuration of the email servers.

Reports contain information such as:

• The date range to which the report refers.
• The policies that have been found, i.e. MTA-STS or DANE.
• The number of successful and failed TLS sessions.
• Failure details, which may be a policy failure (e.g. invalid MTA-STS policy), a negotiation failure (e.g. expired certificate) or other general TLS failures.

The most useful part of TLS reports is usually the failures section. Read more about the specific failure types and their meanings in the RFC.