Glossary term

TLS-RPT: the report that says who couldn't reach you securely

Q: What failures should worry me most in a report?

starttls-not-supported and certificate errors reported by multiple senders point at your infrastructure and block enforce-mode mail. Policy-fetch errors mean the MTA-STS side is broken. Single-reporter oddities are usually the reporter's problem.

What TLS-RPT is

TLS-RPT, short for SMTP TLS Reporting and defined in RFC 8460, is a mechanism by which sending mail servers report back to a receiving domain about their TLS experience delivering to it: how many sessions negotiated encryption successfully, how many failed, and exactly why each failure happened. It is the feedback channel for transport security, playing the same role for MTA-STS and DANE that aggregate reports play for DMARC.

You request the reports with one TXT record:

_smtp._tls.yourbrand.com.  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourbrand.com"

Participating senders (Google and Microsoft among them) then deliver a daily JSON report per sender covering all their attempts to your domain: sessions attempted, sessions that succeeded, and failures broken down by cause, from STARTTLS not offered through certificate errors to policy mismatches.

The problem TLS-RPT solves is silence. When a sending server cannot establish the TLS session your policy demands, nothing tells you. The mail defers and retries, or, absent a strict policy, downgrades to plaintext, and the receiving domain's operators see nothing at all. TLS-RPT converts that invisible failure class into a monitored data stream.

How TLS-RPT differs from MTA-STS

The two protocols ship as a pair so often that they blur together. The division of labor is strict.

MTA-STS is the policy: your domain's published requirement that inbound mail arrive over authenticated TLS, with an enforce mode that instructs senders to withhold delivery otherwise. It changes sender behavior.

TLS-RPT is the telemetry: a request that senders describe what happened when they tried. It changes nothing about how mail flows — a domain with TLS-RPT alone still accepts plaintext exactly as before. It only makes the outcomes observable.

Each is useful without the other, but asymmetrically. TLS-RPT without a policy still reveals your baseline: what fraction of inbound sessions negotiate TLS today, and which senders fail. A policy without TLS-RPT is the dangerous combination — MTA-STS in enforce mode can be quietly blocking legitimate mail, and without reports the first symptom you see is someone asking why their messages never arrived. The deployment grammar is therefore: TLS-RPT first, observe, then policy in testing mode, observe, then enforce.

How TLS-RPT works

The record. One TXT entry at _smtp._tls.{domain} with a version tag and one or more rua destinations, which may be mailto: addresses or HTTPS endpoints that accept POSTed reports. Confirm it resolves alongside the rest of your mail DNS with the email DNS check.

The reports. Each participating sender aggregates its day's delivery attempts to your domain into a single JSON document (gzip-compressed when mailed), covering a stated 24-hour window. Per policy observed (MTA-STS, TLSA/DANE, or none) the report counts successful sessions and failed ones, and itemizes failures with a result type from the RFC's registry:

starttls-not-supported — your server never offered encryption
certificate-expired, certificate-not-trusted, certificate-host-mismatch — the TLS handshake reached a certificate problem
validation-failure — the negotiated session violated the policy
sts-policy-fetch-error, sts-policy-invalid — the sender could not retrieve or parse your MTA-STS policy
sts-webpki-invalid — the policy host's own HTTPS certificate failed

Sending failure reports about failures. RFC 8460 handles the obvious chicken-and-egg: a sender that cannot reach you over TLS must still be able to deliver the report saying so. Reports mailed to your own domain are sent without strict policy enforcement applied to the report delivery itself, and an HTTPS rua sidesteps the mail path entirely — one reason vendors and larger operators prefer the HTTPS destination.

Consumption. One domain receives one report per participating sender per day; a real inbound footprint means a steady stream of JSON. As with DMARC data, sustainable practice is a parsing service or a small pipeline, with the raw mailbox as archive.

TLS-RPT and your deliverability

TLS-RPT guards the receiving side of your mail estate, and three sender-relevant benefits fall out of it.

