TLS-RPT Explained: SMTP TLS Reporting (2026)

TLS-RPT is the reporting layer that tells you when encrypted email delivery to your domain succeeds or fails. If you have deployed — or plan to deploy — MTA-STS or DANE to enforce TLS, you have a blind spot: when a sender cannot establish a secure connection and a message is delayed or refused, that failure is invisible to you. TLS-RPT closes that gap by publishing a DNS record that asks senders to mail you daily reports on their TLS connection outcomes. This guide explains what TLS-RPT is, how the TLS-RPT record works, the TLS-RPT syntax with an example, and how to use SMTP TLS reporting in practice. It pairs directly with MTA-STS in our email security toolkit.

What is TLS-RPT?

TLS-RPT stands for SMTP TLS Reporting, defined in RFC 8460. It lets a receiving domain publish a DNS record advertising where senders should deliver reports about the success and failure of their TLS-encrypted SMTP connections. TLS-RPT does not enforce anything itself — it is purely the feedback channel for the enforcement mechanisms, MTA-STS and DANE. Its whole value is visibility: it turns silent TLS failures into actionable daily data so you can fix a misconfiguration before it quietly blocks mail.

How TLS-RPT works

1. You publish a TXT record at _smtp._tls.yourdomain.com naming a reporting destination.
2. A TLS-RPT-aware sender reads it and records the outcome of each delivery session — whether STARTTLS succeeded, whether the MTA-STS or DANE policy validated, and any routing or certificate failures.
3. Once per UTC day, the sender compiles those outcomes into a JSON report.
4. It delivers the report to your destination, tagging the applied policy as sts, tlsa or no-policy-found.

The reports are aggregate, not per-message, so they protect recipient privacy while still showing you which sending sources are failing TLS and why.

TLS-RPT record syntax

The TLS-RPT record is a single TXT record with a version and one or more report destinations. Here is a mailto TLS-RPT example:

_smtp._tls.example.com.   IN TXT   "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

You can also send reports to an HTTPS endpoint — rua=https://reporting.example.com/v1/tlsrpt — or list several destinations separated by commas. Reports arrive as JSON, once per UTC day, often gzip-compressed when sent by email. Note that this TLS-RPT record lives at _smtp._tls and is entirely separate from your DMARC record at _dmarc; the two rua tags look similar but belong to different layers.

Requirements and provider support

TLS-RPT is the reporting companion to MTA-STS and DANE, so it is most useful deployed alongside one of them — ideally turned on before you flip MTA-STS into enforce mode, so you can confirm clean reports first. You will also want a monitored inbox or HTTPS endpoint and, realistically, a parser or reporting service to turn the daily JSON into something readable. In 2026 the major senders generate TLS reports, including Google Workspace and Microsoft 365 (which requires at least a couple of messages in the same daily window before reporting). With nothing to report against, the reports simply show no-policy-found.

What is in a TLS-RPT report

Each TLS-RPT report is a JSON document covering one UTC day from one sending source. Rather than logging individual messages, it summarises the sessions that source opened to your mail servers: how many successfully negotiated TLS, how many failed, and — crucially — why they failed. A report groups results by your MX host and by the policy that applied, tagging each as sts (an MTA-STS policy was used), tlsa (a DANE policy was used), or no-policy-found. Within the failures you will see specific failure types: STARTTLS could not be negotiated, a certificate did not validate or did not match the expected host, a DANE TLSA record did not match, or the connection could not be routed at all.

That detail is what makes TLS-RPT actionable. A spike in certificate-validation failures from one sender usually means a certificate expired or a hostname changed; a cluster of STARTTLS failures can reveal a misbehaving relay or an active downgrade attempt. Because the reports are aggregate counts rather than message contents, they give you operational visibility without exposing anyone’s mail — which is exactly why mailbox providers are willing to send them.

Setting up TLS-RPT step by step

1. Decide where reports should go. Use a dedicated mailbox such as tlsrpt@yourdomain.com, or an HTTPS endpoint provided by a reporting service. A dedicated destination keeps the daily JSON out of your personal inbox.
2. Publish the TLS-RPT record. Add the TXT record at _smtp._tls.yourdomain.com with v=TLSRPTv1; and your rua destination.
3. Turn it on before enforcement. Enable TLS-RPT first, then deploy MTA-STS in testing mode, so the very first thing you do is gain visibility — never flip MTA-STS to enforce blind.
4. Use a parser. Raw daily JSON from many providers adds up fast; a parsing service or self-hosted tool turns it into a readable trend you will actually look at.
5. Verify the record with dig TXT _smtp._tls.yourdomain.com and confirm reports begin arriving within a day or two.

TLS-RPT, MTA-STS and DANE together

