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
“Palisade streamlined all of our DMARC operations. It was so complicated at first, it was taking so much time. It allowed us to get everything done faster and have a complete overview of our operations, at such an affordable cost. We're saving so much time. It's a great improvement for our operations.”
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
Frequently asked questions
Do I need TLS-RPT if I already have MTA-STS?
Strictly no, practically yes. In testing mode, failures are delivered anyway and only surface through TLS-RPT, without it you're flipping to enforce blind. Even at enforce, it's how you spot certificate problems early.
Where does the TLS-RPT record go?
As a TXT record at _smtp._tls.<domain>, e.g. _smtp._tls.yourdomain.com.
What's in a TLS-RPT report?
One JSON document per sender per day: counts of successful and failed TLS sessions, the failure types (certificate errors, STARTTLS not offered, MTA-STS policy mismatches), and which policy was applied.
Is TLS-RPT the same as DMARC rua reports?
Same pattern, different layer. DMARC rua reports on authentication: who is sending as your domain. TLS-RPT reports on transport: whether mail sent to your domain travels over valid TLS.
Can reports go somewhere other than a mailbox?
Yes: rua= accepts an https: URI as well as mailto:, and you can list multiple destinations in one record.