Safe MTA-STS enforcement. The reports are the instrument that makes tightening transport policy responsible. In testing mode, every failure that would have blocked mail appears in the day's JSON with its cause; you fix certificates and MX listings until the failure count is noise, then enforce with evidence instead of hope. This mirrors the p=none → enforcement path DMARC teams walk with aggregate reports.

Early warning on infrastructure decay. An expiring certificate on one MX, a load balancer dropping STARTTLS after a change, a stale MX record pointing at a decommissioned host — each surfaces as a new failure signature from multiple reporters within a day. Without TLS-RPT, the same faults surface as unexplained deferrals and missing mail, discovered by humans.

Reply-path integrity. Senders live or die by their outbound reputation, but their business runs on inbound too: replies, bounce processing at the return-path domain, unsubscribe mailboxes. TLS-RPT is how you verify that the channels carrying that traffic negotiate encryption from the providers that matter, which is part of the same hygiene story as domain reputation.

Limitations and failure modes

Reports without readers. The DMARC lesson repeats: a rua destination nobody monitors converts telemetry into landfill. Decide who reviews the stream and on what cadence before publishing the record, or the enforcement mistake TLS-RPT exists to prevent happens anyway, with the evidence sitting unread.

Participation is partial. Only senders that implement RFC 8460 file reports. The large providers do, which covers most consumer volume; the long tail of small MTAs fails silently exactly as before. Absence of failure reports from a sender is not evidence of successful TLS with that sender.

A daily cadence, not an alarm. Reports summarize a 24-hour window, delivered after it closes. A certificate that expired this morning blocks mail all day before the JSON says so. For change windows (migrations, certificate rotations) pair the reports with an active check of your own MX hosts rather than waiting for the mesh to tell you.

JSON is not a dashboard. Raw reports from a dozen senders across a fleet of domains defeat manual reading within a week. Unlike DMARC XML, the format is at least pleasant, but the operational answer is the same: parse, aggregate, alert on new failure types.

Misattributing the fault. certificate-not-trusted from one reporter and clean sessions from five others usually indicts the reporter's trust store or a network path, not your certificate. Fix on consensus signals; investigate outliers as sender-side.

Scope creep in interpretation. TLS-RPT describes transport to your MX, nothing else. It says nothing about your outbound deliverability, nothing about content, and nothing about authentication — a domain can have flawless TLS-RPT reports and still fail SPF everywhere. Keep the layers distinct when debugging.

Frequently asked questions

Do I need MTA-STS before deploying TLS-RPT? No — the reverse order is best practice. TLS-RPT alone is harmless and informative: publish it first, learn your baseline, and use the data to deploy MTA-STS testing and then enforce mode without surprises.

Who actually sends TLS-RPT reports? Sending mail systems that implement RFC 8460, which includes Google and Microsoft. Coverage of consumer mail volume is therefore substantial, while many smaller senders report nothing.

Should rua be a mailto or an HTTPS endpoint? Either is valid. HTTPS avoids the irony of failure reports traveling the possibly failing mail path and suits automated pipelines; mailto is simpler to stand up. Monitoring vendors typically hand you an HTTPS endpoint or a dedicated address.

What is the difference between TLS-RPT and DMARC reports? Layer. DMARC aggregate reports describe authentication outcomes: who sent as your domain and whether SPF and DKIM aligned. TLS-RPT describes transport outcomes — whether sessions to your MX encrypted successfully. A complete monitoring posture reads both.

What failures should worry me most in a report? starttls-not-supported and certificate errors reported by multiple senders point at your infrastructure and block enforce-mode mail. Policy-fetch errors mean the MTA-STS side is broken. Single-reporter oddities are usually the reporter's problem.

Does TLS-RPT expose message content or addresses? No. Reports carry session counts, failure types, policy details and sending/receiving IP information — operational metadata only, which is why the privacy calculus is closer to DMARC aggregate reports than to forensic ones.

Publish the _smtp._tls record this week — the record costs one TXT entry and the reports cost nothing. Within days you will know what fraction of your inbound mail encrypts cleanly, and you will have the baseline that makes an MTA-STS rollout a controlled change instead of a leap.