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