TLS-RPT

TLS-RPT (TLS Reporting, RFC 8460) is the companion to MTA-STS. It tells sending mail servers: "If you tried to deliver to my domain and a TLS error occurred, send me a report at this address."

Without TLS-RPT you'd have no way to know that someone tried to mail you, hit a TLS failure, and gave up. The reports are how you catch problems before they become mail-loss outages.

How to publish it

One DNS TXT record:

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"

rua can be a mailto: or https:// endpoint. Major mail providers (Gmail, Microsoft 365) will start sending daily aggregate reports.

What the reports look like

A TLS-RPT report is a JSON blob like:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-13T00:00:00Z",
    "end-datetime": "2026-05-14T00:00:00Z"
  },
  "policies": [
    {
      "policy": { "policy-type": "sts", "policy-domain": "yourdomain.com" },
      "summary": { "total-successful-session-count": 1240, "total-failure-session-count": 3 },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "..."
        }
      ]
    }
  ]
}

How to actually use the data

Two paths:

1. Manual. Set up a dedicated inbox (tls-reports@yourdomain.com). Skim it weekly. Look for failure counts > 0.
2. SaaS report parsers. Tools like Postmark, dmarcian, Valimail, or URIports ingest TLS-RPT and surface trends. Worth it if you're past 1M outbound mails/month.

In an MTA-STS rollout

You publish TLS-RPT before MTA-STS. Run TLS-RPT alone for 2 weeks to baseline what TLS failures already happen. Then publish MTA-STS in testing mode for 2 more weeks. Check reports for new failures. Then flip to enforce. The reports are how you avoid breaking mail by going to enforce too aggressively.