CyberFurl can load analytics only after you opt in. Core product features work without analytics consent.
What is TLS-RPT? SMTP TLS Reporting Explained — Setup & Analysis Guide
Email Security
TLS-RPT Explained: Get Daily Visibility Into SMTP TLS Failures on Your Inbound Email
TLS-RPT (SMTP TLS Reporting, RFC 8460) delivers daily JSON reports from major email senders about TLS encryption failures on your inbound email. It is the essential telemetry layer for safe MTA-STS and DANE deployment — and the only way to detect silent inbound mail drops caused by certificate errors or STARTTLS failures. Learn how to publish the DNS record, parse reports, and act on failures.
TLS-RPT (SMTP TLS Reporting, RFC 8460) delivers daily JSON reports from major email senders about TLS encryption fa…
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting) is a DNS-published standard (RFC 8460) that enables domain owners to receive daily reports from sending mail servers about the success and failure of TLS-encrypted SMTP connections to their inbound mail infrastructure. It is the visibility layer that makes MTA-STS and DANE safe to enforce.
"policy-type": "sts", "policy-string": ["…"]
Without TLS-RPT, when a sender's MTA refuses to deliver email because your MX host's TLS certificate expired or your policy file is unreachable, the message is silently dropped. You receive no bounce, no error, no notification. The email simply never arrives — and you have no way to know. TLS-RPT fixes this by requiring senders to report those failures back to you daily in structured, parseable JSON.
A TLS-RPT report is a gzip-compressed JSON document following the RFC 8460 schema. Each report covers 24 hours of connection attempts from one sending organization to your domain. Key fields:
| Field | What it shows |
|-------|--------------|
| organization-name | The sending provider (e.g., "Google LLC") |
| date-range | The 24-hour window the report covers |
| policies | Which policy was active (MTA-STS or DANE) |
| summary.total-successful-session-count | Number of successful TLS connections |
| summary.total-failure-session-count | Number of failed TLS connection attempts |
| failure-details[].result-type | Specific failure reason (see below) |
| failure-details[].failed-session-count | How many connections hit this failure |
| failure-details[].receiving-mx-hostname | Which of your MX hosts failed |
Common failure result types:
starttls-not-supported — Your MX host did not offer STARTTLS
certificate-expired — Your MX host's TLS certificate is expired
certificate-not-trusted — Your MX host uses a self-signed or untrusted certificate
validation-failure — Certificate hostname does not match the MX record
sts-policy-fetch-error — Sender could not retrieve your MTA-STS policy file
sts-policy-invalid — Your policy file has a syntax error or invalid MX hostname
How TLS-RPT pairs with MTA-STS and DANE
TLS-RPT is specifically designed to be the feedback mechanism for MTA-STS and DANE:
MTA-STS + TLS-RPT: MTA-STS in testing mode reports failures via TLS-RPT without blocking delivery. This is how you safely audit your TLS posture before enforcing. Only advance to mode: enforce after TLS-RPT reports confirm zero failures.
DANE + TLS-RPT: DANE enforcement is binary — if the TLSA record does not match the certificate, the sender refuses to deliver. TLS-RPT provides the only external signal that DANE enforcement is causing failures. Without it, DNSSEC-signed TLSA record mismatches are invisible to the domain owner.
Without TLS-RPT, deploying MTA-STS in enforce mode or publishing DANE TLSA records is operationally reckless — you are enforcing policies that could silently drop inbound email with no way to detect failures.
Setting up the TLS-RPT DNS record
TLS-RPT is published as a single DNS TXT record. The record name must be exactly _smtp._tls.yourdomain.com — this is a strict requirement of RFC 8460.
DNS Record / Config
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
For automated HTTPS ingestion:
DNS Record / Config
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=https://ingest.yourplatform.com/tls-rpt"
Multiple reporting endpoints are supported (separate with commas):
DNS Record / Config
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls@example.com,https://platform.com/tls"
Critical: do not publish this record at the root domain (example.com) or at _tls.example.com — it must be at _smtp._tls.example.com. Incorrect prefix = reports never delivered.
Common TLS-RPT report patterns
Baseline success pattern: The healthy state shows 100% total-successful-session-count with zero total-failure-session-count from all major senders. This is what you want to see before advancing to MTA-STS enforce mode.
Certificate expiry pattern: Sudden spike in certificate-expired failures from all senders on the same date. Indicates your MX host's TLS certificate expired. Immediate action: renew the certificate.
Policy file unavailable: Multiple sts-policy-fetch-error entries from senders. Indicates your MTA-STS policy file HTTPS endpoint is down or returning errors. Check the web server health on your mta-sts subdomain.
MX hostname mismatch: certificate-not-trusted or validation-failure from senders after an MX record change. Your MTA-STS policy file still lists old MX hostnames. Update the policy file and increment the DNS id.
Isolated sender failures: Failures only from one specific sender ASN while others succeed. Often a bug or misconfiguration on the sender side — monitor but do not rush to change your configuration.
Tools that parse TLS-RPT reports
Raw TLS-RPT JSON is parseable but not human-friendly at scale. Useful approaches:
CyberFurl: Automated ingestion, aggregation, and plain-English failure diagnostics
DMARC processors: Several DMARC reporting platforms also ingest TLS-RPT
Webhook + SIEM: Route HTTPS reports into your security information and event management platform
The goal of tooling is to translate result-type: sts-policy-fetch-error, failed-session-count: 1204 into an actionable alert: "Your MTA-STS policy file returned a 503 error from 14:00-15:00 UTC yesterday — 1,204 inbound connections from Microsoft could not validate your policy."
How to implement TLS-RPT
step 1─────────>
step 2─────────>
step 3─────────>
step 4─────────>
step 5─────────>
step 6
1. Step 1:Add a TXT record at _smtp._tls.yourdomain.com (not at the root domain, not at _tls.yourdomain.com — the prefix must be _smtp._tls). Example: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com — If you want automated processing, use an HTTPS endpoint instead: v=TLSRPTv1; rua=https://ingest.yourtool.com/tls-rpt. The mailto: address must be monitored — routing it to a blackhole defeats the purpose.
2. Step 2:Configure the receiving endpoint to handle gzip-compressed JSON reports following the RFC 8460 schema. If using a mailto: address, set up a dedicated mailbox and an automated parser. If using HTTPS, ensure the endpoint can handle POST requests with gzip content. Do not route to a shared human-readable inbox — TLS-RPT reports require machine processing at scale. CyberFurl and other platforms handle this automatically.
3. Step 3:Publish your MTA-STS policy file with mode: testing simultaneously with TLS-RPT. In testing mode, senders report TLS failures but still deliver email. TLS-RPT captures all failures that enforce mode would have blocked — this is your pre-enforcement view of your TLS posture across the real sender ecosystem.
4. Step 4:Review reports daily or weekly. Look for recurring failure patterns: certificate errors on MX hosts, unreachable policy files, hostname mismatches. Cluster failures by source ASN to distinguish between systemic issues (e.g., your expired cert) vs isolated senders with bugs. Focus on failure types from high-volume senders (Gmail, Microsoft) first.
5. Step 5:Fix every failure category identified in TLS-RPT reports. Common fixes: renew expired certificates on MX hosts, fix hostname mismatch between MX DNS and certificate SANs, restore unreachable policy file endpoints, update policy file MX list when MX records change. Only advance MTA-STS to mode: enforce when TLS-RPT reports show zero failures for at least 2 consecutive weeks.
6. Step 6:TLS-RPT is not a one-time audit — it requires continuous monitoring. Configure automated alerting for: sudden spikes in failure count, new failure types (indicates infrastructure change), drop in report volume (may indicate reporting endpoint issue or DNS change). Set alert thresholds and ensure the team receiving alerts has an incident runbook for common TLS failure types.
Technical Architecture
TLS-RPT (RFC 8460) provides structured telemetry for encrypted email transit:
Policy Discovery: Sending MTA queries for MTA-STS or DANE policies AND simultaneously queries _smtp._tls.yourdomain.com for the TLS-RPT record.
Delivery Attempt: Sender attempts SMTP connection with TLS validation.
Data Aggregation: Sender logs each connection result (success, failure type, affected MX).
Daily Report Delivery: Sender compresses 24 hours of data into a gzip JSON report and delivers it to the rua endpoint.
DNS Record / Config
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
Common Misconfigurations
Wrong DNS prefix: Publishing at example.com or _tls.example.com instead of _smtp._tls.example.com — reports are never delivered
Missing mailto: or https:// prefix in rua: rua=tls-reports@example.com is invalid; must be rua=mailto:tls-reports@example.com
Unmonitored inbox: Publishing a mailto: address that goes to an unmonitored mailbox — the reports arrive but no one acts on them, defeating the purpose
Security Risks of Ignoring TLS-RPT
Silent inbound mail drops: Expired certificate on MX host + MTA-STS enforce = all compliant senders refuse delivery — zero bounce, zero notification without TLS-RPT
Downgrade attack blindness: An active STARTTLS stripping attack shows up as a spike in starttls-not-supported failures — TLS-RPT is the only mechanism that surfaces this attack
Enforce misconfiguration: Switching MTA-STS to enforce without clean TLS-RPT reports guarantees lost emails from major senders
Compliance Impact
GDPR Article 32: TLS-RPT provides auditable proof that your email transport encryption is functioning — required for demonstrating "appropriate technical measures" for data in transit
HIPAA: For covered entities, TLS-RPT documents that ePHI transmitted via email was protected by enforced TLS — reducing breach liability
Federal guidance (BOD 18-01 successor): CISA's updated email security framework includes TLS-RPT as part of the recommended email authentication stack
Best Practices for TLS-RPT in 2025/2026
Deploy before MTA-STS, not after — TLS-RPT is a prerequisite for safe MTA-STS testing, not a post-deployment add-on
Use HTTPS endpoints for production — mailto: works for getting started, but machine-readable webhooks scale better and integrate with alerting pipelines
Alert on failure spikes, not individual reports — set thresholds and respond to patterns, not noise
Correlate with DMARC reports — DMARC RUA + TLS-RPT together give a complete picture of both outbound identity spoofing and inbound transport security
Tools to check your TLS-RPT
Check whether your TLS-RPT DNS record is correctly published and formatted as part of a broader email security audit via CyberFurl's security report. The correct prefix (_smtp._tls), valid rua= format, and active reporting endpoint are the three things to validate. For validating your full MTA-STS and TLS posture together, use the MTA-STS checker. For continuous monitoring and automated report ingestion, pair both tools with Email Security monitoring.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl automatically ingests daily TLS-RPT reports from Google, Microsoft, Yahoo, and other major senders, translating raw JSON failure codes into plain-English diagnostics with direct links to the affected infrastructure. Security teams see immediately when certificate errors, policy file outages, or MX mismatches are causing inbound delivery failures.
TLS-RPT is not mandated by law independently, but it is a de facto requirement if you deploy MTA-STS or DANE. Without TLS-RPT, you have no visibility into whether your transport enforcement is causing delivery failures. If you publish MTA-STS in testing mode without TLS-RPT, testing mode is useless — you cannot see the failures it is designed to surface. Federal agencies implementing CISA's modernized email security guidance are expected to implement TLS-RPT alongside MTA-STS. For any organization that cares about inbound mail reliability and encryption compliance, TLS-RPT is essential.
Where are TLS-RPT reports delivered?
TLS-RPT reports are delivered to the endpoint(s) specified in the rua= tag of your TLS-RPT DNS record. You can specify a mailto: address (e.g., rua=mailto:tls-reports@example.com) or an HTTPS webhook endpoint (e.g., rua=https://reports.example.com/tls-rpt). Major senders — Gmail, Microsoft, Yahoo, Comcast — aggregate their connection data daily and send compressed JSON reports to your specified endpoint. Reports are gzip-compressed JSON following the RFC 8460 schema. A mailto: address is simpler to set up; an HTTPS endpoint is better for automated processing and integration with dashboards.
How large are TLS-RPT reports?
Individual TLS-RPT reports from each sender are typically small (a few KB to a few hundred KB, gzip-compressed), but a high-volume domain receiving reports from dozens of large senders can accumulate several MB per day. The reports are structured JSON documents, not human-readable text — automated parsing and aggregation are required to make sense of the data at scale. Gmail, Microsoft, and Yahoo are typically the largest contributors by volume. Each report covers 24 hours of connection data for a specific sender-to-recipient domain pair.
Can I forward TLS-RPT alerts to Slack?
Yes, but it requires an intermediate processing layer. TLS-RPT reports arrive as gzip-compressed JSON files — not Slack-friendly messages. The workflow: set up an HTTPS endpoint or email parser to receive reports → parse the JSON and extract failure counts and failure types → trigger a Slack (or PagerDuty, email, etc.) alert when failures exceed a threshold (e.g., any new failure type or a spike in failure count). Several open-source TLS-RPT parsing tools exist, and platforms like CyberFurl automate the ingestion, parsing, and alerting pipeline so you can route actionable notifications directly to your team's channel.
What is TLS-RPT?
TLS-RPT (SMTP TLS Reporting) is a DNS-published email security protocol (RFC 8460) that enables domain owners to receive daily reports from sending mail servers about the success and failure of TLS-encrypted connections to their inbound MX hosts. It works by publishing a DNS TXT record at _smtp._tls.yourdomain.com with a reporting endpoint. Senders like Gmail, Microsoft, and Yahoo read this record and send aggregated JSON reports daily showing how many connections succeeded, how many failed, and exactly why they failed (certificate error, policy mismatch, STARTTLS failure, etc.). TLS-RPT is the operational telemetry layer that makes MTA-STS and DANE deployments safe to manage.
How do I parse TLS-RPT reports automatically?
TLS-RPT reports arrive as gzip-compressed JSON files following the RFC 8460 schema. For automated parsing: if you used a mailto: rua address, configure the receiving mailbox with an automated parser that extracts the JSON attachment, decompresses it, and stores the structured data. If you used an HTTPS rua endpoint, your web server receives JSON POST requests that can be processed directly. Several open-source tools such as tlsrpt-parse exist on GitHub for custom pipelines. At minimum, extract and monitor three fields: total-successful-session-count, total-failure-session-count, and failure-details[].result-type. For teams that do not want to build parsing infrastructure, platforms like CyberFurl ingest reports automatically and provide parsed dashboards with actionable alerts.
Which major senders send TLS-RPT reports to my domain?
Google (Gmail and Google Workspace), Microsoft (Exchange Online / Microsoft 365), Yahoo Mail, Apple iCloud Mail, and Comcast all send TLS-RPT failure reports to correctly configured domains. These five providers represent the majority of inbound email volume for most organizations, making their TLS-RPT data the most operationally significant signal. Absence of a report from a particular sender does not necessarily mean TLS is working correctly — that sender may simply not implement TLS-RPT. However, absence of reports from Google and Microsoft specifically should trigger investigation into whether your _smtp._tls DNS record is correctly published and whether the rua= address is reachable.
