TLS-RPT Explained: Should You Enable SMTP TLS Reporting?
The short answer
TLS-RPT (SMTP TLS Reporting, RFC 8460) is a DNS TXT record at _smtp._tls that asks other mail servers to send you daily JSON reports on whether their encrypted connections to your domain succeeded or failed. It is worth enabling: it is one low-cost record, it reveals TLS misconfigurations and rare interception attempts, and it pairs with MTA-STS or DANE.
What is TLS-RPT, and should you enable it? How SMTP TLS Reporting works, what a failure report means, and how to add the _smtp._tls record.
On this page
TLS-RPT, short for SMTP TLS Reporting, answers a narrow question: are other mail servers actually encrypting the mail they send to your domain, and if not, why? This guide covers what TLS-RPT is, how the _smtp._tls record works, what a failure report really tells you, and whether you should enable it on a sending domain. The short answer up front: for most domains, yes — it is one DNS record and it costs nothing to run.
The standard is RFC 8460, published in September 2018. It defines a feedback channel, not an enforcement mechanism. TLS-RPT does not encrypt anything and does not block anything — it collects reports from the servers that send you mail, so you can see whether their connections were secured and catch the misconfigurations that silently drop encryption.
What is TLS-RPT?#
TLS-RPT is a reporting standard for email transport encryption. When one mail server delivers to another over SMTP, it can upgrade the connection to TLS using STARTTLS. That upgrade is normally opportunistic: if it fails, most servers fall back to sending in plaintext rather than not delivering at all. The fallback is invisible to you — the mail arrives, and you never learn it crossed the internet unencrypted.
TLS-RPT closes that visibility gap. By publishing a _smtp._tls TXT record, you ask sending servers to aggregate their TLS results with your domain over each day and mail or POST them back to you as a JSON report. You find out how many sessions were encrypted, how many failed, and which failure occurred.
TLS-RPT reports; MTA-STS enforces
How TLS-RPT works#
You enable TLS-RPT with a single TXT record under the _smtp._tls subdomain of your domain — what the standard calls the Policy Domain. The value declares the TLS-RPT version and one or more destinations where reports should be sent.
What the record and the reports contain#
The rua tag lists where reports go. Two schemes are allowed: mailto: for an email address, and https: for a URL that accepts a POST. You can list several destinations separated by commas. A report sent by mail is DKIM-signed by the reporting organization; a report sent over HTTPS uses the media type application/tlsrpt+gzip.
Each report covers a full UTC day, from 00:00 to 24:00, and usually arrives a few hours after the day closes. The body is JSON in I-JSON form (RFC 7493), normally gzip-compressed. It names the reporting organization, the date range, and one or more policy blocks — each with a count of successful and failed sessions, and the details of any failures.
What a TLS-RPT report actually tells you#
Most of a report is good news: a running count of sessions that negotiated TLS cleanly. The value is in the failure details. Each failure carries a result-type that names exactly what went wrong, the sending server's IP, and the receiving MX host it was trying to reach. RFC 8460 defines a fixed set of result types, split between problems negotiating TLS at all and problems specific to an MTA-STS or DANE policy.
| Result type | What it means | Usually caused by |
|---|---|---|
| starttls-not-supported | The receiving server offered no STARTTLS, so the session could not be encrypted | A misconfigured or downgraded MX — or, rarely, an on-path attacker stripping STARTTLS |
| certificate-expired | The receiving MX presented an expired TLS certificate | A lapsed certificate renewal on your inbound mail server |
| certificate-host-mismatch | The certificate did not match the MX hostname | A certificate that omits the MX name, or a wrong MX-to-certificate pairing |
| certificate-not-trusted | The certificate chain did not validate to a trusted root | A self-signed certificate or an incomplete chain on the receiving MX |
| validation-failure | TLS negotiation failed for another reason, such as no common protocol or cipher | An outdated or misconfigured TLS stack on the receiving server |
| sts-policy-fetch-error / sts-policy-invalid | The sender could not fetch or could not parse your MTA-STS policy | A broken MTA-STS policy file or an unreachable policy host |
| tlsa-invalid / dnssec-invalid | A DANE TLSA record failed to match, or DNSSEC validation failed | A stale TLSA record after a certificate rotation, or a DNSSEC signing problem |
Why it matters, and what you miss without it#
Without TLS-RPT you have no view of transport encryption on inbound mail. STARTTLS failures are silent: the message still gets delivered, so nothing alerts you that it traveled in plaintext. An expired certificate on your MX, a downgrade by a middlebox, and an active STARTTLS-stripping attack all look identical from your side, which is to say invisible.
- Certificate problems on your inbound servers, caught before they cause wider TLS failures.
- Senders who cannot encrypt to you, and whether the cause sits on their side or yours.
- Broken MTA-STS or DANE policies that are quietly failing validation for real senders.
- Rare but real interception: a sudden run of starttls-not-supported from senders who normally encrypt can point to an on-path downgrade.
Usually a misconfiguration, occasionally an attack
TLS-RPT vs MTA-STS: how they differ#
TLS-RPT is often confused with MTA-STS because they are deployed together and both hang off a policy domain. They do opposite jobs. MTA-STS is the policy that changes sender behaviour; TLS-RPT is the reporting channel that observes the result and never touches delivery.
| Dimension | MTA-STS (RFC 8461) | TLS-RPT (RFC 8460) |
|---|---|---|
| Job | Enforces TLS — tells senders to require encryption and not fall back | Reports — collects daily stats on TLS successes and failures |
| DNS footprint | A _mta-sts TXT record plus an HTTPS-hosted policy file | A single _smtp._tls TXT record |
| Effect on delivery | Can defer mail when TLS cannot be established | None — reporting only, it never blocks a message |
| What you get back | Nothing directly | JSON reports from participating senders |
| Run alone? | Yes, but you stay blind to failures without TLS-RPT | Yes, but it is far more useful paired with a policy |
Common misconceptions#
TLS-RPT is small enough to be misread in a few predictable ways. Clearing these up is most of what decides whether it is worth your time.
- "It encrypts my mail." No. TLS-RPT reports; it changes nothing about how mail is sent. STARTTLS does the encrypting, and MTA-STS or DANE decides whether to require it.
- "I need MTA-STS first, or it does nothing." No. TLS-RPT is independent. Without a policy you still receive reports — sessions simply show a policy-type of no-policy-found and you lose the policy-specific signal.
- "A failure means someone is intercepting my mail." Usually not. Most failures are your own certificate or configuration.
- "Turning it on could break delivery." It cannot. TLS-RPT never affects whether a message is delivered; only MTA-STS or DANE can defer mail.
- "I will drown in reports." Only senders that support TLS-RPT send them, at most one per day per reporting organization. The volume is low, and it comes mostly from the large providers.
Where TLS-RPT fits with AI Emaily, and where it doesn't#
TLS-RPT lives at the DNS and mail-server layer, and reading its reports is the job of a DMARC or TLS-RPT monitoring platform, not a mail client. AI Emaily does not publish your _smtp._tls record, collect TLS-RPT reports, or parse them. If that is your task, point your rua at a dedicated reporting service or your own endpoint — we are not a deliverability tester or a DMARC monitor, and we will not pretend to be.
The adjacent thing we do care about is encryption on your side of the mailbox, which is what TLS-RPT is ultimately measuring on the wire. AI Emaily connects to your Gmail, Outlook or IMAP account over TLS, keeps stored message bodies in encrypted object storage, and envelope-encrypts sensitive credentials so they are never logged in the clear — the details are on our encryption page. And because transport TLS is really about trusting the sender, AI Emaily reads inbound authentication results to flag spoofed and phishing mail in the inbox you actually read. We build AI Emaily; it runs on a 7-day free trial on the Pro and Autopilot plans, you can compare plans on the pricing page, and the homepage has the full picture.
Frequently asked
See it in AI Emaily
Keep reading
Sources
Written by
Nafiul HasanNafiul Hasan is an entrepreneur and AI automation system builder with 10+ years of experience turning messy, manual workflows into reliable automated systems. He designs and ships AI enterprise solutions end-to-end — the agent logic, the data plumbing, and the product people actually use — and founded AI Emaily to give busy professionals their attention back. He writes here from the builder's seat: what works, what breaks, and how to put AI to work without giving up control.