What Is TLS-RPT and How to Set It Up

TLS-RPT (SMTP TLS Reporting, defined in RFC 8460) is a DNS-based standard that sends you reports when a mail server fails to encrypt a TLS connection while delivering email to your domain. You publish a single TXT record, and sending mail servers automatically send JSON reports to the address you specify whenever TLS negotiation fails — telling you which sender, which receiving server, and what error occurred.

If you've set up MTA-STS (which enforces TLS for inbound mail), TLS-RPT is its reporting companion. MTA-STS does the enforcing; TLS-RPT tells you when enforcement caused a delivery failure and why. Without it, encrypted messages that bounce disappear silently — you never know a sender couldn't reach you.

How TLS-RPT works

Every email delivered to your domain travels through one or more SMTP connections between mail servers. When a sending server connects to your MX server, it attempts a TLS handshake to encrypt the connection. If that handshake fails — expired certificate, unsupported TLS version, untrusted root, protocol downgrade — the message either bounces or falls back to unencrypted delivery.

TLS-RPT gives you visibility into those failures. Here's the flow:

1. A sending server tries to deliver mail to your domain. It connects to your MX server and attempts STARTTLS negotiation.
2. TLS fails or a policy is violated. The handshake errors out, or the sending server detects that your MTA-STS policy wasn't honored (e.g., the receiving server's certificate doesn't match).
3. The sending server generates a JSON report. The report includes the organization name, date range, total successful and failed session counts, and per-failure details (result type, sending MTA IP, receiving MX hostname, failure count).
4. The report is delivered to the address in your TLS-RPT record. This happens via email (as an attachment to a message sent to the rua address) or via HTTP POST to a URL you specify.

Reports are aggregated — you get one report per sender per day, covering all sessions in that 24-hour window, not one report per failed message.

The TLS-RPT DNS record

TLS-RPT uses a single TXT record published at _smtp._tls.yourdomain.com. The syntax:

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

Two components:

• v=TLSRPTv1 — The protocol version. Currently only version 1 exists (defined in RFC 8460).
• rua=mailto:tlsrpt@example.com — The reporting URI for aggregate data. This tells sending servers where to send failure reports. The rua field accepts mailto: addresses, https: URLs, or both (comma-separated).

Multiple reporting destinations

You can send reports to more than one destination — useful if you want a backup inbox or a processing service alongside your own address:

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

When using HTTPS, the sending server POSTs a gzipped JSON file to your endpoint. This is useful if you receive a high volume of reports and don't want them clogging an inbox.

Step-by-step setup

Step 1: Choose your reporting address

Pick an active inbox you or your IT team can monitor. A dedicated address like tlsrpt@example.com is cleaner than a personal inbox — these reports come from many different sending organizations, and a busy domain can receive dozens per day.

If you use a third-party email security platform (EasyDMARC, Valimail, PowerDMARC, etc.), they typically provide a reporting address in their domain. You'd publish that address in your rua field, and the platform parses and visualizes the reports for you.

Step 2: Publish the TXT record

Add the TXT record at _smtp._tls.yourdomain.com in your DNS provider's dashboard:

Important: The record goes at _smtp._tls.yourdomain.com — note the underscore prefix on _smtp. This is the hostname sending servers look up; without the underscore prefix, the record won't be found.

Step 3: Verify the record published

After DNS propagates (usually minutes), verify with a DNS lookup:

dig TXT _smtp._tls.example.com +short

You should see your record returned. If you see nothing, check that the underscore prefix is correct and that your DNS provider didn't append your domain name automatically (some providers do this for TXT records, which would create _smtp._tls.example.com.example.com).

