TLS-RPT SMTP TLS Reporting [2026]

What Is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) provides feedback on email encryption failures between mail servers. When a sending server can’t establish a secure TLS connection with your mail server, TLS-RPT tells you about it through automated reports — what failed, why it failed, and how many times it happened.

Without TLS-RPT, encryption failures happen silently. You’d never know that a misconfigured certificate, an expired key, or a TLS version mismatch is causing messages to fall back to unencrypted delivery or fail entirely. In a world where email encryption should be the default, these silent failures expose your organization to man-in-the-middle attacks and compliance violations.

TLS-RPT is defined in RFC 8460 and works by letting you publish a DNS record that tells other mail servers where to send reports about TLS connection problems when delivering email to your domain.

Why TLS-RPT Matters: Monitoring Email Encryption

Email encryption during transit is no longer optional. Regulations like NIS2, GDPR, and HIPAA increasingly expect organizations to protect email in transit. Major email providers like Gmail and Outlook now require TLS for delivery, and downgrade attacks — where attackers force servers to abandon encryption — are a real threat.

TLS-RPT gives you visibility into three critical scenarios:

1. Configuration errors — You publish an MTA-STS policy requiring encryption, but your certificate expired. Without TLS-RPT, senders silently reject your email.
2. Compatibility issues — A sending server only supports TLS 1.0, but your server requires TLS 1.2+. TLS-RPT reports the mismatch.
3. Active attacks — An attacker intercepts email and presents a fraudulent certificate. TLS-RPT reports the validation failure, alerting you to potential compromise.

The protocol is most valuable when paired with MTA-STS or DANE. Those protocols tell senders to require encryption; TLS-RPT tells you when that requirement causes problems — giving you a feedback loop to fix issues before they affect users.

How TLS-RPT Works (RFC 8460)

The TLS-RPT workflow is straightforward:

1. You publish a TLS-RPT record in DNS as a TXT record at _smtp._tls.yourdomain.com
2. Sending servers attempt TLS when delivering email to your domain
3. If TLS negotiation fails, the sender records the failure type, timestamp, and affected IP addresses
4. The sender aggregates failures over a reporting period (typically 24 hours)
5. The sender emails you a JSON report to the address specified in your TLS-RPT record

Reports are sent asynchronously, usually once per day. They cover all TLS failures from that sender’s infrastructure during the reporting window, making it easy to spot systemic issues rather than one-off anomalies. A TLS report analyzer can help you parse these JSON reports and surface actionable findings.

Unlike DMARC reports, which focus on authentication (SPF and DKIM), TLS-RPT reports focus exclusively on transport security — the encrypted connection between mail servers.

The TLS-RPT DNS Record

A TLS-RPT record is a DNS TXT record with a simple syntax:

v=TLSRPTv1; rua=mailto:[email protected]

You publish this record at _smtp._tls.yourdomain.com as a TXT record. For example, if your domain is example.com, the full DNS record would be:

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

The rua (Reporting URI for Aggregate reports) tag can accept multiple destinations separated by commas:

v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.com/tls

HTTPS endpoints receive reports via HTTP POST with Content-Type: application/tlsrpt+gzip or application/tlsrpt+json.

How to Set Up TLS-RPT (Step-by-Step)

Setting up TLS-RPT takes less than 10 minutes:

Step 1: Choose a Reporting Endpoint

Decide where you want to receive reports. Options:

• Email address — simplest option, but reports are JSON files that require parsing
• HTTPS endpoint — best for automated processing and integration with monitoring systems
• Third-party service — DMARCguard and similar platforms aggregate TLS-RPT reports into dashboards

For email delivery, create a dedicated mailbox like [email protected] or use a catch-all address. Reports can be large (10KB-500KB compressed), so avoid sending them to a low-capacity inbox.

Step 2: Create the TLS-RPT DNS Record

Log into your DNS provider (Cloudflare, Route 53, Google Cloud DNS, etc.) and add a TXT record. You can use our TLS-RPT record generator to build a valid record before adding it to DNS.

• Name/Host: _smtp._tls.yourdomain.com (or just _smtp._tls if your DNS provider auto-appends the domain)
• Type: TXT
• Value: v=TLSRPTv1; rua=mailto:[email protected]

Step 3: Verify DNS Propagation

Use dig or nslookup to confirm the record is live:

dig _smtp._tls.yourdomain.com TXT +short

Expected output:

"v=TLSRPTv1; rua=mailto:[email protected]"

DNS propagation typically takes 5 minutes to 48 hours, depending on your TTL settings.

Step 4: Wait for Reports

