Loading...
Loading...
TLS-RPT publishes a reporting address that asks sending mail providers to send you a daily summary of every failed or downgraded TLS connection to your mail servers, so problems with MTA-STS or STARTTLS surface as data instead of silently dropping mail.
TLS-RPT is diagnostic, not protective, so its absence does not directly expose you to attack. The cost is blindness. If your MTA-STS policy is misconfigured, a mail server certificate expires, or a sender is forced to downgrade to cleartext, messages can be deferred or delivered unencrypted and you get no signal that it happened. The practical consequence is that you cannot safely tighten MTA-STS from testing to enforce mode: without TLS-RPT data you have no idea which senders your policy would break, so you either leave MTA-STS in permissive testing mode forever or you flip to enforce blind and risk blackholing legitimate mail.
RFC 8460 defines a single TXT record published at `_smtp._tls.yourdomain.com` beginning with `v=TLSRPTv1`. The only functional tag is `rua` (Reporting URI for Aggregate reports). There is no forensic or `ruf` tag, unlike DMARC. The `rua` value accepts two URI schemes, `mailto:` and `https:`, and you can list several comma-separated endpoints in one record. Reports are JSON, gzip-compressed, and cover a full 00:00 to 24:00 UTC day, delivered once per day (senders often delay several hours to batch processing). A `mailto:` report arrives as an attachment with `Content-Type: application/tlsrpt+gzip`; an `https:` report is POSTed to your endpoint with the same content type. Each report names the sending organization, the period covered, and for every policy type applied (`sts`, `tlsa`, or `no-policy-found`) the count of successful sessions, the count of failures, and per-failure detail such as `certificate-expired`, `certificate-host-mismatch`, or `starttls-not-supported`. TLS-RPT is the feedback channel for MTA-STS (RFC 8461): deploy both together, keep MTA-STS at `mode: testing` while you read TLS-RPT reports, and only move MTA-STS to `mode: enforce` once the reports are clean. Unlike DMARC external report addresses, TLS-RPT does not require a cross-domain authorization record, so the `rua` address can live on any domain. The `/docs/mta-sts-complete-setup` guide walks through the paired rollout.
TLS-RPT is a TXT record at `_smtp._tls.yourdomain.com` starting with `v=TLSRPTv1`. A missing record means no sending provider will report TLS failures to you, so MTA-STS problems, expired mail-server certificates, and forced downgrades to cleartext all stay invisible. Confirm the record and check that an MTA-STS policy exists alongside it, since TLS-RPT with no MTA-STS or DANE has nothing to report enforcement on.
dig +short TXT _smtp._tls.yourdomain.comdig +short TXT _mta-sts.yourdomain.comhttps://mxtoolbox.com/tlsrpt.aspxNo. TLS-RPT is a reporting mechanism only. It tells sending providers where to mail you statistics about TLS successes and failures. The actual requirement that mail be encrypted comes from MTA-STS (RFC 8461) or DANE. Publish TLS-RPT to see what is happening, then use MTA-STS to make encryption mandatory.
`mailto:` is the simplest and most widely accepted starting point, delivering gzipped JSON as an email attachment. `https:` POSTs reports to a webhook, which is better if you run a processor that ingests them automatically. You can list both, comma-separated, in one record. Unlike DMARC, no external authorization record is required for an address on another domain.
The large senders that implement RFC 8460 do, including Google, Microsoft, and Yahoo. Coverage is not universal across every mail server on the internet, but because these providers carry a huge share of mail, even partial coverage gives you meaningful visibility into TLS delivery health.
It is most valuable paired with MTA-STS or DANE, because those give the reports a policy to measure against. On its own it can still surface opportunistic STARTTLS failures and downgrade attempts, but you will see mostly `no-policy-found` results. The recommended order is to publish TLS-RPT and MTA-STS at `mode: testing` together, read a few weeks of reports, then move MTA-STS to enforce.
Applied the configuration change? Run a live scan to confirm the vulnerability is patched.