TLS-RPT: the encrypted transport report

v=TLSRPTv1; rua=mailto:tlsrpt@example.com

A deliberate format difference

The choice of JSON over XML isn't incidental. DMARC reports inherited XML for historical reasons tied to the era of their design; TLS-RPT, more recent, adopts a lighter format, simpler to parse with modern tooling. Concretely, this means ingestion scripts for TLS-RPT are generally shorter to write than their DMARC equivalents — a nice detail for anyone weighing an in-house processing pipeline rather than dependence on a third-party service — a basic parser can be a few dozen lines of code rather than a few hundred.

The report format

TLS-RPT reports are in JSON format (unlike the XML of DMARC reports), generally gzip-compressed and sent by email as an attachment, or retrievable via API when an https: URI was chosen. Each report covers a 24-hour window and groups results by "policy domain" (the domain whose MTA-STS policy was evaluated) and by failure type.

A typical report states, for example: "4,892 successful sessions to mail.example.com, 3 failed sessions of type certificate-expired, from Gmail, over the period of July 29." This granularity isolates a precise, fixable problem — here, a certificate needing urgent renewal — rather than leaving nothing but a vague complaint from a receiver who noticed some mail wasn't arriving but couldn't say why.

Why it's essential before enforce

MTA-STS's testing mode logs failures without blocking delivery — but that logging is only useful once someone reads it. Without TLS-RPT, there is zero visibility into what that test mode actually observes: a policy goes out, time passes, and the rest is hope. With TLS-RPT, the picture is concrete, day by day — whether connections are failing and why — exactly the same proof-before-hardening logic that applies to the DMARC none → quarantine → reject sequence, detailed in getting to p=reject without breaking legitimate email.

Moving MTA-STS to enforce without having read at least a few weeks of clean TLS-RPT reports is hardening blind: if a legitimate receiving server has a temporary certificate problem, enforce mode will refuse delivery of the sender's mail to it, with no notice other than a silent drop in deliverability, potentially for weeks before anyone notices — and by the time someone does, the trail back to a temporary certificate glitch may already be cold.

Reading a report: what should raise an alarm

Once reports are in place, a few signals deserve particular attention:

• A sudden rise in failure rate toward a specific receiver — often the sign of a certificate or recent configuration problem on their end, worth watching but not necessarily the sender's to fix.
• Repeated mta-sts-policy-invalid failures — these ones are the domain's own doing: the policy itself is malformed or unreachable, and deserves an immediate fix.
• certificate-expired failures on the domain's own servers — the most urgent signal, since it means the local infrastructure has an expired TLS certificate, potentially blocking receipt of legitimate mail as soon as MTA-STS moves to enforce — this one comes before anything else on the list.
• A total absence of reports — the DNS syntax deserves a check before anyone concludes everything's fine; as with rua in DMARC, a malformed record can simply prevent reports from being sent rather than signal an absence of traffic. The same patience reflex applies: 48 hours before worrying about the silence, and no repeated rewrites of the record during that window, since each edit can reset the clock on propagation.

After enforce: TLS-RPT stays on

Once MTA-STS reaches enforce, the temptation is to treat TLS-RPT as scaffolding to tear down — the proof is in, so why keep watching? It's exactly backwards. enforce is when the reports become most valuable: a certificate that expires, a mail server migration, an MX change forgotten in the policy file — each of these ordinary events can start blocking legitimate mail, silently, overnight. TLS-RPT is then the only channel that raises the alarm before the correspondents do. It belongs in permanent monitoring, on the same footing as the DMARC rua mailbox: a feed that stays read for as long as the policy exists, not just during its testing phase.

The link with DANE and other transport-security mechanisms

TLS-RPT isn't exclusively tied to MTA-STS, even though that's by far the most common use. RFC 8460 designs the protocol as a generic reporting mechanism for SMTP transport-security failures, which also includes DANE (DNS-based Authentication of Named Entities), an alternative approach that anchors TLS validation in DNSSEC records rather than an HTTPS policy file. Where an organization has deployed DANE instead of (or alongside) MTA-STS, TLS-RPT keeps providing the same visibility into connection failures, with error codes suited to that mechanism.

In practice, the vast majority of 2026 deployments favor MTA-STS for its simplicity — DANE requires a DNSSEC infrastructure already in place and correctly maintained, a higher technical bar for many organizations. But the fact that TLS-RPT covers both mechanisms means the investment in setting up reports isn't wasted should the approaches be migrated or combined later — the reporting infrastructure survives a change of transport-security mechanism underneath it.

The 24-hour window and the lag to anticipate

As with DMARC aggregate reports, a lag separates the observed event from its arrival in the reporting mailbox. A TLS-RPT report covering July 29 generally arrives on the 30th or 31st, once the sending provider has finished aggregating its own observations over the window. That lag has a direct practical consequence on the monitoring cadence during MTA-STS's testing phase: no instant signal follows a server-side configuration change — the realistic planning figure is a 48-to-72-hour delay before a fix's real effect on the observed failure rate becomes readable — and the same patience discipline that governs DMARC reports is the default here too.

Tooling: reading JSON by hand isn't viable

As with DMARC reports, manually reading dozens of daily compressed JSON files is only realistic for a very small domain. Once volume grows past a handful of daily files, an aggregation tool that turns these reports into a readable dashboard becomes necessary — the same kind of platform already handling DMARC aggregate reports often supports TLS-RPT in parallel, since both flows share the same collection and visualization logic. Pooling both in a single tool avoids multiplying dashboards to watch separately, and makes it easier to correlate an authentication incident with a transport incident occurring over the same period.

In summary

TLS-RPT is to MTA-STS what aggregate reports are to DMARC: the proof loop that turns a blindly published policy into hardening grounded in real data. Configuring it is one more DNS record, with no external-authorization trap to manage, and reading its reports regularly is what distinguishes a careful MTA-STS rollout from a risky bet on deliverability that only surfaces its cost weeks after the fact.

Checking the state of baseline email authentication — the foundation MTA-STS and TLS-RPT build on top of — starts with a domain run through the free DMARC analyzer. That's the step to handle first; encrypted transport then completes an already-solid identity, rather than replacing it, and that's the order in which both protocols deliver the most value for the effort involved — the identity first, then the assurance that the pipe carrying it stays sealed.