TLS-RPT (SMTP TLS Reporting, RFC 8460) is a standard that lets email receivers report back to domain owners about TLS negotiation successes and failures. It provides visibility into whether senders can actually establish encrypted connections with your mail servers.

How is TLS-RPT different from MTA-STS?

MTA-STS enforces encryption by telling senders to only deliver over TLS. TLS-RPT is the reporting companion: it tells you when TLS negotiations fail. They work best together — MTA-STS sets the policy, TLS-RPT gives you the feedback loop.

What format are TLS-RPT reports?

TLS-RPT reports are delivered as JSON files (compressed with gzip), typically once per day. They contain details about successful and failed TLS negotiations, including failure types, sending and receiving MX hostnames, and policy information.

How do I set up TLS-RPT?

Publish a single DNS TXT record at _smtp._tls.yourdomain.com with the value 'v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com'. Replace the email address with where you want reports delivered. That's it — TLS-RPT is one of the simplest email security protocols to deploy.

All posts

Technical

TLS-RPT Explained: Monitor Your Email Encryption

March 17, 20266 min

When you deploy MTA-STS or STARTTLS on your mail server, you're telling the world that your domain supports encrypted email connections. But how do you know if it's actually working? Sending servers might fail to establish TLS, fall back to plain text, or encounter certificate errors, and you'd never hear about it.

TLS-RPT (TLS Reporting) solves this. It's a standard (RFC 8460) that lets sending mail servers report back to you when they have trouble establishing encrypted connections to your domain. Think of it as DMARC reports, but for encryption instead of authentication.

What TLS-RPT reports tell you

A TLS-RPT report is a JSON file sent by email providers that attempted to deliver mail to your domain. Each report contains:

The reporting organization (e.g., Google, Microsoft, Yahoo)
The time period covered by the report
The policy that was applied (MTA-STS or DANE)
Success and failure counts for TLS connections
Specific failure details: certificate errors, handshake failures, policy mismatches, DNS issues

Unlike DMARC reports (which are XML), TLS-RPT reports use JSON, making them slightly easier to parse. But the volume can still be overwhelming without automated processing.

Why TLS-RPT matters

Without TLS-RPT, you're deploying encryption blind. You publish an MTA-STS policy or enable STARTTLS, assume it works, and hope for the best. Meanwhile, legitimate senders might be failing to connect securely to your mail servers.

Common issues TLS-RPT catches:

Expired or misconfigured TLS certificates on your mail server
MTA-STS policy that doesn't match your actual MX records
DANE TLSA records that are out of sync with your certificate
Sending servers that don't support the TLS version you require
DNS resolution failures when senders try to fetch your MTA-STS policy

Setting up TLS-RPT

TLS-RPT requires a single DNS record. You publish a TXT record at _smtp._tls.yourdomain.com that tells senders where to send reports:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

That's it. Once the record is published, email providers that support TLS-RPT (Google, Microsoft, Yahoo, and others) will start sending you daily reports about TLS connection attempts to your domain.

You can also use an HTTPS endpoint instead of email if you prefer to process reports programmatically.

TLS-RPT and MTA-STS: better together

TLS-RPT is most valuable when paired with MTA-STS. MTA-STS tells senders to require TLS when delivering to your domain. TLS-RPT tells you when those requirements cause problems.

The typical deployment sequence is:

Deploy TLS-RPT first to establish a reporting baseline
Deploy MTA-STS in testing mode so senders report failures without blocking mail
Review TLS-RPT reports to identify and fix any issues
Switch MTA-STS to enforce mode once reports show clean connections

If you deploy MTA-STS in enforce mode without TLS-RPT, you won't know when legitimate mail is being blocked due to TLS failures. Always deploy both together.

Reading TLS-RPT reports

A single TLS-RPT report contains a policies array, each with a summary of successful and failed connection attempts. The failure details include a result type (like "certificate-expired" or "sts-policy-fetch-error") and a count.

For a domain receiving mail from dozens of providers, this adds up to a lot of data. Manually reviewing JSON files daily is not practical for most teams.

How MailShield processes TLS-RPT

MailShield receives your TLS-RPT reports automatically. We parse every report, aggregate the data across providers and time periods, and show you a clear dashboard of your encryption health.

You'll see which senders successfully connect over TLS, which ones fail, and exactly why. When something breaks, like an expiring certificate or a policy mismatch, we alert you immediately so you can fix it before it affects delivery.

Add your domain to MailShield to set up TLS-RPT in minutes. We provide the exact DNS record to publish, handle all report processing, and give you visibility into your email encryption that you can't get any other way.