How it works
To enable TLS-RPT you publish a TXT record at _smtp._tls.example.com, for example v=TLSRPTv1; rua=mailto:tlsrpt@example.com. The rua tag lists one or more destinations for the reports: a mailto address, or an https URL that receives the report as a POST request.
Senders that support TLS-RPT, Google and Microsoft among them, then send one aggregate report per day as JSON, usually gzip-compressed. It states the policy they applied (MTA-STS, DANE or none), how many TLS sessions succeeded and failed, and for failures the reason – an expired certificate, a hostname mismatch, missing STARTTLS, an MTA-STS policy that could not be fetched – along with the affected MX and the sending IP address.
TLS-RPT does not protect anything by itself and never changes how mail is delivered. It is the feedback channel for MTA-STS and DANE: without the reports you cannot tell whether your policy works in practice or senders have been failing to reach your mail server for days.
Why it matters
Without TLS-RPT, delivery problems stay invisible. When the mail server certificate expires or an MTA-STS policy no longer matches after a provider switch, senders using enforce mode or DANE refuse delivery, and you only find out when clients complain about missing email.
A broken record, say with a typo in the address or no rua at all, is as good as none: reports go nowhere. Delivery is not affected, but you lose your early warning system right when you need it most, for example while moving MTA-STS from testing to enforce.
How to prevent it
- Publish a TLS-RPT record at _smtp._tls of the domain before or together with MTA-STS or DANE.
- Use a dedicated address for the reports rather than a personal inbox; they arrive daily and are meant for machines.
- Don't just collect the reports, have them parsed, for example by using the DomainWarn report address, which shows DMARC and TLS-RPT reports right in the dashboard.
- Publish a single v=TLSRPTv1 record and check that it is still valid after every edit.
- Before switching MTA-STS to enforce, go through several weeks of reports looking for failed sessions.
How DomainWarn detects it
The TLS-RPT check reads the TXT record at _smtp._tls and verifies that it starts with v=TLSRPTv1 and contains at least one plausible destination, meaning a mailto address or an https URL. A missing record produces a notice with a sample record. A broken one (no rua, an unusable destination or multiple records) produces a warning without an incident, since only reports are lost. The MTA-STS check also points out a missing TLS-RPT record.
Changes to the record are reported as “TLS-RPT changed”. If you add the DomainWarn report address as rua, the reports themselves land in the domain's Email tab, where you can see whether senders reach your mail servers over TLS and why sessions fail.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.