Skip to content
Back to Blog
DMARC.WS Team··6 min read

TLS-RPT Explained: Monitoring Your Email Encryption

TLSMTA-STSEmail SecurityEncryption

What Is TLS-RPT?

TLS-RPT (Transport Layer Security Reporting, RFC 8460) is a standard that lets domain owners receive reports about TLS connection failures when other servers try to deliver email to them. Think of it as DMARC reporting, but for encryption instead of authentication.

When a sending server tries to establish a TLS connection to deliver mail to your domain and something goes wrong — expired certificate, MTA-STS policy failure, DANE validation error — TLS-RPT ensures you hear about it.

Why TLS-RPT Matters

Email encryption in transit relies on TLS (Transport Layer Security). Most modern mail servers support TLS, but unlike HTTPS, email TLS has historically been opportunistic — if the TLS handshake fails, servers fall back to unencrypted delivery.

MTA-STS and DANE change this by letting you enforce TLS. But enforcement without visibility is dangerous: if your TLS configuration breaks, emails bounce instead of being delivered unencrypted. TLS-RPT gives you visibility into these failures so you can fix them before they impact delivery.

The TLS-RPT DNS Record

TLS-RPT uses a DNS TXT record at _smtp._tls.{domain}:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

You can specify multiple reporting destinations:

v=TLSRPTv1; rua=mailto:tls@example.com,https://tls-reports.example.com/api/report

Reports can be sent via email (mailto:) or HTTPS POST (https:).

What's in a TLS Report?

TLS reports are JSON documents sent daily by mail servers that attempted to deliver email to your domain. Each report contains:

  • Reporting organization: Who sent the report (e.g., Google, Microsoft)
  • Date range: The period the report covers
  • Policy applied: Your MTA-STS or DANE policy that was evaluated
  • Success count: Number of successful TLS connections
  • Failure count: Number of failed TLS connections
  • Failure details: Specific error types and affected sending/receiving MX hosts

Common Failure Types

Failure Type Meaning
starttls-not-supported Your MX server doesn't support STARTTLS
certificate-expired Your TLS certificate has expired
certificate-not-trusted Certificate not signed by a trusted CA
certificate-host-mismatch Certificate doesn't match the MX hostname
validation-failure MTA-STS or DANE validation failed
sts-policy-fetch-error Sender couldn't retrieve your MTA-STS policy
sts-webpki-invalid Your MTA-STS policy endpoint has certificate issues

TLS-RPT and MTA-STS: Better Together

TLS-RPT is designed to work alongside MTA-STS (Mail Transfer Agent Strict Transport Security). Here's how they complement each other:

  • MTA-STS tells senders "you must use TLS to deliver mail to this domain, and the certificate must be valid"
  • TLS-RPT tells the domain owner "here's what happened when senders tried to comply with your MTA-STS policy"

Without TLS-RPT, you publish an MTA-STS policy but have no way to know if it's working correctly or causing delivery failures.

Setting Up TLS-RPT

Step 1: Decide on a Reporting Destination

You can receive reports via email or HTTPS. Email is simpler to set up; HTTPS is better for automated processing.

For most organizations, email delivery to a dedicated mailbox works fine — or better yet, use a DMARC monitoring platform that also handles TLS reports.

Step 2: Publish the DNS Record

Add a TXT record:

Host: _smtp._tls
Type: TXT
Value: v=TLSRPTv1; rua=mailto:tls-reports@example.com

Step 3: Ensure Your TLS Configuration Is Solid

Before enabling TLS-RPT (and especially before deploying MTA-STS), verify:

  • Your MX servers support STARTTLS
  • Your TLS certificates are valid, not expired, and issued by a trusted CA
  • Certificate hostnames match your MX records
  • You have certificate renewal automated (Let's Encrypt or similar)

Step 4: Monitor Reports

Reports start arriving within 24–48 hours. Review them for:

  • Any failure counts above zero
  • Certificate-related issues that need attention
  • MTA-STS policy fetch errors

Reading TLS Reports

A typical TLS report JSON structure:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-03-01T00:00:00Z",
    "end-datetime": "2026-03-01T23:59:59Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 604800"],
      "policy-domain": "example.com"
    },
    "summary": {
      "total-successful-session-count": 1523,
      "total-failure-session-count": 0
    }
  }]
}

This is what a healthy report looks like — all sessions successful, zero failures.

When failures occur, the report includes a failure-details array with the specific error type, sending MTA IP, and receiving MX hostname.

Common Issues and Fixes

Certificate Expired

Symptom: certificate-expired failures in reports Fix: Renew your TLS certificate. Set up automated renewal to prevent recurrence.

Hostname Mismatch

Symptom: certificate-host-mismatch failures Fix: Ensure your certificate's Subject Alternative Names (SANs) include all your MX hostnames. If your MX points to mail.example.com, your certificate must cover mail.example.com.

MTA-STS Policy Fetch Error

Symptom: sts-policy-fetch-error failures Fix: Verify that https://mta-sts.example.com/.well-known/mta-sts.txt is accessible, returns a valid policy, and has a valid HTTPS certificate.

Best Practices

  1. Deploy TLS-RPT before MTA-STS: Get visibility into your TLS health before enforcing it
  2. Start MTA-STS in testing mode: Use mode: testing initially — senders report but don't enforce
  3. Monitor certificate expiration: Automate renewal and alert on upcoming expirations
  4. Use a reporting platform: Raw JSON reports are hard to parse at scale — use a tool that aggregates and visualizes them
  5. Check reports weekly: Even after initial setup, new issues can emerge from infrastructure changes

Summary

TLS-RPT is the monitoring companion to MTA-STS and DANE. It gives you visibility into email encryption failures that you'd otherwise never know about. Setting it up is simple — one DNS record — and the payoff is confidence that your email connections are properly encrypted.

If you've already set up DMARC monitoring, TLS-RPT is a natural next step in securing your email infrastructure.