TLS-RPT — SMTP TLS Reporting

The visibility problem TLS-RPT solves

SMTP TLS issues are uniquely invisible from the recipient's perspective. When a sending MTA encounters a TLS problem delivering to your domain — an expired certificate on an MX host, a STARTTLS-stripping attacker, an MTA-STS policy mismatch, an invalid DANE TLSA record — the failure happens entirely on the sender's side, before any mail arrives at your servers. You have no log entries to inspect, no SMTP transcript to analyze, no symptom in your own infrastructure. The mail simply doesn't arrive, or arrives in plaintext when it should have been encrypted, and you have no way to know.

This invisibility becomes operationally dangerous as soon as you deploy MTA-STS in enforce mode. Under enforce, sending MTAs that fail TLS verification will refuse to deliver the message — legitimate mail bounces. Without TLS-RPT, the only signal you receive is angry users complaining that their email isn't arriving, days after the failure window started. The testing → enforce rollout sequence is fundamentally a TLS-RPT-driven process: publish the policy in testing mode, monitor TLS-RPT reports for 2-4 weeks, fix every failure category that appears in reports, then advance to enforce.

The same applies to DANE. Without TLS-RPT, a misconfigured TLSA record or a DNSSEC validation failure causes silent delivery loss with no diagnostic signal at the receiver. TLS-RPT reports DANE failures with the same structure as MTA-STS failures, identifying TLSA-specific result-types like tlsa-invalid and dnssec-invalid.

How TLS-RPT works — the reporting flow

TLS-RPT is operationally simple compared to most email security protocols: one DNS TXT record, no infrastructure, no certificates, no policy file. Sending MTAs that support TLS-RPT check for the record before delivering mail to your domain; if present, they aggregate session statistics throughout the day and submit a JSON report at the end of the 24-hour reporting window.

Reports arrive once per 24-hour period from each sender that supports TLS-RPT. A typical domain receiving inbound mail from Gmail, Microsoft 365, and a handful of corporate senders sees 5-15 reports per day. The first report typically arrives 24-48 hours after the TXT record is published, with Google usually being the first to deliver one.

The DNS TXT record

The JSON report — anatomy field by field

The TLS-RPT report is a JSON document, gzip-compressed for transport. Files arrive as .json.gz attachments (email transport) or as gzipped POST bodies (HTTPS transport) with media type application/tlsrpt+gzip. Below is a real-shape report with annotations on every field — the structure most documentation glosses over.

Reports without failures still arrive — they're not just error reports. The summary block tells you how many TLS sessions succeeded, which is useful for tracking overall sender volume and confirming MTA-STS policy is being observed. The failure-details array is what you focus on when debugging.

The 11 result-types — what each one means and how to fix it

RFC 8460 defines 11 standardized failure types in three categories: certificate failures (cert problems on the receiving MX), STARTTLS failures (TLS negotiation problems), and policy failures (MTA-STS or DANE policy issues). Most documentation lists 3-4 of these. Below is the complete set with the operational fix for each — the table that actually closes the diagnostic loop.

Diagnostic workflow — failure type to root cause to fix

When a TLS-RPT report shows non-zero failures, the result-type is the diagnosis starting point. Below is the operational triage flow most teams need: which result-types are typically symptomatic of which underlying conditions, ordered by frequency in production environments.

rua= endpoint patterns — mailto vs HTTPS vs multi

The rua= directive supports three deployment patterns. Choice depends on report volume, processing requirements, and operational preferences. None is wrong; each has trade-offs.

Sender support matrix — who actually sends TLS-RPT reports

Despite TLS-RPT being on the books since 2018, sender support is uneven. Below is the empirical sender matrix as of May 2026, based on URIports' aggregated report ingestion data and report metadata inspection across hundreds of receiving domains. The list is roughly ordered by volume of reports generated.

TLS-RPT vs DMARC reports — same architecture, opposite direction

If you're already operating DMARC aggregate (RUA) reporting, TLS-RPT will feel architecturally familiar. The protocols use the same DNS TXT + rua= URI pattern, the same daily 24-hour aggregation window, the same gzipped-XML/JSON format approach. They're complementary, not redundant — they cover different layers.

Both should be deployed. DMARC tells you who's sending as your domain; TLS-RPT tells you whether the senders are encrypting to your servers. Without DMARC RUA, you don't know who's spoofing you. Without TLS-RPT, you don't know whether your transport security is working. Mature email security postures have both deployed and both reports actively reviewed.

