SMTP TLS Reporting (TLS-RPT) — Complete Setup Guide

Published April 2026 · 14 min read

SMTP TLS Reporting, defined in RFC 8460, gives domain owners visibility into whether mail servers are successfully negotiating TLS connections when sending email to their domain. Without TLS-RPT, you have no way to know if sending servers are falling back to unencrypted connections — a critical blind spot in your email security posture.

Think of TLS-RPT as the reporting companion to MTA-STS. While MTA-STS tells senders "use TLS or fail," TLS-RPT tells you whether they actually did. Even without MTA-STS deployed, TLS-RPT provides valuable operational intelligence about TLS connectivity to your mail servers.

What Is SMTP TLS Reporting?

When a sending mail server connects to your MX server, it attempts a TLS handshake. If that handshake fails — due to certificate errors, protocol version mismatches, or configuration problems — the connection may fall back to plaintext SMTP. Until TLS-RPT, domain owners had no automated mechanism to learn about these failures.

TLS-RPT works through a simple DNS record that tells sending servers where to deliver reports. When a sending server encounters a TLS failure (or even a successful TLS connection) while delivering mail to your domain, it can generate a JSON report and send it to the address you specify.

TLS-RPT vs MTA-STS: What's the Difference?

These two standards are complementary but serve different purposes:

MTA-STS — Publishes a policy that tells senders to require TLS. It's the enforcement mechanism.
TLS-RPT — Collects reports about TLS successes and failures. It's the monitoring mechanism.

You can deploy TLS-RPT independently of MTA-STS, and many operators do. The reports are useful even without an enforcement policy because they reveal real-world TLS connectivity problems you wouldn't otherwise see.

Why TLS-RPT Matters

Detect Downgrade Attacks

A downgrade attack (also called a STARTTLS stripping attack) occurs when an attacker intercepts the SMTP session and removes the STARTTLS offering, forcing the connection to remain in plaintext. TLS-RPT reports will show these failures, allowing you to detect active attacks against your mail infrastructure.

Monitor Certificate Problems

Expired, mismatched, or untrusted certificates cause TLS handshake failures. Without TLS-RPT, these failures are invisible — senders silently fall back to plaintext or fail delivery, and you never hear about it.

Validate MTA-STS Enforcement

If you've deployed MTA-STS in enforce mode, TLS-RPT tells you how many senders are actually honoring the policy. You'll see which sending infrastructure supports your requirements and which doesn't.

Compliance Requirements

Several regulatory frameworks, including PCI DSS and certain data protection regulations, require encryption of data in transit. TLS-RPT provides auditable evidence that TLS is being used for email transport.

TLS-RPT DNS Record Setup

The TLS-RPT record is a TXT record published at _smtp._tls.yourdomain.com.

Basic Record — Email Reports

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

This tells sending servers to send TLS reports to the specified email address. The rua (Reporting URI for Aggregate data) tag is required.

Using HTTPS for Reports

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=https://reports.yourdomain.com/tls-rpt"

You can also specify an HTTPS endpoint instead of an email address. This is useful if you have an automated report ingestion pipeline.

Multiple Report Destinations

_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com,mailto:security@partner.com"

Separate multiple destinations with commas. This is common when outsourcing TLS monitoring to a third party.

Step-by-Step TLS-RPT Configuration

Step 1: Create a Dedicated Mailbox

Create a dedicated mailbox or distribution list for receiving TLS reports. A good convention is tls-reports@yourdomain.com. These reports are machine-generated and voluminous — don't send them to a personal inbox.

Step 2: Publish the DNS Record

Add the TXT record to your DNS configuration:

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

Use a short TTL (300-3600 seconds) initially in case you need to make changes.

Step 3: Verify with Our Checker

Use our free mailcheck tool to verify your TLS-RPT record is published correctly. We check for syntax errors, missing tags, and common misconfigurations alongside SPF, DKIM, DMARC, and MTA-STS.

Step 4: Wait for Reports

Reports are generated by sending servers on a daily basis. It typically takes 24-48 hours before you start receiving reports from major providers like Gmail, Microsoft, and Yahoo.

Step 5: Combine with MTA-STS (Recommended)

If you haven't already, deploy MTA-STS alongside TLS-RPT. The two standards are designed to work together — MTA-STS provides enforcement, TLS-RPT provides visibility.

Understanding TLS-RPT Reports

TLS reports are delivered as JSON files, typically compressed with gzip, and sent as email attachments with MIME type application/tlsrpt+json. Some senders may also deliver reports as application/tlsrpt+gzip.

Report Structure

A TLS report contains the following key elements:

Organization — The name of the organization generating the report
Date range — The UTC time window the report covers
Policy domain — The domain the policy applies to (your domain)
Policy type — sts (MTA-STS), tlsa (DANE), or smtp (opportunistic)
Summary — Counts of successful and failed TLS sessions
Failure details — Specific information about each failure type

Example Report (Successful Connections)

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

Example Report (With Failures)

