TLS-RPT for email

What is TLS-RPT?

TLS-RPT stands for SMTP TLS Reporting. It is defined in RFC 8460 and allows domain owners to publish a DNS record that tells supporting sending mail servers where to send reports about TLS failures they encounter when delivering mail to that domain.

When a supporting sender fails to establish a valid TLS connection to your mail servers — for example, because of a certificate error, a STARTTLS failure, or an MTA-STS policy violation — it can record that failure and include it in a periodic aggregate report sent to the address you publish.

TLS-RPT does not enforce TLS and does not block or redirect mail. It is a monitoring and reporting mechanism. It gives you the data to find and fix TLS configuration problems before they cause wider delivery issues.

Why TLS-RPT matters

Without TLS-RPT, TLS delivery failures are largely silent. A supporting sender that encounters a certificate error on your MX server may retry or fall back quietly — you have no visibility into how often this happens, which senders are affected, or which of your servers is misconfigured.

TLS-RPT closes this visibility gap. Reports from supporting senders such as Gmail and Microsoft aggregate the TLS failures they encounter for your domain. This lets you identify expired certificates, hostname mismatches, MTA-STS policy violations, and STARTTLS failures on specific MX hosts.

TLS-RPT is particularly valuable when you have published an MTA-STS policy. In testing mode, failures are reported rather than blocking delivery — TLS-RPT is how you receive those reports. Even in enforce mode, ongoing TLS-RPT monitoring alerts you to certificate expiry or infrastructure changes before they cause delivery failures.

TLS-RPT does not directly improve inbox placement or sender reputation. It is a visibility tool for inbound transport security.

How TLS-RPT works

A supporting sender that encounters TLS failures while delivering to your domain records those failures in an internal log. At the end of a reporting period — typically once per day — it generates an aggregate JSON report for each domain it delivered to and sends that report to the address published in the domain's TLS-RPT record.

The report covers the sending organisation's delivery attempts to your domain during that period. It includes policy details, the number of successful and failed TLS sessions, and structured failure information for each type of error encountered.

Reports are JSON-formatted and often delivered as gzip-compressed attachments via email to the mailto: address in your TLS-RPT record. Not every sending server supports TLS-RPT, so the absence of reports does not confirm zero failures — it confirms that no supporting sender encountered failures and chose to report them.

The TLS-RPT DNS TXT record

The TLS-RPT record is a DNS TXT record published at the subdomain _smtp._tls.yourdomain.com. A valid record looks like:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

The v field must be TLSRPTv1. The rua field specifies one or more report destination URIs. Multiple destinations can be separated by commas.

The subdomain is _smtp._tls — not _smtp-tls or _tls. The exact hostname matters: senders look up _smtp._tls.yourdomain.com when checking for a TLS-RPT record. A record published at a different name will not be found.

Report destinations and rua syntax

The rua field in a TLS-RPT record specifies where reports are sent. The mailto: scheme is the most widely supported format:

rua=mailto:tls-reports@yourdomain.com

The HTTPS scheme is also defined in the specification for delivering reports to an endpoint, but mailto: has broader support among sending servers in practice.

You can publish multiple destinations by separating them with commas:

rua=mailto:tls-reports@yourdomain.com,mailto:security@yourdomain.com

The mailbox in the mailto: address must be reachable and actively monitored. Reports are typically sent as email messages with a gzip-compressed JSON attachment. If the destination mailbox bounces or is unmonitored, you lose visibility into TLS failures silently.

What TLS-RPT reports contain

Each TLS-RPT report is a JSON document that covers a single reporting period — typically one day. The report structure includes:

Organisation name and contact information for the sending server. The date range covered. The policy applied — either MTA-STS or DANE, if any. Summary statistics: total successful TLS sessions and total failure sessions. A list of failure details, including the failure type, the number of affected sessions, and the sending and receiving MX hostnames involved.

Failure types include certificate expired, certificate hostname mismatch, certificate not trusted, STARTTLS not supported, STARTTLS connection failure, MTA-STS policy fetch failure, and MTA-STS validation failure among others.

Reports are valuable for spotting systemic issues — for example, a single MX host consistently generating certificate hostname errors, or an MTA-STS policy file that is unreachable for a period after a server change.

TLS-RPT and MTA-STS

TLS-RPT and MTA-STS are complementary standards designed to work together.

MTA-STS is a policy mechanism: it tells supporting senders to require valid TLS when delivering to your domain. In testing mode, MTA-STS does not block delivery but expects failures to be reported. In enforce mode, delivery fails if TLS cannot be established.

TLS-RPT is the reporting mechanism: it tells senders where to send the failure reports that MTA-STS testing mode generates. Without TLS-RPT, an MTA-STS testing mode deployment produces no actionable data.

The recommended deployment sequence is: publish TLS-RPT first, then publish MTA-STS in testing mode, monitor reports, resolve any TLS configuration issues, then switch MTA-STS to enforce mode. Continue monitoring TLS-RPT reports in enforce mode to catch certificate expiry or infrastructure changes early.

Common TLS-RPT mistakes

Wrong DNS hostname. The record must be at _smtp._tls.yourdomain.com. A common mistake is to publish it at _tls.yourdomain.com or _smtp-tls.yourdomain.com — senders will not find it.

Malformed rua value. The rua field must be a valid URI. A missing mailto: prefix, a space in the address, or an incorrect comma separator can make the record unparseable.

Unmonitored mailbox. Reports are sent to the mailto: address in the rua field. If that mailbox is not actively checked, TLS failures accumulate without action.

Bouncing destination mailbox. If the mailbox at the rua address bounces, sending servers may stop attempting delivery. The domain loses visibility without any error in the DNS record.

Publishing TLS-RPT without MTA-STS. TLS-RPT works for any TLS failure, not only MTA-STS violations, but its value is greatest when combined with an MTA-STS policy. Without MTA-STS, the volume of failures reported may be low because opportunistic TLS degrades silently rather than logging errors.

How to fix TLS-RPT problems

Verify the DNS record hostname. Confirm the TXT record is published at exactly _smtp._tls.yourdomain.com and not at a similar but incorrect subdomain.

Validate the record syntax. The record must start with v=TLSRPTv1 and include a rua= field with a valid mailto: or HTTPS URI.

Confirm the destination mailbox is reachable. Test that the mailbox in your rua address accepts mail without bouncing. Set up monitoring or alerts for any reports received.

Check MTA-STS if no reports arrive. If you have published TLS-RPT but receive no reports, verify that your MTA-STS policy is also correctly published. Major senders are more likely to generate TLS-RPT reports when an MTA-STS policy is in place.

Use a TLS-RPT checker to validate the record. A checker confirms the DNS hostname, parses the v= and rua= fields, and flags any syntax errors without requiring you to wait for reports.

How MXFend can help

TLS-RPT Checker — looks up your _smtp._tls DNS TXT record, validates the v= and rua= fields, and flags any syntax errors or missing components. The most direct tool for confirming your TLS-RPT record is correctly published.

MTA-STS Checker — verifies your MTA-STS DNS record and policy file. TLS-RPT and MTA-STS are designed to work together; checking both gives a complete picture of your inbound transport security setup.

SMTP TLS Checker — connects to your MX servers and inspects STARTTLS support and TLS certificate details. Use this to identify the certificate and hostname issues that TLS-RPT reports will flag.

Email Security Score — combines TLS-RPT, MTA-STS, SMTP TLS, blacklist, SPF, DKIM, and DMARC into a single weighted audit.