TLS-RPT explained: reporting for email transport security

TLS-RPT (SMTP TLS Reporting, RFC 8460) is the feedback channel for email transport security. A domain publishes one DNS record naming a reporting address, and participating senders, including Gmail and Microsoft, respond with a daily JSON summary of every TLS negotiation problem they encountered delivering to that domain. Without it, transport encryption fails silently: the sender falls back or defers, and the receiving domain learns nothing. With it, an expired MX certificate or an active downgrade attack shows up in tomorrow's report.

Enabling reports: one record

Reports begin arriving within a day or two, one per participating sender per day, as email with a gzipped JSON attachment. Volume is light, a handful of messages daily, which makes TLS-RPT far easier to consume than DMARC aggregates. One practical caution: if your domain's inbound TLS breaks badly enough, reports about the problem may not be deliverable to the same domain, so receiving them at an address on separate infrastructure keeps the alarm independent of the thing on fire.

Reading a report

1{
2  "organization-name": "Google Inc.",
3  "date-range": {
4    "start-datetime": "2026-07-13T00:00:00Z",
5    "end-datetime": "2026-07-13T23: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: a backup MX with an expired certificate, invisible under opportunistic TLS because senders fell back or retried the primary, and fatal on the day an MTA-STS policy moves to enforce. Thirty-seven failed sessions in a report is a calendar reminder someone missed, caught for free.

The failure vocabulary, in three families

Negotiation failures (starttls-not-supported, validation failures during the handshake) point at broken MX hosts, interfering middleboxes, 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 the MX fleet and account for most real 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 malformed, or its certificate lapsed. Each family has a natural owner, which is what makes the reports operational: certificates page the MX operators, policy errors page whoever owns the mta-sts host, negotiation anomalies from a single origin are a security question.

Operating on the data

Limits worth knowing

Only senders implementing RFC 8460 report, which in practice means the large providers plus security-conscious operators; small MTAs still fail silently. The reports describe sessions, not messages, and say nothing about mail never attempted. None of that reduces the value: Gmail and Microsoft attempt delivery to almost every domain daily, making their reports a free, continuous, external probe of your TLS posture from the vantage points that matter most, and the natural companion to the MTA-STS policy they keep honest.