Operational considerations for the rua= mailbox

If using rua=mailto:, the receiving mailbox needs specific considerations that don't apply to typical mailboxes. Misconfigurations here are responsible for "TLS-RPT is set up but I never see any reports" investigations.

TLS-RPT in Cloud Server for Email's managed infrastructure

For clients on managed PowerMTA + MailWizz infrastructure, TLS-RPT is configured alongside MTA-STS during the day 1-3 onboarding sequence. The patterns we use across most accounts:

• Hosted HTTPS endpoint by default. Each client domain gets rua=https://<cse-tlsrpt-endpoint> pointing to our managed ingestion. Reports are parsed, normalized, and aggregated across all client domains in a single dashboard. Avoids the mailbox quota and attachment-handling concerns above.
• Pre-MTA-STS deployment. TLS-RPT goes live before MTA-STS even in testing mode. This way the first 7 days produce baseline data on TLS issues before adding policy-related failures into the report stream. Helps distinguish baseline TLS issues (bad cert on a secondary MX) from policy-introduced issues.
• First-position endpoint. Where clients want both an internal mailbox and our managed endpoint, the rua= list is structured with our endpoint first to ensure Microsoft reports route to analytics. The internal mailbox receives forwarded copies via our processing layer if needed.
• Weekly review of failure-details across all clients. Aggregate failure-type counts per client domain are reviewed weekly. Most domains show zero or single-digit failures per week; any sustained pattern triggers investigation. Persistent certificate-expired on a specific MX = renewal automation issue. Persistent starttls-not-supported = secondary MX misconfiguration.
• Proactive certificate expiration monitoring. Independent of TLS-RPT, our managed infra monitors cert expiration for every MX host across client domains. The combination ensures issues are caught before TLS-RPT reports them — TLS-RPT becomes confirmation rather than first detection.
• Cross-correlation with DMARC aggregate reports. Both report streams flow into the same dashboard for clients running both. Patterns across both layers (e.g., DMARC failures correlated with TLS issues at specific senders) surface attack patterns that neither protocol catches alone.

Auditing your TLS-RPT — practical workflow

Related concepts

• MTA-STS — the policy mechanism that enforces TLS for inbound mail. TLS-RPT is its companion reporting layer.
• DANE/TLSA — alternative transport-security mechanism using DNSSEC. TLS-RPT also reports DANE failures with policy-type: tlsa. (Coming soon)
• STARTTLS — the SMTP TLS upgrade extension whose failures are reported via starttls-not-supported and validation-failure result-types. (Coming soon)
• DNSSEC — required for DANE; failures appear in TLS-RPT as dnssec-invalid. (Coming soon)
• DMARC — message-authentication reporting; same architecture, opposite direction. Both should be deployed.
• SPF, DKIM — message-authentication; complementary to TLS-RPT's transport-security layer.

Frequently asked questions

What is TLS-RPT and why does it exist?

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a feedback mechanism by which sending mail servers share daily reports about TLS connection success and failure when delivering to your domain. It exists because TLS-related delivery problems (expired certificates, STARTTLS stripping, MTA-STS policy violations, DANE failures) are otherwise invisible to the recipient — the receiver doesn't know that legitimate mail bounced because of a TLS issue at the sender's end. TLS-RPT closes that gap with structured JSON reports listing what worked, what failed, and why. It's the companion protocol to MTA-STS (RFC 8461) and DANE (RFC 7672) — published by the same authors at the same time as MTA-STS in September 2018.

How do I set up TLS-RPT?

