Skip to main content
Relaymetry

TLS-RPT explained: how to read SMTP TLS reports

TLS-RPT is how you see whether sending servers reach your domain over encrypted connections. You publish one DNS TXT record at `_smtp._tls.<yourdomain>` starting with `v=TLSRPTv1` and a `rua` address, and supporting senders then send you aggregate reports, one per UTC day, on whether their TLS, MTA-STS, and DANE connections succeeded or failed. It is the observability layer for MTA-STS: publish it before or with MTA-STS testing mode so you can read failures before you enforce.

Quick answer

SMTP TLS Reporting (TLS-RPT) is how you see whether sending servers are reaching your domain over encrypted connections. You publish a single DNS TXT record at _smtp._tls.<yourdomain> starting with v=TLSRPTv1 and a rua address. Sending mail transfer agents that support the standard then send you aggregate reports, one per UTC day, summarizing whether their TLS, MTA-STS, and DANE connections to your domain succeeded or failed. TLS-RPT is the observability layer for MTA-STS: publish it before or alongside MTA-STS testing mode so you can read failures before you enforce.

What TLS-RPT is

SMTP TLS Reporting, defined in RFC 8460 and usually shortened to TLS-RPT, is a DNS-published mechanism that asks sending MTAs to send your domain aggregate reports about whether their TLS connections to you succeeded or failed. The same reports also cover the policy mechanisms layered on top of TLS — MTA-STS and DANE.

On its own, TLS at the SMTP layer is opportunistic: a sending server tries STARTTLS, and if negotiation fails it commonly falls back to an unencrypted connection rather than deferring the message. That fallback is silent. Without reporting, you have no way to know that a sender could not establish a secure channel to your MX, that a certificate was rejected, or that an MTA-STS policy you published is causing senders to fail. TLS-RPT closes that gap by giving you a feedback channel.

This matters most when you adopt MTA-STS. MTA-STS testing mode is designed to let you publish a policy without affecting delivery, but testing mode is only useful if you can see what the policy would have done. TLS-RPT is what makes testing mode observable. You read the aggregate reports, confirm that legitimate senders are negotiating TLS cleanly against your published policy, and only then move MTA-STS to enforce.

What the DNS record looks like

TLS-RPT is a single DNS TXT record published at _smtp._tls.<yourdomain>. The record value starts with v=TLSRPTv1 and carries a required rua field. The rua value is a URI that tells senders where to deliver aggregate reports. Two URI schemes are supported: mailto: and https:.

A mailto: endpoint receives reports as email:

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

An https: endpoint receives reports by HTTP POST to the named URL:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1;rua=https://reporting.example.com/v1/tlsrpt"

Either scheme is valid. The choice is purely about how you want to receive and process the reports, not about which information you get. A mailto: address can land in a mailbox a person reads or a parser ingests; an https: endpoint suits an automated processing service or a TLS-RPT vendor.

What the aggregate reports contain

A TLS-RPT aggregate report covers a full UTC day and is delivered after a delay, possibly several hours after the day it describes. Each report carries report metadata — the reporting organization, contact information, a unique report id, and the date range the report covers — alongside the counts and failure details for that period.

The counts tell you how connections went. A report includes a total count of policy-compliant TLS sessions (the successful sessions), and where sessions failed, the report includes failure details describing what went wrong. The schema covers failures in routing, in DNS resolution, and in STARTTLS negotiation, plus policy-validation errors for both DANE and MTA-STS.

A policy-type field on each result indicates which policy applied to the sessions being reported. Its value is one of sts (an MTA-STS policy was in effect), tlsa (a DANE TLSA record applied), or no-policy-found (no MTA-STS or DANE policy was discovered, so the session is reported without a policy context). Reading policy-type tells you whether the sender was acting on the MTA-STS policy you published, on DANE, or on neither.

