What Is TLS-RPT? SMTP TLS Reporting Explained

Enforcing TLS on inbound email is powerful, but it introduces a risk: if something is misconfigured, mail can silently fail. TLS-RPT — SMTP TLS Reporting — is the feedback channel that removes the blindfold. It asks sending servers to send you a daily summary of how TLS negotiation went, so you can catch problems before they cost you email.

What Is TLS-RPT?

TLS-RPT (defined in RFC 8460) is a standard that lets a domain publish an address where receiving reports about SMTP TLS should be sent. Participating sending servers aggregate what they saw when delivering mail to your domain — successful TLS sessions, certificate mismatches, expired certificates, STARTTLS failures, and MTA-STS policy problems — and send you a structured JSON report once per day.

It is the essential companion to MTA-STS and DANE. Those standards enforce TLS; TLS-RPT tells you what that enforcement is actually doing in the wild.

Why TLS-RPT Matters

Without reporting, a TLS enforcement failure is invisible to you — the sending server either quietly delivered (in testing mode) or refused delivery (in enforce mode), and you find out only when someone complains that their email never arrived. TLS-RPT surfaces:

Certificates that are expired, self-signed, or do not match the MX hostname.
MX hosts that stopped offering STARTTLS.
MTA-STS policy fetch or parse failures.
An attacker attempting to strip or downgrade TLS on your inbound mail.

This is exactly why you deploy MTA-STS in testing mode first: TLS-RPT reports let you confirm every legitimate mail path negotiates TLS correctly before you switch to enforce.

The TLS-RPT DNS Record

TLS-RPT is a single TXT record published at _smtp._tls.yourdomain.com. It is independent of MX or MTA-STS records.

text

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

Record Tags Explained

Tag	Required?	Description
`v=TLSRPTv1`	Yes	Version identifier — always `TLSRPTv1`.
`rua=`	Yes	Where reports are sent. A `mailto:` address, or an `https://` endpoint that accepts report uploads. Multiple destinations are separated by commas.

Email or HTTPS deliveryThe rua destination can be a mailbox (mailto:tlsrpt@example.com) or an HTTPS collector (https://reports.example.com/tls). Most teams start with a mailbox and later route it into a reporting service that parses the JSON for them.

What a Report Contains

Reports are sent once per day as JSON (typically gzip-compressed) and cover a 24-hour window. Each report groups results by policy and MX host, with a count of successful and failed sessions plus a failure breakdown.

json

{
  "organization-name": "Sending Provider Inc.",
  "date-range": { "start-datetime": "2026-07-06T00:00:00Z",
                  "end-datetime":   "2026-07-06T23:59:59Z" },
  "contact-info": "postmaster@sending-provider.example",
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "example.com" },
    "summary": { "total-successful-session-count": 4821,
                 "total-failure-session-count": 3 },
    "failure-details": [{
      "result-type": "certificate-expired",
      "receiving-mx-hostname": "mx2.example.com",
      "failed-session-count": 3
    }]
  }]
}

Common result-type values include certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure, and sts-policy-fetch-error. A sudden spike in failures is a strong early warning of a certificate renewal that went wrong — or a downgrade attempt.

How TLS-RPT Fits with MTA-STS

MTA-STS and TLS-RPT are almost always deployed together:

MTA-STS defines the enforcement policy (require TLS, valid certificate, matching MX host).
TLS-RPT gives you the observability to run that policy safely — you watch the reports during testing, fix anything that fails, then move to enforce with confidence.

You can generate the _smtp._tls record alongside your policy with the MTA-STS & TLS-RPT Generator, and confirm it is published with the MTA-STS Checker.

TLS-RPT is not just for MTA-STSEven if you use DANE (or no enforcement at all), publishing a TLS-RPT record is worthwhile — it gives you visibility into the TLS health of your inbound mail from every participating sender.

Frequently Asked Questions

Does TLS-RPT block any email?

No. TLS-RPT is purely a reporting mechanism — it never affects delivery. Enforcement is the job of MTA-STS or DANE. TLS-RPT only tells you what happened.

How often will I receive reports?

Participating senders send at most one aggregate report per day per policy. Volume depends on how many providers send you mail and support TLS-RPT; large providers like Google and Microsoft do.

Do I need MTA-STS to use TLS-RPT?

No. The two are independent records. You can publish a TLS-RPT record on its own to gain visibility, though its greatest value is confirming an MTA-STS or DANE deployment is healthy.

How do I check my TLS-RPT record?

Use the ShowDNS MTA-STS Checker, which validates the _smtp._tls record alongside your MTA-STS policy, or run dig _smtp._tls.yourdomain.com TXT +short.