What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting, RFC 8460) is the reporting channel for MTA-STS and DANE. Sending mail servers that run into TLS problems when delivering to your domain send a daily summary report to the address you publish in the TLS-RPT record. It lists how many connections succeeded, how many failed and why: expired certificate, host name mismatch, STARTTLS not offered, policy not fetchable.
Without TLS-RPT, MTA-STS is flying blind. You publish a policy and never learn whether it locks senders out. With TLS-RPT you see within a day whether Google, Microsoft or other large providers report failures, and you can safely move from testing to enforce.
Anatomy of the record
The record is a TXT record at _smtp._tls.example.com with exactly two tags: v=TLSRPTv1 and rua= with one or more reporting addresses separated by commas. Allowed are mailto: addresses and https: endpoints that accept reports as JSON via POST.
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"How to read the result
The checker shows the record and the recognised reporting targets. These findings are possible:
- No record: only a notice. You receive no reports; delivery is unaffected.
- No rua: the record exists but names no target. It has no effect.
- Invalid rua: a target is neither a mailto: address nor an https URL, for example an address without @ or an http URL.
- Multiple records: only one TLS-RPT record is allowed. With several, senders ignore all of them.
Receiving and reading reports
Reports arrive as compressed JSON attachments by email. For a single domain a mailbox you check occasionally is enough. For many domains a service that collects and presents the reports pays off; the providers that analyse DMARC reports usually offer this too. The reporting address may be on another domain; unlike DMARC, no authorisation record is needed.
A report contains, per sender, the policy it applied (MTA-STS, DANE or none), the number of successful and failed sessions and, per failure class, details such as the affected MX and the IP of the sending server. With this information a certificate problem can usually be attributed to a specific server within minutes.
Important: reports only come from senders that support TLS-RPT. Google and Microsoft do, many smaller servers do not. A day without a report therefore does not mean everything is fine, only that the supporting senders had no failures.
Monitor TLS-RPT and MTA-STS together
TLS-RPT is the prerequisite for running MTA-STS safely. DomainWarn checks for all client domains whether the record exists and is valid, and reports when it disappears, for example because a zone was copied incompletely during a hosting migration.
Frequently asked questions
- Do I need TLS-RPT without MTA-STS?
- The benefit is small then, but not zero: senders still report TLS failures such as an expired certificate on the MX. TLS-RPT is most useful as the first step before introducing MTA-STS.
- Can I use the same address as for DMARC reports?
- Technically yes, but the formats differ. If you use an analysis service it usually gives you a dedicated address for TLS-RPT.