TLS-RPT setup: publish the record, read the reports, fix the errors

What TLS-RPT is and why you want it

TLS-RPT stands for SMTP TLS Reporting and is defined in RFC 8460. Your domain publishes an address in DNS, and sending mail servers deliver reports about their TLS connections to your MX hosts there. Each report covers one day and states how many sessions were encrypted successfully, how many failed and why.

TLS-RPT is the feedback channel for MTA-STS and DANE. Both let your domain require TLS for inbound mail. If a sender cannot fetch the policy or the certificate does not match the MX host, it refuses to deliver in enforce mode. Without TLS-RPT you only hear about it when someone complains. With TLS-RPT it is in the next morning's report.

TLS-RPT itself does not change delivery. The record enforces nothing and blocks nothing, so it is safe to publish first, before MTA-STS or DANE are in place.

The TLS-RPT record

The record is a TXT record at the hostname _smtp._tls below your domain. It carries the version tag v=TLSRPTv1 and at least one rua destination. A destination is either a mail address (mailto:) or an HTTPS endpoint; several destinations are separated by commas.

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

_smtp._tls.example.com.  IN TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsrpt.example.com/report"

By mail, the report arrives as a gzip attachment of type application/tlsrpt+gzip; an HTTPS endpoint receives it as a POST of type application/tlsrpt+json. The mail address may live in a different domain, for example at a reporting service or your agency; unlike DMARC, no authorisation record is needed there. A domain may have only one TLS-RPT record; if senders find two, they ignore both.

Setting up TLS-RPT step by step

The setup takes a few minutes. The real work is reading the reports later.

1. Pick a destination: create a mailbox such as tlsrpt@example.com or use a reporting service; many DMARC services accept TLS reports too.
2. Create the TXT record: at your DNS host, add a TXT record named _smtp._tls (some interfaces want _smtp._tls.example.com. with a trailing dot) with the value v=TLSRPTv1; rua=mailto:tlsrpt@example.com.
3. Verify the record: run dig TXT _smtp._tls.example.com or use the DomainWarn TLS-RPT Checker, which validates the syntax and the rua destinations and tells you whether the domain has an MTA-STS policy.
4. Wait: the first reports arrive the next day at the earliest, because senders generate them once a day for the previous day.
5. Review: look at reports with failures before you switch MTA-STS to enforce.

Fixing "TLS-RPT record not found"

If a checker reports TLS-RPT record not found although you published it, the name is almost always wrong. The usual causes:

• Wrong hostname: the record sits at _tls, _smtp or the domain apex instead of _smtp._tls. Both labels are required, in that order.
• Missing underscore: some DNS interfaces strip or reject underscores. If the host quietly turns the name into smtp.tls, the record is useless.
• Record in the wrong zone: typing the full name into a field that appends the domain automatically produces _smtp._tls.example.com.example.com. Check the full name dig returns.
• TTL and propagation: a new record can take up to an hour to reach every resolver, longer if the previous TTL was high. Query an authoritative nameserver directly to rule out caching.
• Typos in the value: TLSRPTv1 with a lowercase v, the semicolon between the fields, and rua= followed by mailto:. Without the mailto: prefix the record is invalid.

dig +short TXT _smtp._tls.example.com
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

dig +short TXT _smtp._tls.example.com @ns1.dns-host.example

Reading the reports

A TLS-RPT report is a JSON file. The header holds the reporting provider (organization-name), the period (date-range) and a report-id. Below that, the policies array holds one entry per policy the sender applied to your domain, each with a summary and an optional list of failures.

policy-type tells you which rule the sender found: sts for an MTA-STS policy, tlsa for DANE, and no-policy-found when neither existed. The numbers in summary matter most: total-successful-session-count is the number of successfully encrypted connections, total-failure-session-count the number that failed.

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-09-11T00:00:00Z",
    "end-datetime": "2026-09-11T23:59:59Z"
  },
  "report-id": "2026-09-11T00:00:00Z_example.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: testing",
          "mx: mail1.example.com",
          "mx: mail2.example.com",
          "max_age: 86400"
        ],
        "policy-domain": "example.com"
      },
      "summary": {
        "total-successful-session-count": 1284,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "209.85.220.41",
          "receiving-mx-hostname": "mail2.example.com",
          "receiving-ip": "203.0.113.25",
          "failed-session-count": 3
        }
      ]
    }
  ]
}