How to set up TLS-RPT and read the first reports

  1. Decide where reports should go. Choose a rua endpoint you can actually receive at: a mailto: mailbox, an https: endpoint that accepts report POSTs, or a TLS-RPT processing service that gives you one of those endpoints and parses the reports for you.

  2. Publish the TXT record. Add a TXT record at _smtp._tls.<yourdomain> with v=TLSRPTv1 and your chosen rua, for example v=TLSRPTv1;rua=mailto:reports@yourdomain.com or v=TLSRPTv1;rua=https://reporting.yourdomain.com/v1/tlsrpt.

  3. Publish it before or with MTA-STS testing mode. If you are rolling out MTA-STS, get TLS-RPT in place first or in the same change, so that the moment your MTA-STS policy goes live in testing mode you are already collecting reports about it.

  4. Wait a day. Aggregate reports cover a full UTC day and arrive after a delay. Do not expect data within minutes of publishing. Give it at least one full UTC day, and allow several hours beyond that for the first reports to arrive.

  5. Read the policy-type and the counts. When reports start arriving, look at the policy-type (sts, tlsa, or no-policy-found) to confirm which policy senders applied, and compare the successful-session count against the failure details.

  6. Act on the failures before enforcing. Investigate STARTTLS-negotiation failures, certificate problems, and MX or routing failures in the reports. Resolve them while MTA-STS is still in testing mode.

  7. Then move MTA-STS to enforce. Only after the reports show that legitimate senders are negotiating TLS cleanly against your policy should you advance MTA-STS from testing to enforce.

What TLS-RPT does not do

TLS-RPT is report-only. Publishing the record changes nothing about how mail is delivered to your domain. It does not require, downgrade, or block any connection, and it does not enforce TLS — that is what MTA-STS and DANE do. TLS-RPT only asks senders to tell you what happened.

The reports are also aggregate and delayed, not real-time and not per-message. They tell you, after the fact, how a sender's connections to you went across a UTC day. They do not show you the contents of any message, they do not prove inbox placement, and they depend on the sending side supporting the standard and choosing to send reports. A clean TLS-RPT picture confirms that reporting senders reached you over TLS as expected; it is the instrumentation you read before turning MTA-STS on, not a delivery guarantee.

Frequently asked questions

Does publishing a TLS-RPT record change how my mail is delivered?

No. TLS-RPT is report-only. The record asks sending servers to tell you whether their TLS, MTA-STS, and DANE connections to your domain succeeded or failed. It does not require, downgrade, or block any connection, and it does not enforce encryption. Enforcement is what MTA-STS and DANE do. Publishing TLS-RPT only opens a feedback channel; it cannot break delivery.

Should the rua use a mailto: address or an https: endpoint?

Both schemes are supported by RFC 8460 and you get the same report data either way. A `mailto:` endpoint receives each aggregate report as an email, which suits a mailbox a person or a parser reads. An `https:` endpoint receives reports by HTTP POST to the URL you name, which suits an automated processing service or a TLS-RPT vendor. Choose based on how you want to receive and process reports, not on which information you need.

How quickly will I see reports after publishing the record?

Not immediately. Each aggregate report covers a full UTC day and is delivered after a delay, possibly several hours after the day it describes. Expect to wait at least one full UTC day, plus additional hours, before the first reports arrive. TLS-RPT is an after-the-fact, daily aggregate channel, not a real-time or per-message one.

What does the policy-type field in a report mean?

Each result in a report carries a `policy-type` field indicating which policy applied to the sessions being reported. Its value is `sts` when an MTA-STS policy was in effect, `tlsa` when a DANE TLSA record applied, or `no-policy-found` when neither was discovered. Reading `policy-type` tells you whether the sender acted on the MTA-STS policy you published, on DANE, or on no policy at all.

Do I need MTA-STS before I publish TLS-RPT?

No, and the recommended order is the reverse. TLS-RPT is the observability layer for MTA-STS, so you publish TLS-RPT before or alongside MTA-STS testing mode. That way you are already collecting reports the moment your MTA-STS policy goes live in testing, and you can confirm senders are negotiating TLS cleanly before you advance MTA-STS to enforce. TLS-RPT also reports on plain opportunistic TLS and DANE even when no MTA-STS policy exists.

Other email authentication problems

References