MTA-STS glossary
What does v=TLSRPTv1 mean in a TLS-RPT record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
v=TLSRPTv1 is the version tag of a TLS-RPT record — a DNS TXT record at _smtp._tls.<domain>, defined by RFC 8460, of the form v=TLSRPTv1; rua=mailto:.... It asks participating senders to deliver a daily JSON report of their TLS negotiation successes and failures to your domain, including MTA-STS policy failures.
v=TLSRPTv1 at a glance | |
|---|---|
| Tag | v (version) |
| Valid values | TLSRPTv1 — the only version defined by RFC 8460 |
| Default | Required — the record must start with v=TLSRPTv1 or it is ignored. |
| Where it goes | First tag of the TXT record at _smtp._tls.<domain>, e.g. v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com |
How v=TLSRPTv1 works
TLS-RPT (SMTP TLS Reporting, RFC 8460) is the reporting channel for mail transport security. Publish this record and senders that support it — Google and Microsoft among them — deliver one JSON report per day summarising their TLS sessions to your domain: how many connections negotiated TLS successfully, how many failed, and why — an expired certificate, no STARTTLS offered, or a mismatch against your MTA-STS policy.
It's the visibility companion to MTA-STS testing mode: testing only makes sense if the failures go somewhere, and TLS-RPT is that somewhere. It's how you find out an MX certificate is about to be a problem before you flip mode: enforce. It plays the same role for transport security that DMARC's rua aggregate reports (see /learning/what-is-a-rua) play for authentication — evidence first, enforcement second.
The rua= destination can be a mailto: address or an https: endpoint that accepts posted reports, and you can list more than one. The reports themselves are machine-readable JSON, usually gzip-compressed — fine to eyeball once, unmanageable by hand across a fleet of domains.
Correct record vs common mistake
Correct
v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.comA version tag and a destination — participating senders now deliver a daily JSON summary of TLS successes and failures for your domain.
Common mistake
v=TLSRPTv1No rua= means no destination — the record is invalid without one, so no reports can ever arrive and you get none of the visibility TLS-RPT exists to provide.
Troubleshooting v=TLSRPTv1
| Issue | Likely cause | Fix |
|---|---|---|
| No reports arriving | Record mistyped or at the wrong name — or simply that only some providers send TLS reports | Verify the TXT record at _smtp._tls.<domain> and confirm the rua= mailbox accepts external mail; Google and Microsoft are reliable senders |
| Reports arrive but are unreadable | They're gzip-compressed JSON attachments, not human-readable email | Decompress and parse them, or point rua= at a service that aggregates them for you |
| Reports show failures but mail seems fine | Testing-mode MTA-STS failures or intermittent certificate issues — delivered anyway, but flagged | Treat them as the pre-enforce punch list: fix the certificates and mx patterns they identify, then switch mode to enforce |
Why it matters for MSPs
Without TLS-RPT, transport failures across a client base are invisible — TLS problems don't bounce, they silently downgrade or defer. Publishing it on 50–200 domains solves that but creates the next problem: 50–200 daily gzipped JSON feeds. The evidence you need to reach enforce safely exists; no human is reading it for two hundred tenants.
Trusted by MSPs
“Their responsive support, agent task lists, white-label reporting, and centralized dashboard make managing our customer domains, effortless.”
Bobby Ghoshal — CEO, dupe.com
DMARC software that does the work
Palisade closes the loop: it publishes TLS-RPT alongside the MTA-STS policies it hosts, reads every client domain's daily reports for you, and uses them as the evidence to advance each domain from testing to **enforce** — reporting most vendors leave you to parse yourself.
1 domain free up to 1,000 emails/month
Questions readers ask