TLS-RPT Generator

Why bother

TLS problems on the receiving side are invisible from the inside. A certificate expires, the name in it stops matching the server, an intermediate hop strips STARTTLS, and the sender either delivers the message some other way or does not deliver it at all, and you never hear about it. TLS-RPT turns that invisible layer into a daily summary.

Where to publish it

As a TXT record at _smtp._tls.yourdomain. Most panels only need _smtp._tls in the name field. Both underscores are mandatory.

What is inside a report

Reports arrive as a JSON document, usually gzipped. Only a few fields matter:

• policy-type — which rule the connection was checked against: sts for MTA-STS, tlsa for DANE, or no-policy-found when there is no policy at all.
• successful-session-count and failed-session-count — how many connections went through and how many broke over the day. These are the two worth charting.
• failure-details — the reason: certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure, along with the IP address it happened on.

What to look at first

Isolated failures are normal, whether networks, timeouts, somebody's broken relay. The signal worth acting on is a steady failure rate from one provider, or certificate-expired climbing everywhere at once, which is almost always a certificate on your MX that did not renew automatically.

The second thing these reports catch is starttls-not-supported from hosts you believed were encrypted. Usually the culprit is an intermediate gateway or an anti-spam proxy stripping STARTTLS out of the server response. You cannot diagnose that from the inside; from the outside it is obvious.

What the record contains

Two tags. v=TLSRPTv1 is the version and comes first. rua= is the reporting destination: either mailto:tls@example.com or https://example.com/tlsrpt to receive them by POST. Several addresses are separated by commas.

Unlike DMARC, an external address needs no confirming record, and it only has to accept mail. That makes handing reports to a contractor or an analysis service straightforward.

Why bother when mail already arrives

TLS-RPT changes nothing about delivery. It is the only way to see the problems senders are having with you. From inside the domain you cannot tell that an intermediate hop strips STARTTLS, or that the certificate on one of your backup MX hosts expired a month ago.

It earns its place in two situations. Deploying MTA-STS: in testing mode the reports show exactly what would break under enforce, before it breaks. And changing mail provider, while some senders are still working from cached data.

What to do with the reports

The format is machine-oriented, and reading it by hand makes sense for the first few weeks, long enough to confirm nothing is failing. After that either feed them to an analyser or set up a simple rule: anything with a non-zero failed-session-count goes to its own folder, the rest is ignored.

No reports at all is also a signal, and an easy one to miss. A week without a single message from the large providers usually means the record is published under the wrong name: it is _smtp._tls with two underscores, not smtp.tls, and not at the domain root.

The order to deploy channel protection

TLS-RPT goes first because it is the one piece that cannot break anything: reports accumulate, delivery is unchanged. A week of observation establishes the baseline, showing how many connections use TLS at all, and from whom.

Then MTA-STS in testing mode: the reports start showing where policy and reality disagree, so before moving to enforce you can see which MX host would fail. Only after a clean week, enforce. Done in the opposite order, mail stops arriving and there is no data to explain why.