Sending mail servers will begin delivering reports within 24-48 hours. You’ll only receive reports from senders who:

1. Support TLS-RPT (Gmail, Outlook, Yahoo, and most modern MTAs do)
2. Experienced a TLS failure when delivering to your domain
3. Successfully delivered at least one message (so they know your TLS-RPT record exists)

If you receive zero reports after a week, that’s good news — it means TLS connections are succeeding.

TLS-RPT for Google Workspace and Microsoft 365

Both major email platforms support TLS-RPT, but setup varies slightly.

Google Workspace

Google Workspace domains automatically support inbound TLS. To set up TLS-RPT reporting:

1. Add the _smtp._tls.yourdomain.com TXT record in your DNS provider (not in the Google Admin Console)
2. Google sends TLS-RPT reports to your rua address when delivery to your domain fails
3. Google’s mail servers also respect TLS-RPT records you publish — they’ll send you reports about their delivery failures

Google sends reports in standard RFC 8460 JSON format, typically once per day.

Microsoft 365 / Exchange Online

Microsoft 365 supports TLS-RPT similarly:

1. Add the DNS TXT record in your external DNS provider (Azure DNS, Cloudflare, etc.)
2. Microsoft 365 sends TLS-RPT reports when outbound delivery fails to domains with TLS-RPT records
3. You can monitor inbound TLS failures by publishing a TLS-RPT record for your domain

Microsoft’s TLS-RPT implementation aligns with RFC 8460. Reports arrive as JSON email attachments.

Self-Hosted Mail Servers

For Postfix, Exim, or other self-hosted MTAs, TLS-RPT support depends on the MTA version:

• Postfix 3.6+ — native TLS-RPT reporting support via smtp_tls_policy_maps and external reporting scripts
• Exim 4.95+ — experimental TLS-RPT support via third-party patches
• Haraka, Stalwart, Zone-MTA — built-in TLS-RPT support

Check your MTA’s documentation for specific configuration instructions.

How to Read a TLS-RPT Report (JSON Example)

TLS-RPT reports are JSON files, usually gzip-compressed. Here’s an annotated example:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-03-01T00:00:00Z",
    "end-datetime": "2026-03-01T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "2026-03-01T00:00:00Z_example.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": ["version: STSv1", "mode: enforce"],
        "policy-domain": "example.com"
      },
      "summary": {
        "total-successful-session-count": 12450,
        "total-failure-session-count": 3
      },
      "failure-details": [
        {
          "result-type": "certificate-expired",
          "sending-mta-ip": "2001:4860:4000::1",
          "receiving-mx-hostname": "mail.example.com",
          "failed-session-count": 3,
          "additional-information": "Certificate expired on 2026-02-28"
        }
      ]
    }
  ]
}

Key Fields Explained

In the example above, Google successfully delivered 12,450 messages to example.com but failed 3 times due to an expired certificate on mail.example.com.

How to Verify Your TLS-RPT Record

Use these methods to validate your TLS-RPT configuration:

Method 1: DNS Lookup

Run a DNS query:

dig _smtp._tls.yourdomain.com TXT +short

Verify the output matches your published record.

Method 2: Online TLS-RPT Checkers

Use a TLS-RPT checker to validate syntax and DNS propagation. DMARCguard’s free checker verifies:

• DNS record exists and is properly formatted
• rua email address is reachable
• TXT record syntax matches RFC 8460

Method 3: Send Test Email

Send an email from a service that supports TLS-RPT (Gmail, Outlook.com) to your domain. If TLS succeeds, you won’t receive a report — but if you intentionally misconfigure TLS (e.g., use a self-signed certificate with MTA-STS in enforce mode), you should receive a failure report within 24 hours.

TLS-RPT Troubleshooting: Fixing Common Failures

TLS-RPT reports include a result-type field that identifies the specific failure. Here’s how to fix the most common issues:

starttls-not-supported

Cause: Your mail server doesn’t advertise STARTTLS support during the SMTP handshake.

Fix:

• Enable TLS in your mail server configuration (Postfix: smtpd_tls_security_level = may, Exim: tls_advertise_hosts = *)
• Ensure your TLS certificate is installed and readable by the mail server process
• Restart your mail server after configuration changes

certificate-expired

Cause: Your TLS certificate has passed its expiration date.

Fix:

• Renew your certificate immediately (use Let’s Encrypt with certbot for automated renewal)
• Update your mail server configuration to point to the new certificate
• Set up automated renewal with a 30-day pre-expiration reminder

certificate-host-mismatch

