Prolateral Consulting Ltd
Prolateral Consulting Ltd
Knowledgebase Articles
Setup examples

Prolateral offers primary and backup domain (DNS) services, with servers in key geographic locations providing the best service possible.


How do I setup TLS-RPT?


In this knowledge article it is assumed you already have the following working:

  • A email server solution
  • Already receiving inbound emails for your domain/s.
  • Enabled TLS/SSL for SMTP on the email server.

TLS-RPT is Transport Layer Security RePorTing, and is a protocol designed to improve the security of email communication by providing feedback to domain owners about issues encountered during the establishment of TLS-encrypted connections between email servers.

TLS-RPT in a few steps

Create a mailbox

In order to receive the TLS-RPT reports you will need a dedicated mailbox or access to a TLS-RPT analysing service.

If you choose to use a mailbox on your domain, then we suggested a dedicated mailbox as the email address needs to be published in the DNS TXT record.


Add a DNS TXT to your domain

You will need to create a DNS TXT record called


Review TLS reports

Analyse and review the received TLS reports.

Setting up TLS-RPT

Let's look in more detail in the setting up of TLS-RPT

Step 1 - Create a mailbox

It is recommend you create a dedicated mailbox to receive the reports as this is a published email address in DNS.

Create a mailbox with the email address

Ensure that mailbox can receive emails from other Internet domains.

Step 2 - Adding a TXT DNS record

You will need access to your DNS zone records in order to create a new TXT record called an example of the record is below.

_smtp._tls TXT "v=TLSRPTv1;"

The record is a TXT DNS record and the breakdown is as follows:

Field & ValueDescription
v=TLSRPTv1 TLSRPT version 1

Aggregate Report URI (rua), A comma-separated list of locations where the report is to be submitted.

TLSRPT supports reports to go via email (mailto:) or https submission

What would trigger a TLSRPT report?

To establish a secure SMTP connection there are several protocols that can be used. For example, DANE TLSA, STARTTLS, and MTA-STS. Any one of these protocols could cause a message to be undelivered or the message to be delivered by an unsecured method. When this happens the sending server will generate a TLS report and submit it to the published "rua" value in the DNS TXT record.

Below is a list of possible failures that could cause a TLE report to be generated.

TLS negotiation failures
starttls-not-supported  The receiving MTA does not support the STARTTLS command. Check your receiving server has a valid certificate installed and the Mail Transport Agent (MTA) is configured for TLS / SSL.
certificate-host-mismatch The receiving MTA’s certificate does not match the hostname. Check your receiving server has a valid certificate that includes the mail server hostname.  Wildcard SSL certificates are also acceptable.
certificate-not-trusted The sender does not trust the certificate. Check your receiving mail servers SSL certificate.
certificate-expired The receiving MTA’s certificate is expired.  Check your receiving mail servers SSL certificate and if necessary renew / update the SSL certificate.
validation-failure This is a catch-all error, i.e. if it's not one of the above errors then it will report as a general validation failure.
MTA-STS failures
sts-policy-fetch-error The sender could not fetch the MTA-STS policy over HTTPS. The web server that is hosting the .well-known/mta-sts.txt file must support HTTPS communications.
sts-policy-invalid The published mta-sts.txt file contains a syntax error. Please refer to the knowledgae base article on MTA-STS.
sts-webpki-invalid This indicates that the MTA-STS Policy could not be authenticated using PKIX validation.
DNS failures
tlsa-invalid This indicates a validation error in the TLSA record associated with a DANE policy.
dnssec-invalid This indicates that no valid records were returned from the recursive resolver.
dane-required This indicates that the sending system is configured to require DANE TLSA records for all the MX hosts of the destination domain, but no DNSSEC-validated TLSA records were present for the MX host that is the subject of the report.

Additional reading

More information on TLSRPT can be found in the RFC8460.


like it, love it, then share it. Share this article on social media.

Did you enjoy this article?


The Origin of this information may be internal or external to Prolateral Consulting Ltd. Prolateral makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Prolateral makes no explicit or implied claims to the validity of this information. Any trademarks referenced in this document are the property of their respective owners.