Step 4: Set up MTA-STS (if you haven't)

TLS-RPT reports TLS failures whether or not you have MTA-STS. But the two are designed to work together — MTA-STS enforces encryption, and TLS-RPT tells you what breaks when enforcement kicks in. If you haven't set up MTA-STS yet, do it alongside TLS-RPT. See our MTA-STS setup guide for the full walkthrough.

Start MTA-STS in testing mode, publish your TLS-RPT record, and monitor the reports for a week before switching to enforce. This gives you a safety net: you'll see exactly which senders would fail under enforcement before any messages actually bounce.

Understanding TLS-RPT reports

Reports arrive as JSON files, usually gzipped and attached to an email sent to your rua address. The structure (per RFC 8460 §4):

{
  "organization-name": "Company-X",
  "date-range": {
    "start-datetime": "2026-09-09T00:00:00Z",
    "end-datetime": "2026-09-09T23:59:59Z"
  },
  "contact-info": "sts-reporting@company-x.example",
  "report-id": "5065427c-23d3-47ca-b6e0-946ea0e8c4be",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: testing",
                        "mx: *.mail.example.com", "max_age: 86400"],
      "policy-domain": "example.com",
      "mx-host": "*.mail.example.com"
    },
    "summary": {
      "total-successful-session-count": 5326,
      "total-failure-session-count": 303
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "2001:db8:abcd:0012::1",
      "receiving-mx-hostname": "mx1.mail.example.com",
      "failed-session-count": 100
    }, {
      "result-type": "starttls-not-supported",
      "sending-mta-ip": "203.0.113.56",
      "receiving-mx-hostname": "mx2.mail.example.com",
      "failed-session-count": 200
    }]
  }]
}

What each section means

• organization-name — The sending organization (the one reporting the failure, not your domain).
• date-range — The 24-hour window this report covers. Reports are daily.
• summary — Total successful and failed TLS sessions for the period. A healthy domain shows thousands of successes and zero or single-digit failures.
• failure-details — The actionable part. Each entry has a result-type (what went wrong), the sending server's IP, the receiving MX hostname, and how many sessions failed.

Common failure types

Does TLS-RPT help deliverability?

TLS-RPT doesn't directly influence spam filter scoring — it's a reporting protocol, not an authentication record like SPF or DKIM. But it matters for inbox placement in two practical ways:

1. Catches silent delivery failures. When TLS encryption fails on an inbound message, the email bounces with a permanent error — and the sender may not always notify you. TLS-RPT reports tell you which senders couldn't deliver to you and why, so you can fix the issue (expired cert, wrong MX config) before it causes missed messages or delayed responses.

2. Completes the transport-security stack. Gmail, Outlook, and Yahoo increasingly expect senders and receivers to support encrypted transport. A domain with SPF, DKIM, DMARC, MTA-STS, and TLS-RPT sends a clear signal that it's professionally maintained. Missing TLS-RPT doesn't penalize you, but having it means you'll know about transport failures before they become deliverability problems.

TLS-RPT vs. DMARC reports

Both are reporting protocols that use rua addresses and DNS TXT records, but they report on different things:

You need both. DMARC reports tell you about spoofing and authentication gaps. TLS-RPT reports tell you about encryption failures. They cover different layers of the email delivery stack.

Common TLS-RPT mistakes

• Wrong record location. The record goes at _smtp._tls (with underscores), not smtp.tls or _tls. A missing underscore means senders won't find the record and won't send reports.
• Publishing TLS-RPT without MTA-STS. You'll still get reports, but you won't know which failures are caused by your enforcement policy vs. opportunistic TLS issues. Set up both together.
• Ignoring the reports. Publishing the record is the easy part. If nobody reads the JSON reports, you've gained nothing. Use a monitoring tool or check the inbox weekly.
• Using a rua address on a different domain without permission. If you point rua at an address on someone else's domain (e.g., a vendor's reporting service), the receiving domain may reject the reports if the destination domain doesn't publish a verification record. This is similar to DMARC's external reporting verification. If you're using a third-party service, they'll handle this for you.

Check your grade free

Don't guess what's broken — see it. Scan your domain free at emailsecuritygrade.com and get an instant A–F grade on your SPF, DKIM, DMARC, and MX records, with a plain-language fix for anything failing. No signup, no install — it runs in your browser.

If your emails are still landing in spam after fixing the records, a deliverability tool like InboxAlly can train mailbox providers to trust your sending — worth a look once your grade is solid.