Why analyze your TLS-RPT reports?
Google, Microsoft, and Yahoo send daily TLS-RPT reports to your domain. Each report reveals whether TLS encryption succeeded or failed for inbound email. Ignoring these reports means flying blind on email security.
The problem: TLS-RPT reports are raw JSON files, often gzip-compressed. No human reads them without a tool.
Three reasons to analyze every report:
- Detect expired certificates - one expired certificate on a secondary MX silently breaks encryption for thousands of emails
- Verify MTA-STS enforcement - senders flag unreachable or invalid policies directly in the report
- Catch failures early - a 2% failure rate today becomes 20% next week if the root cause goes undiagnosed
Upload your first report now and get a health score in under 10 seconds.
How to analyze a TLS-RPT report in 3 steps
Step 1: Get the report
Open the TLS-RPT email from Google (noreply-smtp-tls-reporting@google.com), Microsoft, or another provider. Download the .json.gz or .json attachment. Most providers send one report per 24-hour period.
Step 2: Upload the file
Drag and drop the file onto the upload area above, or click "Browse." The tool accepts .json and .json.gz files up to 10 MB. Decompression is automatic.
Step 3: Read the diagnosis
CaptainDNS parses the report and returns four key outputs:
- Health score (0-100) - four levels: excellent (90+), good (70-89), warning (50-69), critical (below 50)
- Per-policy breakdown - separate results for MTA-STS and DANE with success rates per MX server
- Failure analysis - each failure type explained with severity, root cause, and fix
- Direct tool links - one click to the CaptainDNS tool that resolves each specific issue
Run the analysis now - results appear in under 10 seconds.
TLS-RPT report structure (RFC 8460)
Every TLS-RPT report follows the JSON schema defined by RFC 8460. Understanding this structure helps you interpret raw reports.
Three top-level fields matter:
- organization-name - the sender (e.g., "Google Inc.")
- date-range - the reporting period, typically 24 hours
- policies - one or more evaluated policies (MTA-STS and/or DANE)
Each policy block contains:
| Field | Description |
|---|---|
policy-type | sts, tlsa, or no-policy-found |
policy-domain | The target domain evaluated |
total-successful-session-count | Number of successful TLS connections |
total-failure-session-count | Number of failed TLS connections |
failure-details | Array of failure types with counts and codes |
Use the analyzer above to decode these fields automatically - no manual JSON parsing required.
All 12 TLS failure types analyzed
The analyzer covers every failure code defined in RFC 8460. Here is the complete reference.
STARTTLS failures
| Code | Severity | Cause | Action |
|---|---|---|---|
starttls-not-supported | Critical | MX server does not offer STARTTLS | Enable STARTTLS on the mail server immediately |
A missing STARTTLS means all email to that MX travels in plaintext. Fix this first.
Certificate failures
| Code | Severity | Cause | Action |
|---|---|---|---|
certificate-expired | High | TLS certificate has expired | Renew with Let's Encrypt or your CA |
certificate-host-mismatch | High | CN/SAN does not match the MX hostname | Reissue with the correct hostname |
certificate-not-trusted | High | Self-signed or unrecognized CA | Replace with a certificate from a public CA |
Certificate errors are the most common TLS-RPT failures. Renew or reissue affected certificates immediately.
MTA-STS failures
| Code | Severity | Cause | Action |
|---|---|---|---|
sts-policy-fetch-error | High | Policy URL unreachable (HTTP 4xx/5xx) | Verify https://mta-sts.domain/.well-known/mta-sts.txt |
sts-policy-invalid | High | Policy content malformed | Validate with the MTA-STS Syntax Checker |
sts-webpki-invalid | High | HTTPS certificate invalid on MTA-STS host | Renew the certificate for mta-sts.domain |
MTA-STS failures mean senders cannot verify your TLS policy. Validate your full setup with the MTA-STS Record Checker.
DANE failures
| Code | Severity | Cause | Action |
|---|---|---|---|
tlsa-invalid | High | TLSA record does not match the certificate | Update with the DANE/TLSA Checker |
dnssec-invalid | Critical | Broken DNSSEC chain of trust | Verify with the DNSSEC Checker |
dane-required | High | DANE expected but no valid TLSA record found | Publish valid TLSA records for each MX |
A broken DNSSEC chain invalidates all DANE records. Treat dnssec-invalid as the highest priority fix.
Real-world use cases
These three scenarios come from actual TLS-RPT reports. Each shows how the analyzer identifies the problem and what to do next.
Incident 1: Expired certificate on a secondary MX
Symptom: Google reports 200 certificate-expired failures on mail2.example.com in 24 hours.
Root cause: The Let's Encrypt certificate on the secondary MX expired. The certbot cron job was broken.
Fix: Renew the certificate and verify the cron job to prevent recurrence.
Incident 2: Unreachable MTA-STS policy
Symptom: Microsoft flags sts-policy-fetch-error with HTTP 503 for example.com.
Root cause: The server hosting https://mta-sts.example.com/.well-known/mta-sts.txt went down during a maintenance window.
Fix: Restore the endpoint or switch to CaptainDNS MTA-STS hosting for managed high availability.
Incident 3: No TLS policy on a subdomain
Symptom: The report returns no-policy-found for billing.example.com.
Root cause: The subdomain receives email but has neither MTA-STS nor DANE configured.
Fix: Deploy MTA-STS with the MTA-STS Generator or DANE with the DANE/TLSA Generator.
Encountering a similar issue? Upload your report above to get the exact diagnosis.
FAQ
Q: What is a TLS-RPT report and how do I read it?
A TLS-RPT report is a JSON file sent daily by mail servers (Google, Microsoft, Yahoo) that deliver email to your domain. It lists TLS connection successes, failures, and failure codes. Reports arrive as .json.gz attachments. Upload them to the analyzer above for instant interpretation.
Q: Why am I receiving emails from noreply-smtp-tls-reporting@google.com?
Your domain has a TLS-RPT DNS record with a mailto: address. Google sends one report per 24-hour period covering all TLS connections from Gmail to your domain. This is expected behavior. These reports are your primary visibility into email encryption health.
Q: What is the difference between a TLS-RPT checker and a TLS-RPT report analyzer?
A TLS-RPT checker validates your DNS record at _smtp._tls.domain - the configuration. A TLS-RPT report analyzer reads the JSON report files you receive - the results. Use the TLS-RPT Record Checker for configuration, and this tool for report analysis.
Complementary tools
After analyzing your report, use these tools to fix issues and strengthen your configuration.
| Tool | Purpose |
|---|---|
| TLS-RPT Generator | Create or update your TLS-RPT DNS record |
| TLS-RPT Record Checker | Verify your TLS-RPT DNS configuration is live |
| TLS-RPT Syntax Checker | Validate record syntax before publishing |
| MTA-STS Record Checker | Confirm MTA-STS deployment and policy |
| DANE/TLSA Checker | Verify DANE TLSA records match certificates |
| Email Domain Audit | Full audit: SPF, DKIM, DMARC, MTA-STS, TLS-RPT |
Start with the Email Domain Audit for a complete overview of your domain's email security.
Useful resources
- RFC 8460 - SMTP TLS Reporting - the official TLS-RPT specification (IETF, 2018)
- RFC 8461 - MTA Strict Transport Security - the companion MTA-STS protocol
- RFC 7672 - SMTP Security via DANE - DANE authentication for SMTP transport
- Google Workspace - Configure TLS Reporting - step-by-step guide for Google Workspace admins