TLS-RPT (RFC 8460) lets a receiving domain request daily JSON reports on TLS connection successes and failures from sending servers. It is the visibility layer for MTA-STS and DANE deployments — without TLS-RPT, you deploy transport security blind. This article explains TLS-RPT, the report format, processing options, and how UK businesses use it to monitor their transport security posture.
TLS-RPT is the counterpart for transport security that DMARC aggregate reports are for authentication. A domain publishes a TLS-RPT DNS record pointing at a reporting address; compliant sending servers send daily JSON reports summarising their TLS connection outcomes when delivering mail to that domain.
Without TLS-RPT, you deploy MTA-STS or DANE and then have no way to know whether senders are actually reaching your server successfully. Are they downgrading to plaintext? Are DANE validations failing? Is a common forwarder silently breaking your policy? TLS-RPT reports answer these questions.
A single TXT record published at _smtp._tls.domain:
_smtp._tls.firm.co.uk. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"Two tags:
v=TLSRPTv1 — version. Must be first. Only defined version.rua= — reporting URI(s). Almost always mailto:. Multiple addresses separated by commas.That is it. Two tags, one record. Simple deployment.
Reports arrive as JSON (optionally gzipped) attached to an email. A trimmed example:
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-04-22T00:00:00Z",
"end-datetime": "2026-04-22T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "2026-04-22T00:00:00Z_firm.co.uk",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": ["version: STSv1","mode: enforce","mx: mail.firm.co.uk","max_age: 1209600"],
"policy-domain": "firm.co.uk",
"mx-host": ["mail.firm.co.uk"]
},
"summary": {
"total-successful-session-count": 247,
"total-failure-session-count": 0
}
}
]
}Each entry contains:
As of 2026, TLS-RPT is sent by:
TLS-RPT has broader adoption than forensic DMARC reports. For a UK business sending predominantly to UK and EU recipients, expect several reports per day covering most mail traffic.
Options:
Tools like parsedmarc include TLS-RPT processing. Ingest reports into a time-series database (InfluxDB, OpenSearch), visualise with Grafana.
For very small UK domains with few reports, manual inspection in a mailbox is possible. Not recommended at any meaningful scale — JSON is not human-friendly.
| Failure type | Cause | Action |
|---|---|---|
starttls-not-supported | Receiver did not advertise STARTTLS | Check mail server STARTTLS config |
certificate-host-mismatch | Cert does not match MX hostname | Reissue cert with correct SAN |
certificate-expired | Cert expired | Renew (automate with Let's Encrypt) |
certificate-not-trusted | Cert chain broken or untrusted CA | Fix cert chain configuration |
validation-failure | Generic TLS policy mismatch | Review specific policy |
dane-failure | TLSA record does not match presented cert | Update TLSA after cert change |
sts-policy-fetch-error | Cannot fetch MTA-STS policy file | Check HTTPS hosting |
sts-policy-invalid | Policy file malformed | Validate policy content |
sts-webpki-invalid | HTTPS cert on mta-sts host invalid | Renew mta-sts cert |
TLS-RPT is the third leg of the transport security tripod:
Deploying MTA-STS or DANE without TLS-RPT is like running a door lock without any way to check whether it was opened. TLS-RPT surfaces the real operational state.
A TLS-RPT dashboard typically shows:
certificate-expired failure).Good dashboards integrate TLS-RPT with DMARC data for a single-pane view of both authentication and transport health.
A typical TLS-RPT deployment on a UK business domain:
parsedmarc._smtp._tls.firm.co.uk IN TXT "v=TLSRPTv1; rua=mailto:address"When TLS-RPT reports show failures, the workflow is:
failure-details array in the JSON.openssl s_client or similar to reproduce the TLS handshake against your server.Persistent failures from one specific sender IP often indicate a stale forwarder or an older mail server that cannot negotiate modern TLS. Sometimes the only fix is coordinating with the sender to upgrade their infrastructure.
Q: Is TLS-RPT worth publishing if I do not have MTA-STS or DANE?
A: Yes — you still get visibility into STARTTLS success rates and any opportunistic TLS failures. The reports show "policy-type: none" for plain STARTTLS traffic but still report successes and failures. Useful baseline monitoring.
Q: Does TLS-RPT have privacy implications?
A: Minimal. Reports contain infrastructure data (IPs, hostnames, counts) but no message content or recipient addresses. GDPR implications are smaller than DMARC forensic reports.
Q: Can I point TLS-RPT at a third-party service's address?
A: Yes. Cross-domain RUA requires the service's domain to publish an authorisation record at yourdomain._report._tlsrpt.service.com. Commercial processors automate this.
Q: How frequent are TLS-RPT reports?
A: Daily per receiver per domain, typically. Some receivers send less frequently.
Q: What is the typical report volume?
A: For a UK SME, 5-15 reports per day. A small portion of email traffic generates a report each day from each major receiver.
Q: Can I ignore TLS-RPT success reports and alert only on failures?
A: Yes — most dashboards let you configure this. Success reports are a baseline; failures are the actionable signal. Alert on failures above a threshold.
Q: What does a typical TLS-RPT pass rate look like for a mature UK domain?
A: 99%+ TLS success. The remaining <1% is typically legacy senders or niche networks that cannot negotiate modern TLS.
Q: Does TLS-RPT tell me about plaintext deliveries?
A: Reports about MTA-STS enforce policies tell you about failures to use TLS. For domains not publishing MTA-STS, reports under "policy-type: none" simply show negotiation outcomes — all senders that tried STARTTLS get a success/failure count.
Q: Is TLS-RPT affected by DNSSEC?
A: The TLS-RPT record is a DNS TXT that benefits from DNSSEC protection but does not require it. Even without DNSSEC, TLS-RPT works — receivers fetch the reporting address and send reports.
Q: What if a major receiver stops sending me TLS-RPT reports?
A: Usually indicates a policy change at the receiver or a gap in mail flow. Investigate if it persists for more than a week. Reports resume automatically when mail traffic resumes.
Q: Can I correlate TLS-RPT failures with specific mail events?
A: Partially. Reports aggregate by day and source IP, so individual message correlation is not possible. For specific incident investigation, combine with your own mail server logs.
Q: Does TLS-RPT overlap with DMARC aggregate reports?
A: They cover different layers. DMARC reports authentication; TLS-RPT reports transport. A well-configured UK business publishes both and integrates the data in a single dashboard.
Q: What happens if I forget to set up a processing mailbox?
A: Reports bounce or pile up in a neglected inbox. Nothing breaks operationally, but you lose visibility. Set up processing before publishing the record.
Q: Is TLS-RPT being superseded by anything newer?
A: No — it is stable. The protocol is well-specified and works well alongside MTA-STS and DANE. Future development is in broader adoption, not replacement.
Q: How do I estimate the storage requirements for TLS-RPT reports?
A: For a UK SME, a few megabytes per month. For enterprise with multiple domains, tens of megabytes. Storage is rarely a concern; processing and visualisation are.
Q: Are there UK public sector requirements for TLS-RPT?
A: NCSC Mail Check scores TLS-RPT positively. Central government domains are expected to publish it as part of the GOV.UK mail policy. NHS suppliers under DTAC should have it.
Q: Does TLS-RPT work if my MX is hosted by a third-party provider?
A: Yes — you publish the TLS-RPT record at your domain; reports arrive at the address you specify. Whether the provider's infrastructure correctly honours MTA-STS or DANE is what drives the report data.
Q: Can I combine TLS-RPT and DMARC report inboxes?
A: Yes — one mailbox can receive both, processed by the same service. Most UK DMARC services handle both on a single ingestion endpoint.
Q: Does publishing TLS-RPT have any negative side effects?
A: No. It is purely observational. Publishing invites reports; it does not change enforcement behaviour. No risk to publish.
Q: How do UK banks and financial services use TLS-RPT?
A: Typically as part of enterprise DMARC/TLS monitoring, deployed alongside DANE. Used to evidence transport security controls for FCA and similar regulatory audits.
Q: Can I receive TLS-RPT for subdomains?
A: Yes. Each subdomain that publishes its own _smtp._tls record receives its own reports. Alternatively, the parent's TLS-RPT applies if no subdomain record exists.
Q: Is there a way to trigger an immediate TLS-RPT report?
A: No. Reports are batched daily by receivers. There is no on-demand reporting mechanism.
Q: What percentage of my outbound mail traffic generates TLS-RPT feedback?
A: For a UK business sending mostly to Gmail, Microsoft 365, Yahoo and Fastmail users, the majority (perhaps 70-80%) of traffic is covered by TLS-RPT reports. Niche and smaller receivers generate no reports. Sufficient sample size for meaningful monitoring.
Q: Can TLS-RPT reports include the actual TLS cipher used?
A: The spec allows it but most receivers include only aggregate failure data. For cipher-level detail, your own mail server logs are better.
Q: Is TLS-RPT worth the effort for a small UK business?
A: Yes if you have deployed MTA-STS or DANE. No point enforcing transport security without visibility into whether it is working. For plain STARTTLS deployments, TLS-RPT is lower priority but still useful.
Q: Does TLS-RPT cost anything?
A: The DNS record and ingestion mailbox cost nothing. Processing can be free (self-hosted, or free tiers of hosted services) or paid (enterprise DMARC/TLS platforms). Most UK SMEs use free or entry-paid tiers.
Q: What alerts should I set up for TLS-RPT?
A: Typical alerts: any certificate-expired failure (urgent), any dane-failure above a threshold (check cert rotation), any new persistent sts-policy-fetch-error (HTTPS issue), success rate dropping below 99%.
Q: How often should I review TLS-RPT data?
A: Weekly for most UK businesses. Monthly at minimum. Integrating alerts means you do not need to check proactively — the dashboard notifies you when something changes.
Q: Can I use TLS-RPT without MTA-STS or DANE?
A: Yes. The reports still summarise opportunistic STARTTLS outcomes. Less actionable than reports tied to a specific policy, but still reveals TLS negotiation success rates.
Q: Does TLS-RPT share anything sensitive about my mail infrastructure?
A: Report contents include your MX hostnames, policy summaries and source IPs of senders. This is all public information; no sensitive details are exposed.
Q: Which receivers send the richest TLS-RPT data?
A: Google and Microsoft both send detailed reports including specific failure types, failure details and counts per source. Fastmail and Yahoo send less detailed but adequate reports. Smaller receivers vary.
Q: Can TLS-RPT reveal active attacks on my transport security?
A: Indirectly. A sudden spike in certain failure types (particularly validation-failure from unexpected sources) can indicate downgrade attempts. More commonly, failures reveal misconfigurations rather than attacks.
Q: Does TLS-RPT require my mail server to change?
A: No. Your mail server continues operating normally. TLS-RPT is entirely configuration at the DNS and processing-pipeline level. No mail server change needed.
Q: How do TLS-RPT and log-based TLS monitoring differ?
A: Your own mail server logs show inbound TLS details (what senders negotiated with you). TLS-RPT shows outbound TLS details (how senders negotiated with you from their perspective, including failures they saw). Complementary views of the same handshakes.
Q: Is TLS-RPT adoption expected to continue growing?
A: Yes. As MTA-STS and DANE adoption rise, TLS-RPT adoption rises in parallel — publishing one without the other is operationally incomplete. Expect gradual maturation across UK business email in 2026 and beyond.
Q: Can I use TLS-RPT reports for regulatory audit evidence?
A: Yes. Reports demonstrate ongoing monitoring of transport security, which is an expected control in PCI DSS, ISO 27001, Cyber Essentials Plus, and various sector frameworks. UK auditors familiar with email security routinely ask for report samples.
Q: What happens if both rua addresses in a TLS-RPT record fail?
A: Reports are lost. Senders do not retry or buffer. Critical to keep both addresses (if multiple) operational. Single-address deployments are simpler but remove redundancy.
Q: Is there a lightweight "monitoring only" deployment for small UK domains?
A: Yes — publish TLS-RPT with a single RUA address pointing at a processor's free tier. Receive reports, visualise, alert on failures. Minimal overhead, high value.
Q: How does TLS-RPT relate to compliance with UK GDPR?
A: Indirectly supportive. UK GDPR requires appropriate technical measures against unauthorised access; TLS in transit is one such measure; TLS-RPT provides evidence that the measure is operating as intended. Useful to cite in data protection impact assessments.
Q: Can Mail Hardener (the UK-accessible processor) receive TLS-RPT for multiple domains centrally?
A: Yes. A single Mail Hardener tenant ingests both DMARC and TLS-RPT for many domains; reports are segregated by domain in the dashboard. Standard pattern for UK businesses managing a portfolio of domains.
Q: What is the minimum useful TLS-RPT deployment for a new UK business setting up email?
A: Publish the DNS record with RUA pointing at a free-tier DMARC/TLS processor. Start receiving reports. Graduate to paid tiers and richer dashboards as mail volume justifies the cost. Rarely wait to deploy — it is low-effort for high visibility value.
Q: Does TLS-RPT work for UK mail servers hosted on cloud providers (AWS, Azure, GCP)?
A: Yes — TLS-RPT is agnostic of where the mail server runs. Reports arrive at whatever RUA address you configure. Cloud-hosted UK mail servers face the same TLS-RPT deployment as any other.
Q: Is TLS-RPT required for Cyber Essentials Plus certification?
A: Not explicitly required, but evidence of transport security monitoring supports the controls that CE Plus does require. UK auditors appreciate seeing TLS-RPT deployed as it demonstrates active monitoring.
Q: What is the relationship between TLS-RPT and NCSC Mail Check?
A: NCSC Mail Check for UK public sector domains checks whether TLS-RPT is published and monitors the reports. For private sector, use commercial alternatives that provide similar monitoring and scoring.
Q: Can TLS-RPT reports ever be used by attackers?
A: Only in narrow cases. The reports reveal which senders connect to your mail infrastructure — information that is already largely visible to anyone observing DNS. Not typically a meaningful attacker-useful leak.
Q: Is there a dashboard tool specifically designed for UK public sector TLS-RPT monitoring?
A: Yes — NCSC Mail Check. For private sector UK businesses, the commercial tools (Mail Hardener, Red Sift, dmarcian) are the equivalents.