What does a TLS-RPT report tell me?

A daily report from a receiving server about all TLS attempts to your mail server: number of successful and failed sessions, plus the cause per failure (cert expiry, cipher mismatch, policy fetch error, etc.).

Which failure codes should I know?

The most common: starttls-not-supported, certificate-expired, certificate-not-trusted, certificate-host-mismatch, sts-policy-fetch-error, sts-policy-invalid. Each points directly to a concrete configuration gap.

Do I need MTA-STS for TLS-RPT?

TLS-RPT only makes sense alongside an active MTA-STS — otherwise recipients have no target state to compare failures against. The two belong together as a pair.

What about data protection for TLS-RPT reports?

Reports contain no mail content, no recipient addresses — only statistical TLS aggregate data and IPs. The GDPR-relevant element is essentially the sender server IP.

How long does daily analysis take?

With active MTA-STS in mode=enforce and a clean configuration: 5 minutes to skim. With problems or in the testing phase: 20–30 minutes for targeted investigation. Mailantis aggregates the reports and reduces this to one click.

Understanding TLS-RPT — reading failure reports properly

The problem: TLS errors otherwise stay invisible

By default, SMTP tries to set up a TLS connection between the sending and receiving mail server. If that fails — expired certificate, weak ciphers, downgrade attack — the server usually falls back to an unencrypted connection. The mail arrives, but in plain text. You would never find out.

TLS-RPT (TLS Reporting, RFC 8460) solves this. You explicitly ask receiving servers in a DNS record to report such incidents to you. Reports arrive daily as JSON files via email — directly actionable, or aggregated by Mailantis.

The DNS record

TLS-RPT is enabled via a TXT record at the subdomain _smtp._tls. Example:

_smtp._tls.example.com · TXTv=TLSRPTv1; rua=mailto:[email protected]

The key fields:

v=TLSRPTv1 — version identifier, always this.
rua=mailto: — the email address reports are sent to. Multiple addresses are allowed, comma-separated.
rua=https:// — alternatively an HTTPS endpoint that accepts reports via POST (rarely used).

If you use Mailantis, you receive a dedicated rua address that you simply forward reports to — we aggregate the JSON files into readable overviews.

The JSON structure

A TLS-RPT report is a JSON file, packaged as application/tlsrpt+gzip. Unpacked, a typical report looks like this:

Example report{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-07T00:00:00Z",
    "end-datetime":   "2026-05-07T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "2026-05-07T00:00:00Z_example.com",
  "policies": [
    {
      "policy": {
        "policy-type":   "sts",
        "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 86400"],
        "policy-domain": "example.com",
        "mx-host":       ["mail.example.com"]
      },
      "summary": {
        "total-successful-session-count": 1842,
        "total-failure-session-count":      3
      },
      "failure-details": [
        {
          "result-type":            "certificate-expired",
          "sending-mta-ip":         "74.125.24.27",
          "receiving-mx-hostname":  "mail.example.com",
          "failed-session-count":   3
        }
      ]
    }
  ]
}

The key pieces of information:

organization-name — who is sending the report (e.g. Google, Microsoft, Yahoo).
summary — count of successful and failed TLS sessions in the time window.
failure-details — when failures occurred, the cause per incident.

The key failure codes

RFC 8460 defines a fixed list of result-type values. The most common ones:

starttls-not-supported — the receiving server offers no STARTTLS. Your mail is delivered in plain text.
certificate-expired — the recipient's TLS certificate has expired.
certificate-not-trusted — the certificate is not signed by a trusted CA (self-signed or similar).
certificate-host-mismatch — the certificate does not match the expected hostname.
validation-failure — generic validation error (e.g. ciphers too weak).
sts-policy-fetch-error — the MTA-STS policy could not be loaded.
sts-policy-invalid — the loaded policy is syntactically broken.
sts-webpki-invalid — the policy URL presents an invalid TLS certificate.

Important: TLS-RPT only makes sense alongside an active MTA-STS. Without an MTA-STS policy, recipients have no target state to compare failures against.

How to analyse reports

Three analysis patterns that are almost always relevant in practice:

Daily trend — do failures stay consistently low, or are there sudden spikes? Spikes indicate newly emerging problems (cert expiry, wrong MX configuration).
Distribution across recipients — do failures come from a single recipient or across the board? A single recipient = a configuration problem there, broadly distributed = a problem of your own (policy or MX).
result-type clustering — if 80% of failures are certificate-expired, you know immediately where to look.

Practical recommendations

Always activate TLS-RPT alongside MTA-STS — the two complement each other.
During the MTA-STS testing phase, TLS-RPT is particularly valuable: you see problems without losing mail.
Do not collect reports in a normal mailbox — the JSON files are not meant for human eyes. An aggregation tool (Mailantis) or your own parsing script is mandatory.
After three weeks of reports without failures: switch MTA-STS to enforce with confidence.

Understanding TLS-RPT: reading failure reports properly