TLS-RPT (SMTP TLS Reporting, defined in RFC 8460) is a single DNS TXT record that tells other mail servers where to send you a daily report whenever they fail to set up an encrypted TLS connection to your domain. You publish it at the _smtp._tls subdomain, point the rua tag at a mailbox or HTTPS endpoint you control, and within about 24 hours you start receiving JSON reports about connection successes and failures. It is a reporting layer, not an enforcement layer, so it never blocks or delays mail on its own.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
The record itself is short. Here is the copy-paste template you can adapt right now:
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com"
Replace yourdomain.com with your domain and swap in a real reporting address. That single line is the entire mechanism. Everything else in this guide is about doing it correctly and reading what comes back.
Why TLS-RPT exists and what problem it solves
SMTP was designed in an era with no encryption. When STARTTLS was bolted on later, it stayed opportunistic: if the TLS handshake fails or a certificate is invalid, most sending servers silently fall back to plaintext or defer the message. The sender knows something went wrong. You, the domain owner receiving the mail, learn nothing.
That silence is the problem. A misconfigured certificate, an expired chain, a downgrade attack stripping the STARTTLS banner, or a broken MTA-STS policy can all cause TLS to fail for a subset of your inbound mail, and you would never see it in your own logs because the connection never completed. TLS-RPT closes that visibility gap. It asks every participating sender to aggregate what they saw when connecting to you and mail you a structured summary once per day.
This matters most when you have deployed a TLS enforcement policy. If you turn on MTA-STS in enforce mode and your certificate later expires, senders that honor the policy will refuse to deliver rather than downgrade. Without TLS-RPT you find out when someone complains that your mail stopped arriving. With TLS-RPT you get a report naming the exact failure type the same day.
The exact _smtp._tls TXT record, tag by tag
The record lives at a fixed location: the hostname _smtp._tls prepended to your domain. For example.com the full name is _smtp._tls.example.com. It is an ordinary DNS TXT record, so any DNS host that lets you add TXT entries can hold it.
There are only two tags you need to know:
v=TLSRPTv1is the version identifier and it must come first, exactly as written. A record that does not begin withv=TLSRPTv1is invalid and ignored.ruais the aggregate report URI. It tells senders where to deliver reports. This tag is required; a TLS-RPT record with noruadoes nothing.
A complete mailto record looks like this:
v=TLSRPTv1; rua=mailto:tls-reports@example.com
You can list more than one destination by separating URIs with a comma, and reports will be sent to each:
v=TLSRPTv1; rua=mailto:tls-reports@example.com,https://reports.example.net/v1/tlsrpt
mailto versus https endpoints
RFC 8460 defines two rua transports and you can use either or both.
A mailto: endpoint receives each report as an email with a gzip-compressed JSON attachment. This is the simplest option and works with any mailbox. The tradeoff is that a busy domain can receive many reports a day from many providers, so a shared human inbox fills up fast.
An https: endpoint receives reports as an HTTP POST of the same JSON, letting a collector ingest them programmatically. Use this if you run tooling that parses reports automatically. Note that the reporting server must present a valid TLS certificate for the HTTPS endpoint, which is deliberate: reports about broken encryption should not themselves travel over broken encryption.
Most teams start with mailto: because it needs nothing but a DNS change and a mailbox.
Use a dedicated reporting mailbox, not a person's inbox
This is the operational detail most walkthroughs skip. Do not point rua at your own name or a support alias. TLS-RPT reports are machine-generated JSON that arrives every day from Google, Microsoft, and every other sender that supports the standard. Routing that into a working inbox buries real mail and trains people to ignore it.
Create a dedicated mailbox such as tls-reports@yourdomain.com (or a subaddress like tls-reports+prod@) whose only job is to collect these. A few practical points:
- The reporting address does not have to be on the same domain as the record. You can send reports for
example.comtotls-reports@collector.example.netif you centralize reporting. RFC 8460 allows cross-domain reporting without an authorization record, unlike DMARC. - Make sure that mailbox itself accepts mail reliably. If your TLS-RPT mailbox is behind the same broken TLS you are trying to diagnose, you may never receive the report telling you.
- The same discipline you would apply to a DMARC aggregate report mailbox applies here: expect volume, plan to parse it, and keep it separate from human mail.
TTL, publishing, and verification
Publish the record with a moderate TTL. A value between 3600 (one hour) and 86400 (one day) is sensible. There is no benefit to an aggressive short TTL because TLS-RPT policy changes are rare, and a longer TTL reduces DNS load. If you are actively testing and expect to edit the record, drop the TTL to 3600 first, confirm everything works, then raise it.
After you add the record, confirm it resolves. From a terminal:
dig +short TXT _smtp._tls.example.com
You should see your v=TLSRPTv1 string returned. If it is empty, check that you did not accidentally create the record at the apex or at smtp._tls without the leading underscore on _smtp. Both underscores matter.
Reports are generated on a daily cadence, so do not expect anything within minutes. Give it 24 to 48 hours before concluding that reporting is not working. The first reports usually arrive from the large providers first.
How TLS-RPT complements MTA-STS and DANE
TLS-RPT is the reporting companion to the two mechanisms that actually enforce encrypted delivery. It replaces neither.
MTA-STS uses a DNS record plus an HTTPS-hosted policy file to tell senders they must use validated TLS to reach you. DANE (TLSA records) uses DNSSEC-signed records to pin the certificate senders should expect. Both can cause mail to be deferred or rejected when TLS is wrong, which is the point: they stop silent downgrades.
The gap they share is feedback. Enforcement without reporting means you are flying blind on how often enforcement is actually kicking in. TLS-RPT is the answer. Deploy MTA-STS or DANE for enforcement, deploy TLS-RPT alongside it for visibility, and you can see exactly which senders hit certificate-expired, starttls-not-supported, validation-failure, or sts-policy-invalid failure types in the reports. Many operators publish TLS-RPT first, in isolation, run it for a few weeks to confirm their inbound TLS is healthy, and only then turn on MTA-STS enforcement with confidence. If you are weighing the two enforcement options, our MTA-STS vs DANE comparison breaks down which fits your setup.
Because TLS-RPT never blocks mail, there is no downside to publishing it early. It is the safest of all the email-authentication DNS records to deploy because it cannot cause a delivery failure.
Reading what the reports tell you
A TLS-RPT report is a JSON document with a summary of successful and failed sessions and a breakdown of failure types. The fields that matter most are the result-type values under each policy. Common ones include:
starttls-not-supported: the sending server offered STARTTLS but your server did not complete it, often a plaintext downgrade or a stripped banner.certificate-expired: your certificate was past its validity date. This is the single most common real failure and the reason to watch reports.certificate-host-mismatch: the certificate did not match the mail host name.validation-failure: a generic TLS validation problem such as an untrusted chain.sts-policy-fetch-errororsts-policy-invalid: the sender could not retrieve or parse your MTA-STS policy.
A steady stream of certificate-expired after a renewal usually means a mail node was not reloaded and is still serving the old certificate. Persistent starttls-not-supported from one source can indicate a middlebox stripping STARTTLS. The value of TLS-RPT is turning these from invisible into a named, dated, per-sender count.
Frequently asked questions
Does TLS-RPT block or delay email?
No. TLS-RPT is purely a reporting mechanism. It has no enforcement power and cannot cause a message to be deferred or rejected. Only MTA-STS and DANE change delivery behavior. This is why TLS-RPT is safe to publish before you deploy any enforcement, and why there is no risk in adding the record today.
Do I need MTA-STS or DANE for TLS-RPT to work?
No, they are independent. TLS-RPT will collect reports about your inbound TLS even with no enforcement policy in place, and those reports cover plain STARTTLS sessions too. That said, TLS-RPT is far more valuable once you enforce, because it tells you when enforcement is causing failures. Running TLS-RPT alone first is a good way to audit your TLS health before committing to MTA-STS enforcement.
Can I send TLS-RPT reports to an address on a different domain?
Yes. Unlike DMARC, TLS-RPT does not require an authorization record when the reporting destination is on a different domain from the one the record covers. You can centralize all reports at a single mailbox or HTTPS collector across many domains. Just make sure that destination reliably accepts mail or HTTP POSTs.
How soon will I see reports after publishing the record?
Reports are generated once per day by sending servers, so expect the first ones within 24 to 48 hours, not minutes. The largest providers tend to report first. If nothing arrives after two days, re-check that the record resolves at _smtp._tls.yourdomain.com with both underscores and starts with v=TLSRPTv1.
Once your record is live, run a free check on spfwise to confirm it parses correctly and to see how your TLS-RPT setup sits alongside your SPF, DKIM, DMARC, and MTA-STS records in one grade.