What exactly gets sent to me?

Aggregate reports about TLS connections to your mail servers: how many delivery attempts were encrypted successfully, how many were not and what went wrong. The format is JSON inside a gzip archive, one report per receiver and day. It is not meant to be read by hand; there are ready-made evaluators for it.

Do I need MTA-STS or DANE for this?

No, TLS-RPT works on its own and is useful on its own: you see how often your domain is reached over an encrypted connection at all. Together with MTA-STS it becomes particularly valuable, because TLS-RPT is how you learn what MTA-STS testing mode has reported.

Email address or HTTPS endpoint?

The address is the simpler route and is supported everywhere; use a dedicated one, not your work mailbox. An HTTPS endpoint pays off when you evaluate the reports automatically anyway: they then land in the evaluator directly instead of taking the detour through a mailbox. Having both is allowed.

Can I give several targets?

Yes, RFC 8460 allows several targets, and every receiver sends its report to all of them. In practice one or two are enough; each further target only multiplies the volume that arrives daily anyway.

Where exactly do I enter the record?

As a TXT entry on _smtp._tls.your-domain.com. At most providers you only type _smtp._tls as the name because the domain is appended automatically; the generator shows the full name to be safe.

Does the record reveal anything about my infrastructure?

The record contains only the report target, and it is public in DNS. That is exactly why no credentials belong in it, not even inside an HTTPS address. If you have reports sent to an endpoint, secure it some other way, for instance with a hard-to-guess path and server-side checks.

Does the generator change anything in my DNS?

No. It only produces text that you copy and enter at your DNS provider yourself. It also queries nothing, it computes purely from what you enter.

TLS-RPT Generator

Create a TLS-RPT record so that TLS delivery problems do not stay silent.

TLS-RPT makes sure you find out when other mail servers cannot reach your domain over an encrypted connection. Without it, a failed TLS connection fails silently: the sending server either delivers unencrypted or not at all, and nothing on your side hints at it. A TLS-RPT record is a single TXT entry and the only way to see those cases in the first place.

What the generator does

You state where the reports should go. There are two kinds of target, and the generator has you pick the kind rather than write it into an address: an email address or an HTTPS endpoint. It adds the required mailto: or https:// itself, validates every value and assembles the finished entry. Several targets are allowed, and each gets its own row.

What matters here too is the name of the entry: it belongs on _smtp._tls. in front of your domain, not on the domain itself. As with DMARC and MTA-STS, the wrong name is the mistake that does not stand out, because no report ever arrives.

Reading the result

The notes below the record mostly say what actually turns up, because that is a recurring misunderstanding. The reports are not readable error messages but JSON files inside gzip archives that arrive once a day from every larger receiver. A personal mailbox is the wrong place for them; a dedicated address that is evaluated automatically works better, or an HTTPS endpoint straight away.

When an HTTPS endpoint is given, receivers POST the reports there with the content type application/tlsrpt+gzip. The endpoint has to be able to accept that, otherwise the reports are lost without anyone noticing.

Background: what the RFC requires

RFC 8460 is authoritative. It requires exactly two things: v=TLSRPTv1 as the first tag, written exactly like that, and rua with at least one target. Only mailto: and https: are allowed there; plain http is invalid, which is hard to argue with for a mechanism that reports failed encryption.

TLS-RPT belongs with MTA-STS and DANE but is independent of both and can be set up on its own. It is particularly worthwhile before MTA-STS: in testing mode MTA-STS reports deviations, and TLS-RPT is the channel through which those reports reach you. Without TLS-RPT, testing mode is an observation nobody observes.

Common failure patterns

The record sits on the domain instead of _smtp._tls. It is then never found.
The address entered without mailto: The record looks right and is invalid; this generator therefore adds the prefix itself.
Reports to a personal mailbox. Several gzip archives a day that nobody opens, and after two weeks a rule filters them away.
An HTTPS endpoint that does not accept POST. The reports disappear silently.
TLS-RPT set up but never evaluated. The reports are the whole point; without evaluation the entry is decoration.

Once the entry is in DNS, check it with the MTA-STS and TLS-RPT Check: it reads the record, names the configured targets and shows how MTA-STS is doing at the same time.

Common questions

What exactly gets sent to me?: Aggregate reports about TLS connections to your mail servers: how many delivery attempts were encrypted successfully, how many were not and what went wrong. The format is JSON inside a gzip archive, one report per receiver and day. It is not meant to be read by hand; there are ready-made evaluators for it.
Do I need MTA-STS or DANE for this?: No, TLS-RPT works on its own and is useful on its own: you see how often your domain is reached over an encrypted connection at all. Together with MTA-STS it becomes particularly valuable, because TLS-RPT is how you learn what MTA-STS testing mode has reported.
Email address or HTTPS endpoint?: The address is the simpler route and is supported everywhere; use a dedicated one, not your work mailbox. An HTTPS endpoint pays off when you evaluate the reports automatically anyway: they then land in the evaluator directly instead of taking the detour through a mailbox. Having both is allowed.
Can I give several targets?: Yes, RFC 8460 allows several targets, and every receiver sends its report to all of them. In practice one or two are enough; each further target only multiplies the volume that arrives daily anyway.
Where exactly do I enter the record?: As a TXT entry on _smtp._tls.your-domain.com. At most providers you only type _smtp._tls as the name because the domain is appended automatically; the generator shows the full name to be safe.
Does the record reveal anything about my infrastructure?: The record contains only the report target, and it is public in DNS. That is exactly why no credentials belong in it, not even inside an HTTPS address. If you have reports sent to an endpoint, secure it some other way, for instance with a hard-to-guess path and server-side checks.
Does the generator change anything in my DNS?: No. It only produces text that you copy and enter at your DNS provider yourself. It also queries nothing, it computes purely from what you enter.