TLS-RPT delivers daily JSON reports on every failed TLS negotiation to your domain. The record, the report format, and how to turn failures into fixes.
Transport encryption failures are silent by design. When a sending server cannot negotiate TLS with your MX, it either falls back to plaintext or defers, and you learn nothing either way. TLS-RPT (RFC 8460) fixes the silence: large senders will mail you a daily JSON summary of every TLS problem they hit delivering to your domain. If you deployed MTA-STS after our last article, this is the feedback channel that tells you whether enforce mode is safe.
Enabling reports
Publish one TXT record naming where reports should go. The address can be a mailbox or an HTTPS endpoint; mail is the common choice and the report mail itself is just email with a gzipped JSON attachment.
Reading a report
Each report covers one day from one sender's perspective and is grouped by policy: which MTA-STS or DANE policy the sender evaluated, how many sessions succeeded, and how many failed with what result types. The structure is small enough to read by eye for a single domain, and regular enough to parse trivially.
1{
2 "organization-name": "Google Inc.",
3 "date-range": {
4 "start-datetime": "2025-05-12T00:00:00Z",
5 "end-datetime": "2025-05-12T23:59:59Z"
6 },
7 "policies": [{
8 "policy": {
9 "policy-type": "sts",
10 "policy-domain": "example.com",
11 "mx-host": ["mx1.example.com", "mx2.example.com"]
12 },
13 "summary": {
14 "total-successful-session-count": 14892,
15 "total-failure-session-count": 37
16 },
17 "failure-details": [{
18 "result-type": "certificate-expired",
19 "receiving-mx-hostname": "mx2.example.com",
20 "failed-session-count": 37
21 }]
22 }]
23}That example is the everyday catch: one backup MX with an expired certificate, invisible to users because opportunistic TLS fell back or retried against the primary, and fatal the day you switch MTA-STS to enforce. Thirty-seven failed sessions in a report is a calendar reminder someone missed.
The failure types worth memorizing
Result types cluster into three diagnostic families. Negotiation failures (starttls-not-supported, validation-failure during handshake) usually mean a middlebox, a broken MX, or an attacker; a sudden burst of starttls-not-supported from one network is what a downgrade attack looks like in data. Certificate failures (certificate-expired, certificate-host-mismatch, certificate-not-trusted) are operational debt on your MX hosts and account for most real-world entries. Policy failures (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid) mean the MTA-STS scaffolding itself broke: the policy host is down, the file is malformed, or its certificate lapsed.
The mapping from family to owner is what makes the reports operational. Certificate entries page whoever runs the MX fleet. Policy entries page whoever owns the mta-sts subdomain and its hosting. Negotiation anomalies from a single origin network are a security question, not an infrastructure one.
Operating on the data
A lightweight TLS-RPT practice
- 1
Automate ingestion
Parse attachments into rows (date, reporter, result type, MX host, count). parsedmarc handles TLS-RPT alongside DMARC aggregates, so most teams need no new tooling.
- 2
Alert on new failure types, not counts
A handful of transient failures is background noise. A result type appearing for the first time, or failures concentrating on one MX, is the actionable pattern.
- 3
Gate MTA-STS promotion on quiet reports
Hold in testing mode until reports show near-zero failures for two consecutive weeks. The success counts prove enforcement would have delivered the same mail.
- 4
Correlate with change windows
MX migrations, certificate renewals, and provider switches should each be followed by a deliberate look at the next few reports. This is the cheapest post-change verification you will ever get.
Limits worth knowing
Only senders that implement RFC 8460 report, which in practice means the large providers plus a scattering of security-conscious operators. Small MTAs fail silently exactly as before, so absence of reported failures is not proof of universal health; it is proof that the senders who carry most of your inbound volume are succeeding. The reports also describe sessions, not messages, and say nothing about mail that was never attempted.
None of that reduces the value. Gmail and Microsoft between them attempt delivery to almost every domain daily, which makes their reports a free, continuous, external probe of your TLS posture from the vantage points that matter most.
Frequently Asked Questions
Do I need MTA-STS before TLS-RPT?
How much report volume should I expect?
Can TLS-RPT reports contain message content?
Does TLS-RPT cover DANE too?
TLS-RPT is a one-record deployment that turns invisible transport failures into a daily data feed. Publish the record today, wire the reports into the same pipeline as your DMARC aggregates, and let two quiet weeks of data walk your MTA-STS policy into enforce mode.
Key Takeaways
- TLS-RPT is one TXT record; reports arrive daily as gzipped JSON from participating senders
- Reports classify failures: STARTTLS not offered, certificate errors, and policy fetch or validation problems
- Google and Microsoft both send TLS-RPT reports, covering the bulk of real-world inbound attempts
- A quiet report stream is the green light for MTA-STS enforce mode; failure spikes are your rollback trigger
- Success counts matter too: they tell you what fraction of sessions would have survived enforcement
Related articles
Greylisting, Tarpitting, and Other Receiver Defenses Senders Should Understand
Receiving servers defend themselves with deliberate delays, temporary rejections, and traps for impatient senders. How each defense works and how a good MTA passes them.
Building a Deliverability Monitoring Stack
Postmaster Tools, SNDS, FBLs, DMARC reports, TLS-RPT, bounce logs, engagement data: the full observability stack, what each layer catches, and the alerts worth paging on.
Email Address Internationalization: SMTPUTF8 and EAI in Practice
Addresses like 佐藤@例え.jp are valid email. How EAI and SMTPUTF8 work, who supports them, and what sending systems break when a Unicode address shows up.