TLS-RPT

A TXT record at `_smtp._tls.example.com` containing a version tag and one or more report destinations.

Destinations are given as `mailto:` addresses or `https:` endpoints. Mail addresses are the common choice and are simplest to set up.

The record is independent of MTA-STS: it can be published on its own, and it is worth publishing first.

No policy or enforcement is implied. Publishing it changes nothing about how mail is delivered.

It is also independent of DANE, the DNSSEC-based alternative to MTA-STS: a domain using either mechanism, or neither, can still collect these reports.

A JSON document covering one day, listing each sending organisation's sessions to your domain.

Counts of successful sessions and of failures, broken down by failure type: certificate mismatch, expired certificate, STARTTLS not offered, policy not found, validation failure.

The MX hostnames involved and, for failures, the sending IP addresses, which is what makes a problem traceable.

Reports arrive as compressed attachments, one per sending organisation per day, so a domain receiving mail from many senders receives several.

The format is defined in the specification rather than left to each sender, so reports from different organisations parse identically and can be aggregated without per-sender handling.

MTA-STS in `enforce` mode makes failures into deferred mail. Knowing in advance which senders would fail turns that from a risk into a checklist.

Certificate problems on a mail server are frequently invisible: nothing warns when an MX hostname's certificate stops matching, because delivery continues unencrypted.

Reports also reveal senders attempting delivery that you did not know about, which occasionally identifies misdirected or spoofed traffic.

The sequence that works is: publish TLS-RPT, publish MTA-STS in `testing`, read reports for a few weeks, then move to `enforce`.

Publish the record and confirm it with `dig _smtp._tls.example.com TXT +short`.

Point it at a mailbox that is actually read, or at a service that parses the JSON. The reports are machine-readable and tedious by hand.

Expect nothing for the first day or two: reports are daily summaries, generated after the period they cover.

A total absence of reports after a week usually means the record is wrong rather than that everything is perfect, since large senders report routinely.

Read the failure types rather than only the counts. A handful of `certificate-host-mismatch` entries from one sender points at a specific MX hostname, while `starttls-not-supported` across many senders points at the mail server itself.