DNSVerdictAll toolsGuidesHow it works

How to set up TLS-RPT (SMTP TLS Reporting)

Published · Updated

TLS-RPT is one TXT record at _smtp._tls.yourdomain that asks other mail servers to send you reports about TLS problems they had while delivering mail to you. It is the feedback channel for MTA-STS and DANE: without it, you find out about a broken certificate from your users’ missing mail.

_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

RFC 8460 §3 defines the record: it must begin with the version tag v=TLSRPTv1, and the rua directive is required. Check whether your domain publishes it with the email score or the DNS lookup (type TXT, name _smtp._tls.yourdomain).

The rua value

FormExampleHow reports arrive
mailto:rua=mailto:[email protected]Email with a (usually gzipped) JSON attachment, §5.3
https:rua=https://tlsrpt.example.com/v1HTTP POST of the report to your endpoint, §5.4
Bothrua=mailto:[email protected],https://x.example.com/v1Comma-separated; senders pick

Use a dedicated mailbox rather than a person’s inbox, because each reporting sender mails its own file. If you point rua to a different domain, check the reporting service’s documentation for any extra record it needs. Reporting services that accept https: endpoints publish the exact value to use.

What does a TLS-RPT report contain?

Per §4, a report is a JSON file covering a time frame, normally 24 hours. It includes:

Failures that senders report include negotiation problems (no STARTTLS offered), certificate problems (expired, name mismatch, untrusted), and policy-fetch failures for MTA-STS. The full list is in §4.3. A typical mistake it exposes: an MX host missing from the mx: list in your MTA-STS policy, or a renewed certificate not installed on the secondary MX.

Reports are plain JSON and readable with zcat report.json.gz | less. If volume is larger than you want to read by hand, a TLS-RPT processing service will parse them; that is a choice, not a requirement.

Does TLS-RPT work with MTA-STS and DANE?

Publish and verify

  1. Create the mailbox or HTTPS endpoint that will receive reports.
  2. Add the TXT record at _smtp._tls, not at the apex. One record only.
  3. Query it back. The v=TLSRPTv1 tag must come first, and rua must contain a valid mailto: or https: URI.
  4. Wait a day or two. Reports only come from senders that support TLS-RPT and that actually delivered mail to you, so a quiet domain may see few of them.

Trade-off: the reports tell outsiders nothing, but your mailbox will receive data about which hosts sent you mail. If you send reports to a third-party service, that service sees it too.

FAQ

Is TLS-RPT useful without MTA-STS? Less so. RFC 8460 is built around reporting on MTA-STS and DANE validation, and its schema (§4) has a no-policy-found type for sessions where the sender found neither. Without a policy, there are no policy-validation failures to report, so the reports carry little detail. Publish TLS-RPT together with MTA-STS or DANE to get failure reasons you can act on.

Will TLS-RPT change how my mail is delivered? No. The record only asks senders to report on TLS results, and RFC 8460 §3 defines it as a reporting policy, not a delivery policy. Whether a message is delivered, deferred or refused after a TLS failure is decided by the sender’s handling of your MTA-STS policy (RFC 8461 §5) or DANE records (RFC 7672), not by TLS-RPT.

Why have I received no reports? Reports arrive only from senders that implement TLS-RPT and have attempted delivery to you in the reporting period, normally 24 hours (RFC 8460 §4). Confirm the record sits at _smtp._tls, starts with v=TLSRPTv1, and that the mailto: mailbox accepts compressed attachments. A quiet domain may see few reports even when everything is correct.

Sources

Tools used

Email Deliverability ScoreDMARC Record CheckerDNS Lookup