{
  "organization": "google.com",
  "date-range": {
    "start-datetime": "2026-04-24T00:00:00Z",
    "end-datetime": "2026-04-24T23:59:59Z"
  },
  "policies": [{
    "policy-type": "sts",
    "policy-string": ["version: STSv1","mode: enforce","max_age: 604800","mx: mail.example.com"],
    "policy-domain": "example.com",
    "summary": {
      "total-successful-session-count": 1530,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "209.85.220.41",
      "receiving-mx-hostname": "mail.example.com",
      "failed-session-count": 12,
      "additional-information": "https://reports.example.com/detail/12345",
      "failure-reason-code": "X509_V_ERR_CERT_HAS_EXPIRED"
    }]
  }]
}

TLS Failure Types

RFC 8460 defines the following failure result types that can appear in TLS-RPT reports:

starttls-not-supported — The receiving server does not offer STARTTLS at all.
certificate-expired — The server's TLS certificate has expired.
certificate-not-trusted — The certificate chain is not trusted (self-signed or chain issue).
validation-failure — General TLS validation failure not covered by other types.
sts-policy-fetch-error — The sender could not retrieve the MTA-STS policy from HTTPS.
sts-webpki-invalid — The MTA-STS policy was served over an invalid TLS certificate.

Tip: A high number of starttls-not-supported failures on your MX servers means your mail server isn't advertising STARTTLS at all — this is a serious configuration problem that needs immediate attention.

Common TLS-RPT Problems and Fixes

Not Receiving Reports

The most common reason for not receiving TLS reports is a DNS record that doesn't pass validation. Check that:

The record is published at _smtp._tls.yourdomain.com (not _smtp._tls alone — some DNS platforms append the domain, some don't)
The v=TLSRPTv1 tag is spelled correctly (case-sensitive)
The rua email address actually exists and can receive mail
Report senders can deliver to the rua address (check DMARC alignment — rua addresses must accept mail from external domains)

Reports Show Unexpected Failures

If you see TLS failures in reports, investigate systematically:

Check certificate validity — Run openssl s_client -connect mail.yourdomain.com:25 -starttls smtp to inspect your certificate chain.
Verify TLS configuration — Use tools like our mailcheck or external scanners to validate your TLS setup.
Review cipher suites — Ensure your server supports modern cipher suites that sending servers expect.
Check SNI configuration — If hosting multiple domains, ensure Server Name Indication is properly configured.

DNS Record Syntax Errors

Common syntax mistakes include:

Missing v=TLSRPTv1 tag (must come first)
Using semicolons instead of commas between rua destinations
Spaces around the = sign (not allowed)
Incorrect subdomain label (must be exactly _smtp._tls)

TLS-RPT with External Report Processors

Parsing raw JSON reports manually is tedious at scale. Several options exist for automated processing:

Self-Hosted Parsing

Open-source tools can parse and store TLS-RPT reports in a database for analysis. If you're already running monitoring infrastructure, this is straightforward — the report format is well-defined JSON.

Hosted Report Analytics

Our mailcheck platform can process TLS-RPT reports alongside DMARC aggregate reports, giving you a unified view of both authentication and transport security. Check your domain's current status including TLS-RPT with a free scan.

Best Practices for TLS-RPT Deployment

Deploy before MTA-STS — Get visibility first, then enforce. This gives you a baseline of TLS connectivity before you start rejecting connections.
Use a dedicated report address — Don't mix TLS reports with DMARC reports or personal email.
Monitor daily — Set up alerting for sudden increases in TLS failures, which may indicate attacks or certificate problems.
Check alignment with MX records — Ensure your MX hosts and MTA-STS policy match. Discrepancies between DNS MX records and MTA-STS mx: tags will generate failure reports.
Set appropriate TTL — 3600 seconds is a good TTL for TLS-RPT records. Not too long that changes take forever, not too short that you create unnecessary DNS load.
Combine with header analysis — When you spot TLS failures in reports, cross-reference with email headers to trace the full delivery path.

TLS-RPT and DMARC: Complementary Reporting

While DMARC reports focus on authentication (SPF/DKIM pass/fail), TLS-RPT reports focus on transport security (TLS success/failure). Together, they give you a complete picture of email security:

DMARC reports — "Who is sending email as my domain, and are they authenticated?"
TLS-RPT reports — "When email is in transit to my domain, is it encrypted?"

We recommend setting up both. See our DMARC reporting guide for the authentication side of the equation.

Security Considerations

Report destination validation — Ensure your rua address is secure and not publicly guessable. Reports contain information about your mail infrastructure that could be useful to attackers.
Email authentication for reports — TLS reports should be authenticated with DKIM by the sender. Verify DKIM signatures on incoming reports before processing them.
Rate limiting — RFC 8460 specifies that report senders should not send more than one report per 24 hours per failure type per receiving domain. If you're getting flooded, something is wrong.
Report size — Individual reports should not exceed 1MB uncompressed. If you receive larger reports, they may not be legitimate.

Important: If you delegate TLS-RPT reporting to an external organization's email address, that organization will learn which IP addresses send mail to your domain and what TLS configuration your servers support. Consider this information sharing carefully.

Verify Your TLS-RPT Setup

Use our free tool to check your TLS-RPT DNS record and overall email security posture:

Check TLS-RPT Now →

You can also compare your domain against top-scoring organizations. Cloudflare scores 92/100 — see how your domain compares.

Related guides: MTA-STS Explained · DMARC Setup · DMARC Reporting · Email Header Analysis