Cause: Your TLS certificate’s Common Name (CN) or Subject Alternative Name (SAN) doesn’t match your mail server’s hostname.

Fix:

• Verify your MX record hostname: dig yourdomain.com MX
• Ensure your certificate’s SAN includes the MX hostname (e.g., mail.example.com)
• If you have multiple MX records, your certificate should include all hostnames or use a wildcard certificate

validation-failure

Cause: The certificate chain can’t be verified against trusted Certificate Authorities.

Fix:

• Ensure your certificate includes the full chain (root + intermediate CA certificates)
• Verify your certificate issuer is trusted by major CAs (avoid self-signed certificates in production)
• Check for expired intermediate certificates

sts-policy-fetch-error

Cause: The sender couldn’t retrieve your MTA-STS policy file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt.

Fix:

• Verify the policy file is accessible via HTTPS (not HTTP)
• Check that the web server hosting the policy file has a valid TLS certificate
• Ensure no firewall or CDN is blocking access to /.well-known/mta-sts.txt

sts-policy-invalid

Cause: Your MTA-STS policy file has syntax errors or invalid values.

Fix:

• Validate your policy file syntax (must be plain text, not HTML)
• Ensure mode is set to testing, enforce, or none (not other values)
• Verify mx entries match your actual MX records
• Check that max_age is a valid integer (recommended: 86400 or higher)

TLS-RPT and MTA-STS

TLS-RPT and MTA-STS are companion protocols that work best together:

• MTA-STS is a policy that tells senders: “You must use TLS when delivering to my domain, and here’s how to verify my certificate.”
• TLS-RPT is a monitoring protocol that tells you: “Here’s every time a sender tried to deliver to your domain but TLS failed.”

When you deploy MTA-STS in enforce mode, you’re requiring encryption. But if your TLS certificate expires or you misconfigure your mail server, legitimate email gets rejected — and you won’t know unless you have TLS-RPT enabled.

The recommended deployment sequence:

1. Publish a TLS-RPT record first (start monitoring)
2. Publish an MTA-STS policy in testing mode (senders report but don’t enforce)
3. Monitor TLS-RPT reports for 1-2 weeks to identify configuration issues
4. Fix any failures reported in TLS-RPT
5. Upgrade MTA-STS to enforce mode once TLS-RPT shows zero failures

This approach ensures you catch configuration errors before they cause email delivery failures.

Frequently Asked Questions

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) is a protocol defined in RFC 8460 that provides feedback on TLS connection failures during email delivery. When a sending mail server can’t establish a secure TLS connection with your mail server, TLS-RPT tells you what failed, why, and how often through automated JSON reports.

How do I set up a TLS-RPT DNS record?

Publish a TXT record at _smtp._tls.yourdomain.com with the value: v=TLSRPTv1; rua=mailto:[email protected]. Replace the email address with your own reporting endpoint. Most DNS providers support TXT records, and the change typically propagates within minutes to hours.

What is the difference between TLS-RPT and MTA-STS?

MTA-STS is a policy that tells senders to require TLS when delivering to your domain. TLS-RPT is a monitoring protocol that reports when TLS connections fail. They work best together: MTA-STS enforces encryption, TLS-RPT tells you when enforcement causes problems.

What does a TLS-RPT report contain?

TLS-RPT reports are JSON files containing the policy type being evaluated (MTA-STS, DANE, or no policy), specific failure types (certificate expired, hostname mismatch, STARTTLS not supported), failure counts, sending server details, and the time range of the report.

How do I fix “starttls-not-supported” in a TLS-RPT report?

This error means your mail server doesn’t support STARTTLS encryption. Enable TLS/SSL support in your mail server configuration (Postfix, Exim, Exchange, etc.), ensure port 587 or 465 is configured for encrypted connections, and verify your TLS certificate is valid and installed correctly.

Do I need TLS-RPT if I already have DMARC?

Yes, they serve different purposes. DMARC reports on email authentication failures (SPF/DKIM), while TLS-RPT reports on email encryption failures. DMARC protects against spoofing; TLS-RPT protects against man-in-the-middle attacks and downgrade attacks on email delivery.

Does Google Workspace / Microsoft 365 support TLS-RPT?

Yes, both Google Workspace and Microsoft 365 support TLS-RPT. Google sends TLS-RPT reports to domains that publish TLS-RPT records, and both platforms support setting up TLS-RPT records for your domains to monitor inbound delivery failures.

Related Protocols

• MTA-STS — Tells senders to require TLS for your domain
• DANE — Uses DNSSEC to verify mail server certificates
• DMARC — Similar reporting concept but for authentication, not encryption