It helps to see the three transport-security standards as one system. MTA-STS and DANE are the two ways to enforce TLS — MTA-STS using the web certificate system and an HTTPS-hosted policy, DANE using DNSSEC-anchored TLSA records. TLS-RPT is the single reporting layer that works with both: whichever enforcement mechanism you choose, TLS-RPT tells you whether it is succeeding in the real world. That is why the standard advice is to deploy TLS-RPT first, then add MTA-STS (and DANE if you run DNSSEC), and only tighten enforcement once the reports show clean sessions.

Without this feedback loop, enforced TLS is a leap of faith: you would be telling senders to refuse delivery on any TLS failure with no way to see whose mail you are bouncing or why. TLS-RPT converts that risk into a managed rollout. None of this changes who your mail is from — for that, see the authentication hub — but it does protect the confidentiality and integrity of mail in transit, which is a distinct and increasingly expected layer of deliverability hygiene.

TLS-RPT pitfalls and best practices

• Deploying TLS-RPT with no MTA-STS or DANE — the reports will mostly say no-policy-found and give you nothing to act on.
• Confusing the TLS-RPT rua with the DMARC rua — they are different records at different hostnames for different purposes.
• Drowning in raw JSON — the daily volume is real; use a parsing service or dedicated mailbox.
• Listing multiple destinations and assuming all are used — support varies, and at least one major provider has been observed delivering only to the first destination, so put your primary rua first.
• Best practice: deploy TLS-RPT together with MTA-STS, turn it on before enforce, use a dedicated parser, verify the record with dig TXT _smtp._tls.yourdomain.com, and review the reports regularly.

For the enforcement side of the story, read our MTA-STS guide; for how transport security fits with sender authentication, see the email authentication hub and the broader deliverability guide.

Choosing mailto or https reporting

The rua tag accepts two kinds of destination, and they suit different setups. A mailto: destination delivers each daily report as an email attachment — usually gzip-compressed JSON — which is simple to set up and works with any mailbox, but means you (or a service) must collect and parse attachments. An https: destination has the sender POST the report directly to a web endpoint, which is cleaner for automated processing but requires you to run or subscribe to a service that accepts the uploads. Many domains use a dedicated TLS-RPT processing service and simply point the rua at whatever address that service provides. Whichever you choose, if you list more than one destination, put the one you actually monitor first, because support for multiple destinations is uneven and at least one major provider has been observed sending only to the first entry.

Whatever the transport, the point of TLS-RPT is to replace guesswork with evidence. Enforced TLS without reporting is a decision made in the dark: you are instructing senders to bounce mail on any TLS failure while having no idea how often that happens or to whom. With smtp tls reporting in place, a sudden change — a newly expired certificate, a relay that stopped supporting modern TLS, a policy typo — shows up as a clear spike in the next day’s report instead of as a mysterious drop in received mail that takes weeks to diagnose. That early-warning value is why experienced operators treat TLS-RPT as mandatory rather than optional whenever they enforce transport security.

Related reading

• SPF records guide
• DKIM records guide
• DMARC records guide
• BIMI records guide
• MX records guide

TLS-RPT FAQ

Does TLS-RPT encrypt my email?

No. TLS-RPT is purely a reporting standard — it tells you whether encrypted delivery succeeded or failed. The actual enforcement of TLS is done by MTA-STS or DANE; TLS-RPT is the feedback loop that makes their failures visible.

Where do I publish the TLS-RPT record?

As a TXT record at _smtp._tls.yourdomain.com, starting with v=TLSRPTv1; and at least one rua destination. It is a separate record from your DMARC record, which lives at _dmarc.

How often are TLS-RPT reports sent and in what format?

Reports are aggregated once per UTC day and sent as JSON, frequently gzip-compressed when delivered by email. They summarise TLS session outcomes rather than individual messages, so they preserve privacy while still pinpointing failing sources.

Can I use TLS-RPT without MTA-STS or DANE?

Technically yes, but the reports will mostly read no-policy-found because there is no enforcement policy to evaluate against. TLS-RPT delivers its value when deployed alongside MTA-STS or DANE, where it shows whether your TLS policy is working. The one situation where standalone TLS-RPT is genuinely useful is as a brief diagnostic step before you publish an MTA-STS policy: it lets you observe how senders are currently connecting so you can gauge whether enforcing TLS will cause any surprises.

Can I send TLS-RPT reports to more than one place?

Yes — list multiple comma-separated mailto: or https: destinations. However, support for multiple destinations varies, and at least one large provider has been seen using only the first one, so put your most important destination first.

Is the TLS-RPT rua the same as the DMARC rua?

No. Both use a rua tag, but they are different records for different purposes: the DMARC rua (at _dmarc) reports on authentication results — who sent as your domain and whether they passed and aligned — while the TLS-RPT rua (at _smtp._tls) reports on transport encryption outcomes — whether senders could establish a validated TLS connection. They are complementary, and a complete deployment publishes both, each pointing at a destination you actually monitor.