Free Tool - No Signup Required

TLS-RPT Record Generator

Q: How does TLS-RPT relate to MTA-STS and DANE?

TLS-RPT is the reporting companion to the TLS enforcement standards. MTA-STS and DANE tell senders to require valid TLS and refuse delivery when it is missing, which can silently bounce legitimate mail if your setup is wrong. TLS-RPT gives you the visibility to catch those failures first. Publish TLS-RPT, deploy MTA-STS in testing, watch the reports, then move to enforce only once they are clean.

Q: Do I need MTA-STS or DANE before adding TLS-RPT?

No. TLS-RPT is useful on its own. Even without MTA-STS or DANE it reports on opportunistic STARTTLS successes and failures for inbound mail, which can reveal MX servers accepting mail in plaintext or presenting broken certificates. It is the lowest-risk first step toward hardened SMTP transport because it only collects data and never changes how mail is delivered.

Build a valid _smtp._tls TXT record so senders report SMTP TLS and MTA-STS failures to you — before you enforce.

Your Domain

The record is published at _smtp._tls.yourdomain.com

Reporting Destinations (rua)

Where senders should deliver aggregate TLS reports. Add one or more mailbox addresses and/or HTTPS endpoints.

mailto:

Your TLS-RPT Record

Add at least one reporting destination above to generate your TLS-RPT record.

How to add this record:

Log in to your DNS provider (Cloudflare, Route 53, GoDaddy, etc.)
Add a new TXT record with host _smtp._tls
Paste the record above as the value
Save and wait for DNS propagation (typically 5-60 minutes)

Verify with IntoDNS.AI Check MTA-STS

SMTP TLS reporting, explained

Email between mail servers travels over SMTP, and TLS on that hop is opportunistic: if STARTTLS is missing or a certificate is broken, most senders quietly fall back to plaintext rather than fail. That means inbound mail can be downgraded and read in transit without anyone noticing. TLS-RPT closes the visibility gap. By publishing a single TXT record at _smtp._tls.example.com, you ask every sending organisation to email or POST you a daily aggregate report of how their TLS sessions to your mail servers went.

The record format is deliberately small. It is v=TLSRPTv1; rua=..., where rua is a comma-separated list of destinations. Each destination is either a mailto: address or an https: URL that accepts an HTTP POST. You can list several, and you can mix the two types — senders try each one. There are no policy decisions to make here: TLS-RPT never changes how mail is delivered, it only collects evidence.

That makes it the safe first move when hardening SMTP transport. The usual workflow is to publish TLS-RPT, then deploy MTA-STS in testing mode (or DANE via TLSA records), watch the reports until they are clean, and only then switch to enforce. Without TLS-RPT you are flying blind: you would move to enforcement and discover broken senders only when their mail starts bouncing.

Reports themselves are gzipped JSON. Each one names the reporting organisation, a date range, and a set of policy and result types — values like starttls-not-supported,certificate-expired, validation-failure, and successful-session with success and failure counts. A few stray failures from an obscure forwarder are normal; a consistent failure from a large provider is a signal to fix your MX certificate or MTA-STS policy before you enforce anything. Point rua at a mailbox or processor that can parse the JSON — many DMARC report processors ingest TLS-RPT too.

Once published, confirm everything with the MTA-STS checker, the SMTP TLS checker, or a full scan on the IntoDNS.ai homepage.

TLS-RPT record format

Tag	Required	Meaning
v=TLSRPTv1	Yes	Version tag. Must be the first tag and is currently always `TLSRPTv1`.
rua=mailto:	Yes	A mailbox to receive reports, e.g. `mailto:[email protected]`.
rua=https:	Yes	An HTTPS endpoint that accepts reports via HTTP POST, e.g. `https://reports.example.com/tlsrpt`.
,	—	Separate multiple `rua` destinations with a comma; mailto and https may be mixed.

At least one rua destination is required, otherwise the record has no effect. Example: v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.com/tlsrpt

Frequently Asked Questions

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a DNS TXT record published at _smtp._tls.<your-domain> that asks sending mail servers to send you daily aggregate reports about whether they could deliver mail to you over a secure TLS connection. It tells you, before you enforce anything, how often TLS negotiation, MTA-STS policy checks, or DANE validation succeed or fail.

How does TLS-RPT relate to MTA-STS and DANE?

TLS-RPT is the reporting companion to the two TLS enforcement standards. MTA-STS and DANE both tell senders to require valid TLS and to refuse delivery when it is missing — which can silently bounce legitimate mail if your setup is wrong. TLS-RPT gives you the visibility to catch those failures first. The recommended order is: publish TLS-RPT, deploy MTA-STS in testing mode (or DANE), watch the reports for a week or two, then move to enforce only once the reports are clean.

How do I read TLS-RPT reports?

Reports arrive as gzipped JSON, either by email (to a mailto: address) or via HTTP POST (to an https: endpoint). Each report names the sending organisation, the date range, and a set of result types — for example "starttls-not-supported", "certificate-expired", "validation-failure", or "successful-session". A handful of failures from a single forwarder is usually noise; a consistent failure from a major provider like Google or Microsoft points to a real problem with your MX certificate or policy that you must fix before enforcing.

Can I send reports to more than one destination?

Yes. The rua= tag accepts a comma-separated list, and you can mix mailto: and https: URIs in the same record — for example rua=mailto:[email protected],https://reports.example.com/tlsrpt. Senders will attempt each destination. Use a mailbox or processor that can parse the gzipped JSON; raw reports in a human inbox quickly become unmanageable for any real volume.

Should I use a mailto or an https reporting endpoint?

A mailto: address is the simplest to set up and works with any TLS-RPT processing service (many DMARC report processors also ingest TLS-RPT). An https: endpoint receives reports via HTTP POST and suits teams that run their own ingestion pipeline. If you are unsure, start with a mailto: address pointed at a dedicated mailbox or a reporting service.

Do I need MTA-STS or DANE before adding TLS-RPT?

No. TLS-RPT is useful on its own — even without MTA-STS or DANE, it reports on opportunistic STARTTLS successes and failures for inbound mail, which can reveal MX servers that are accepting mail in plaintext or presenting broken certificates. It is the lowest-risk first step toward hardened SMTP transport, because it only collects data and never changes how mail is delivered.