What Is TLS-RPT? SMTP TLS Reporting Explained
A practical reference guide to TLS-RPT, including what the record looks like, what the tags mean, and how it fits alongside MTA-STS.
What TLS-RPT is
TLS-RPT (SMTP TLS Reporting) is a DNS-based mechanism that allows domain owners to receive reports about email delivery issues related to TLS encryption.
It provides visibility into whether messages are successfully delivered over secure connections and highlights failures such as certificate errors or policy mismatches.
TLS-RPT is particularly valuable when deploying MTA-STS, as it helps identify real-world delivery issues that would otherwise be invisible.
You can check your TLS-RPT record with the DNS Pro TLS-RPT Check tool.
For comparison, you can also use MXToolbox: https://mxtoolbox.com/TLSRPTLookup.aspx
Tools For This Topic
What a TLS-RPT record looks like
TLS-RPT is published as a TXT record under a specific subdomain: _smtp._tls.yourdomain.com.
Example record:
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"How to read the record
- _smtp._tls.example.com → fixed hostname for TLS-RPT policies
- 3600 → TTL (cache duration in seconds)
- TXT → record type
- v=TLSRPTv1 → identifies the record as TLS-RPT
- rua=mailto:tls-reports@example.com → destination for aggregate reports
Key tags explained
TLS-RPT uses a simple tag-based format:
- v → version (must be TLSRPTv1)
- rua → reporting URI(s), typically mailto addresses
- Multiple rua values can be specified as a comma-separated list
v=TLSRPTv1; rua=mailto:reports@example.com,mailto:security@example.comWhy TLS-RPT matters
SMTP delivery failures related to TLS are often silent. Without reporting, it can be difficult to detect misconfigurations or downgrade attacks.
TLS-RPT provides aggregate reports that show:
- Failed TLS negotiations
- Certificate validation errors
- Policy mismatches (e.g. MTA-STS enforcement failures)
- Delivery attempts downgraded to plaintext
How TLS-RPT works with MTA-STS
TLS-RPT does not enforce encryption policies itself. Instead, it reports on whether delivery met expectations.
MTA-STS defines the policy (e.g. require TLS), while TLS-RPT provides feedback on whether that policy is being honoured.
Learn more about MTA-STS here: /articles/what-is-mta-sts
What to check
- The record exists at _smtp._tls.yourdomain.com
- The version tag is exactly v=TLSRPTv1
- The rua address is valid and monitored
- Multiple reporting destinations are correctly formatted
- The domain also has MTA-STS configured if enforcement is required
Common mistakes
- Publishing the record at the root domain instead of _smtp._tls
- Incorrect tag formatting or missing semicolons
- Assuming TLS-RPT enforces policy rather than reports
- Configuring reporting but not monitoring the mailbox
- Using invalid or unreachable mailto addresses
Basic validation commands
# Query TLS-RPT record
dig TXT _smtp._tls.example.com
# Alternative
nslookup -type=txt _smtp._tls.example.comUse These DNS Pro Tools
If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.
Standards And Official References
Use these primary standards and provider resources to verify the protocol details and implementation guidance covered in this article.
Related Tools
Related Articles
What Is MTA-STS? SMTP TLS Policy Explained
Learn what MTA-STS is, how it enforces TLS for email delivery, what the policy looks like, and how it works with DNS and HTTPS.
What Is BIMI? Email Brand Indicators Explained
A practical guide to BIMI, including what the BIMI record contains, how selector-based publishing works, and how BIMI fits into email trust.
What is SPF flattening?
A practical guide to SPF flattening, including what a flattened record looks like, why teams consider it, and what risks it introduces.