What Is TLS-RPT? Email TLS Reporting Explained Simply
The short answer
TLS-RPT (SMTP TLS Reporting, RFC 8460) is a published DNS TXT record at _smtp._tls that invites other mail servers to send your domain daily JSON reports. Those reports tell you one thing: how many of the servers delivering mail to you managed to encrypt the connection with TLS, and, for the ones that failed, exactly why.
What is TLS-RPT? A plain-English guide to SMTP TLS Reporting, the _smtp._tls record, and what a TLS reporting report tells you about encrypted email.
On this page
If you have run into the term TLS-RPT, you are probably looking at a DNS setting, a deliverability checklist, or a security review and wondering what the acronym means. The short version: TLS-RPT, or SMTP TLS Reporting, is a way for your domain to ask the mail servers of the world to tell you whether they encrypted the messages they sent you. It is a reporting channel and nothing more — but that turns out to be useful information to have.
This is a definitional guide. It covers what TLS-RPT is, what the _smtp._tls record looks like, and what a TLS reporting report actually contains. The standard behind it is RFC 8460, published in September 2018. If your question is instead the deeper "should I turn it on, and how do I read the output every morning" — that is a separate walkthrough. This page is about understanding the concept first.
What is TLS-RPT?#
TLS-RPT stands for SMTP TLS Reporting. It is a standard, defined in RFC 8460, that lets the owner of a domain receive feedback about transport encryption on the mail arriving at that domain. When one mail server hands a message to another over SMTP, the two can upgrade the plain connection to an encrypted one using TLS. TLS-RPT is how you find out whether that upgrade actually happened.
The important word is reporting. TLS-RPT does not encrypt anything, and it does not block anything. It defines a feedback loop: participating sending servers keep a running tally of their TLS results with your domain and mail the summary back to you once a day. Everything TLS-RPT does is observational and after the fact.
TLS-RPT reports; it does not enforce
How TLS-RPT works: the _smtp._tls record#
You switch TLS-RPT on with a single DNS TXT record. It lives under the _smtp._tls subdomain of the domain you want reports for — what the standard calls the Policy Domain. The value is short: it declares the version and lists one or more addresses where reports should be sent.
The version is always v=TLSRPTv1. The rua tag holds the destination, or destinations, for the aggregate reports. Two schemes are allowed: mailto: for an email address, and https: for a URL that accepts a POST. You can list several, separated by commas. Unlike a DMARC record, TLS-RPT has no ruf tag — there is no separate stream of per-message forensic reports.
What a TLS reporting report contains#
Once the record is live, participating senders begin mailing you reports. Each one covers a full UTC day, from 00:00 to 24:00, and usually arrives a few hours after that day closes. The body is JSON in the I-JSON format (RFC 7493), normally gzip-compressed; when it is sent over HTTPS it carries the media type application/tlsrpt+gzip, and a mailed report is DKIM-signed by the reporting organization.
Most of the content is a simple count of sessions that encrypted cleanly. The part worth reading is the failures. RFC 8460 defines a fixed set of result-types, split into two families: problems negotiating TLS at all, and problems specific to a policy. Each failure record also names the sending server's IP and the receiving MX host it was trying to reach.
- Negotiation failures: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, and validation-failure — the general "a TLS negotiation failure email arrived" cases.
- MTA-STS policy failures: sts-policy-fetch-error, sts-policy-invalid, and sts-webpki-invalid.
- DANE policy failures: tlsa-invalid, dnssec-invalid, and dane-required.
Why TLS-RPT matters, and what you are blind to without it#
The reason TLS-RPT exists is that STARTTLS is usually opportunistic. If the encryption upgrade fails, most sending servers quietly fall back to delivering in plaintext rather than not delivering at all. The message still arrives, so nothing alerts you that it crossed the internet unencrypted. Without TLS-RPT, that failure is completely silent.
TLS-RPT turns that silence into a daily record. It is the diagnostic half of a TLS deployment — the part that lets you see whether the encryption you asked for is actually holding.
- Certificate problems on your own inbound servers, caught before they cause wider TLS failures.
- Senders who cannot encrypt to you, and whether the fault sits on their side or yours.
- A broken MTA-STS or DANE policy that is quietly failing validation for real mail.
- A rare but real downgrade: a sudden run of starttls-not-supported from senders who normally encrypt can point to on-path interference.
A failure is usually a misconfiguration, not an attack
TLS-RPT vs MTA-STS, DANE and DMARC#
TLS-RPT gets confused with three neighbours, because all four are DNS-based email standards and two of them even reuse the same rua tag name. The difference is what layer each one works on, and whether it reports or enforces.
| Standard | What it does | Where it lives in DNS | Reports or enforces? |
|---|---|---|---|
| TLS-RPT (RFC 8460) | Collects daily stats on whether senders encrypted their connections to you | A single _smtp._tls TXT record | Reports only — never affects delivery |
| MTA-STS (RFC 8461) | Tells senders to require TLS and refuse to fall back to plaintext | A _mta-sts TXT record plus a policy file fetched over HTTPS | Enforces — can defer mail that cannot be encrypted |
| DANE | Pins your server's certificate in DNS so senders can require verified TLS | TLSA records, secured with DNSSEC | Enforces — a DNSSEC-anchored alternative to MTA-STS |
| DMARC reporting | Reports whether mail claiming to be from you passed SPF and DKIM | A _dmarc TXT record, also with an rua tag | Reports only — but about authentication, not encryption |
Common misconceptions about TLS-RPT#
TLS-RPT is small enough that a few predictable misreadings do most of the damage. Clearing them up is most of what the concept requires.
- "It is a security control." It is a diagnostic. STARTTLS does the encrypting; MTA-STS or DANE decides whether encryption is required. TLS-RPT only observes the result.
- "Its rua is the same as DMARC's rua." Both tags name aggregate report destinations, but they collect different things — TLS-RPT collects encryption statistics, DMARC collects authentication results. And TLS-RPT has no ruf tag at all.
- "It tells me a specific message was intercepted." No. A report is an aggregate count over a whole UTC day, not a log of individual messages.
- "It only works if I have MTA-STS." No. TLS-RPT is independent. Without a policy in place you still get reports; the sessions simply show up as no-policy-found and you lose the policy-specific detail.
- "A TLS negotiation failure email means someone is attacking me." Usually not — it is far more often your own certificate or a sender's outdated TLS stack.
Where TLS-RPT fits with AI Emaily#
A fair question by now: does my email client do any of this? For TLS-RPT specifically, no, and it is worth being precise about why. Publishing the _smtp._tls record, collecting the daily reports, and parsing the JSON are jobs for whoever runs your domain's DNS plus a dedicated TLS-RPT or DMARC monitoring service. AI Emaily is a mail client — it sits on the reading side of the mailbox, not the postmaster side — so it does not set up your record or ingest your reports, and we are not going to imply otherwise.
What AI Emaily does care about is the same underlying goal TLS-RPT measures on the wire: keeping your mail confidential and its senders trustworthy. It connects to your Gmail, Outlook or IMAP account over TLS, stores message bodies in encrypted object storage, and keeps sensitive credentials envelope-encrypted rather than logged in the clear — the specifics are on our encryption page. Because transport encryption is ultimately about trusting the sender, AI Emaily also reads the inbound authentication results on the mail you receive to flag likely spoofing and phishing, with approve-before-send, undo and a full audit trail on anything the agent does. We build AI Emaily; it runs on a 7-day free trial on the Pro and Autopilot plans, and the pricing page and homepage have the rest.
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.