Publish a single DNS TXT record at _smtp._tls.example.com containing v=TLSRPTv1; rua=mailto:tls-reports@example.com (or rua=https://endpoint.example.com/tlsrpt for HTTPS POST delivery). Both transports are allowed. The dedicated mailbox or HTTPS endpoint must accept incoming reports; if mail bounces from the rua address or the HTTPS endpoint returns errors, sending MTAs may stop attempting reports after a few failed deliveries. Verify with dig +short TXT _smtp._tls.example.com and you're done — no other infrastructure required. Reports start arriving 24-48 hours after publication, with Google typically the first sender to deliver one. Most domains receive 5-15 reports per day depending on inbound mail volume.

What's the difference between TLS-RPT and DMARC reports?

Different layers, different directions, similar architecture. DMARC RUA reports flow from receivers to senders — they tell you who claimed to send as your domain and whether SPF/DKIM authenticated. TLS-RPT reports flow from senders to receivers (the opposite direction!) — they tell you whether senders successfully encrypted mail to your servers. DMARC verifies who sends; TLS-RPT verifies how mail is transported. Both use DNS TXT records with rua tags pointing to mailto: or https: endpoints, both produce daily JSON reports, both support multiple aggregation endpoints. They're complementary, not redundant — production deployments need both for full email security visibility.

Which sending MTAs actually send TLS-RPT reports?

Sender support is uneven. The largest TLS-RPT report sources by volume in 2026 are: Google/Gmail (#1, supported since April 2019), Microsoft 365 (#2), Comcast (#3), Mail.ru (#4), and Mimecast (#5). Most other major providers either don't send TLS-RPT reports or send them inconsistently. Importantly, Microsoft has a documented bug: it sends reports only to the first rua= endpoint listed in the DNS record, ignoring subsequent endpoints. If you list multiple rua= URIs hoping for redundancy, only the first one receives Microsoft's reports. Reports from other senders behave per RFC and may attempt all listed endpoints. The practical implication: put your most important rua= first in the comma-separated list.

What are the 11 TLS-RPT failure result-types?

RFC 8460 defines 11 failure types in 3 categories. Certificate failures: certificate-host-mismatch (cert hostname doesn't match MX), certificate-expired (cert past validity), certificate-not-trusted (cert chain not trusted by sender). STARTTLS failures: starttls-not-supported (MX doesn't advertise STARTTLS), validation-failure (general TLS handshake failure). Policy failures: sts-policy-fetch-error (couldn't retrieve MTA-STS policy), sts-policy-invalid (policy syntax invalid), sts-webpki-invalid (HTTPS cert at policy host invalid), tlsa-invalid (DANE TLSA record invalid), dnssec-invalid (DNSSEC validation failed for DANE), dane-required (DANE was expected but TLSA records missing). Each result-type has a specific operational fix; the report tells you exactly which condition occurred at which MX, with counts.

Can I send TLS-RPT reports to an HTTPS endpoint instead of email?

Yes. The rua= directive supports both mailto: and https: schemes. HTTPS delivery is preferred for high-volume domains because email-based reporting can suffer from the report itself being subject to TLS issues, gzip-decompression overhead in mail clients, and 10MB report-size limits at receiving mailservers. The HTTPS pattern: rua=https://reports.example.com/v1/tlsrpt — the sender POSTs the gzip-compressed JSON report to the URL with Content-Type application/tlsrpt+gzip. You can list multiple endpoints separated by commas: rua=mailto:tls-reports@example.com,https://reports.example.com/v1/tlsrpt. Most TLS-RPT analytics platforms (URIports, dmarcian, EasyDMARC) provide HTTPS ingestion endpoints.

How is the TLS-RPT JSON report structured?

Top-level fields: organization-name (sender's org name), date-range (start-datetime/end-datetime, 24h UTC), contact-info (sender's contact email), report-id (unique identifier, often timestamp_domain), and policies (array). Each policy entry has policy (with policy-type 'sts'/'tlsa'/'no-policy-found', policy-string array of policy lines, policy-domain), summary (total-successful-session-count, total-failure-session-count), and failure-details (array of result-type, sending-mta-ip, receiving-mx-hostname, failed-session-count, plus optional failure-reason-code and additional-information). Reports are typically gzip-compressed (.json.gz extension, application/tlsrpt+gzip media type). The compressed format keeps reports under the 10MB receiver limit common in mail systems.

What happens if my TLS-RPT mailbox bounces?

Sending MTAs that try to deliver TLS-RPT reports to a mailbox that bounces or rejects the message will eventually give up after several attempts. Once a sender has stopped attempting reports for your domain, they may not resume immediately even after the mailbox is fixed — you can lose visibility into TLS issues for days or weeks. Best practices: use a dedicated mailbox (tls-reports@yourdomain.com), not a personal address; configure the mailbox to accept large attachments (5-10MB compressed JSON files); ensure no auto-responder, no out-of-office, no spam filtering that might reject legitimate reports; monitor delivery to that mailbox separately. For high-volume domains, HTTPS endpoints are more reliable than mailto: because they don't depend on the very TLS infrastructure being monitored.