TLS-RPT: get told when inbound TLS fails

If a sending server fails to establish TLS with your mail servers, you would normally never know. The sender either falls back to plain text or gives up quietly, and nothing tells you.

SMTP TLS Reporting, defined in RFC 8460, fixes that by asking senders to mail you a daily summary of how their TLS connections to your domain went.

What TLS-RPT is for#

TLS-RPT is a reporting companion to the policies that make SMTP encryption strict: MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672). Both of those tell senders to refuse insecure delivery. When something goes wrong, such as an expired certificate, an MX host missing from your policy, or an attacker interfering with the connection, mail gets deferred. TLS-RPT is how you find out.

It is also useful on its own, without MTA-STS or DANE. Senders that support TLS-RPT will report on their connections to you even if you publish no strict policy, which gives you visibility into whether inbound mail is reaching you encrypted.

Publishing the record#

TLS-RPT uses a single TXT record at _smtp._tls under your domain:

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected]"

• v=TLSRPTv1 identifies the record.
• rua lists where reports should go. It accepts mailto: addresses and https: URLs, separated by commas.

_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.com/tlsrpt"

An HTTPS endpoint receives reports as POST requests. A mailbox is simpler to start with.

There is no authorization step equivalent to DMARC's external destination check, so you can send reports to an address at another domain, such as a reporting service, without extra DNS records on their side.

When reports arrive#

Senders that support TLS-RPT typically aggregate results over a 24-hour period and send one report per day per recipient domain. Reports sent by email arrive as attachments, usually gzip-compressed JSON with a .json.gz extension. The emails themselves have a specific content type so they can be filtered automatically.

Only senders that implement TLS-RPT will report, and not every mail operator does. Large mailbox providers are the most common reporters, which is useful because they also carry most of the traffic.

Anatomy of a report#

A report is a JSON document. Here is a trimmed example:

{
  "organization-name": "Receiver Example",
  "date-range": {
    "start-datetime": "2026-09-30T00:00:00Z",
    "end-datetime": "2026-09-30T23:59:59Z"
  },
  "report-id": "2026-09-30T00:00:00Z_example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mx1.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 5230,
      "total-failure-session-count": 4
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "203.0.113.17",
      "receiving-mx-hostname": "mx2.example.com",
      "failed-session-count": 4
    }]
  }]
}

The fields that matter#

• organization-name and date-range: who is reporting and for which day.
• policy-type: sts for MTA-STS, tlsa for DANE, or no-policy-found when you publish neither.
• policy-string: the policy the sender actually applied. Comparing it with what you think you published catches stale caches.
• summary: counts of successful and failed TLS sessions.
• failure-details: one entry per distinct failure, with a result type, the MX host involved and a count.

import gzip, json, sys

for path in sys.argv[1:]:
    r = json.load(gzip.open(path))
    for p in r["policies"]:
        s = p["summary"]
        print(r["organization-name"], p["policy"]["policy-type"],
              "ok", s["total-successful-session-count"],
              "fail", s["total-failure-session-count"])
        for f in p.get("failure-details", []):
            print("   ", f["result-type"], f.get("receiving-mx-hostname"), f["failed-session-count"])