This report says: on 11 September 2026 Google found an MTA-STS policy in testing mode for example.com, encrypted 1284 sessions and counted 3 sessions to mail2.example.com as failures due to an expired certificate. In testing mode those messages were still delivered; in enforce mode they would have been held back.

The result-type values that matter

Every entry in failure-details carries a result-type, the IP of the sending server, the affected MX host and a failed-session-count. The result-type tells you where to look.

• starttls-not-supported: the MX host did not offer STARTTLS. Often a backup MX or a firewall that strips the offer.
• certificate-expired: the MX host's certificate has expired. Renew it and check that automatic renewal actually runs.
• certificate-host-mismatch: the certificate is not valid for the hostname in the MX record or the policy. Typical after a hostname change.
• certificate-not-trusted: the chain is incomplete or the CA is unknown. Usually the intermediate certificate is missing on the server.
• validation-failure: catch-all for other TLS errors, such as a protocol version the sender no longer accepts.
• sts-policy-fetch-error: the MTA-STS policy could not be fetched from mta-sts.example.com. The web host was down, answered with a redirect or presented the wrong certificate.
• tlsa-invalid and dnssec-invalid: failures on the DANE side. The TLSA record does not match the certificate or the DNSSEC chain is broken.

A single failure among thousands of sessions is usually a transient network problem. It is worth investigating when the same result-type shows up every day on the same MX host.

Microsoft 365 and Google Workspace

Microsoft 365 and Exchange Online: Exchange Online sends TLS-RPT reports for mail it delivers to external domains. There is no switch for it in the Microsoft 365 admin center; you publish the record at the DNS host of the domain, or at Microsoft only if the DNS zone lives there. An Exchange Online mailbox works as the destination, but make sure attachments of type application/tlsrpt+gzip are not blocked by an attachment rule.

Google Workspace: Google has been sending TLS reports to every domain with a TLS-RPT record for years, so it is usually the first sender you hear from. Its MX hosts carry valid certificates, so failure reports for a Workspace domain almost always point back to your own MTA-STS policy, for example an mx line that no longer matches after the move from aspmx.l.google.com to smtp.google.com. Google does not analyse the reports you receive.

Who needs the reports and what goes wrong in practice

TLS-RPT pays off mainly when your domain uses MTA-STS or DANE, or plans to. Then the reports are your only source for whether senders read the policy and whether deliveries fail on encryption. Without them, the reports only tell you whether opportunistic STARTTLS to your MX hosts works: useful for catching an expired certificate, but not urgent.

The typical mistakes in day-to-day operation:

• Nobody reads the mailbox. A reporting service that alerts on failures is the better choice.
• The rua address sits on the very MX host that is broken. An address in another domain or an HTTPS endpoint avoids that.
• The record was forgotten during a DNS migration. Underscore records tend to fall through the cracks when a zone is copied by hand.

Frequently asked questions

Do I need TLS-RPT without MTA-STS?

Not strictly. Without MTA-STS or DANE the reports only tell you whether opportunistic STARTTLS to your MX hosts works. Once you plan MTA-STS, publish the TLS-RPT record first so you already have data in testing mode.

Why am I not getting reports although the record is published?

Reports only come from senders that support TLS-RPT, and only if they sent mail to your domain the previous day. With little inbound mail, days can pass. If the syntax is correct and the domain gets mail from Google or Microsoft, expect reports within one or two days.

Can I send the reports to an address in a different domain?

Yes. Unlike DMARC, TLS-RPT does not require the destination domain to authorise it. You can put rua=mailto:tlsrpt@agency.example on every client domain and collect the reports centrally.