Read the TLS-RPT record a domain publishes at _smtp._tls, check it against RFC 8460, and see exactly where its TLS reports are being sent. It runs free in your browser over DNS-over-HTTPS, with no signup and nothing stored.
Create a free Unspam account to save your results and re-run these checks anytime, so you catch a broken setup before it costs you. No credit card.
TLS-RPT is a DNS record that asks receiving mail servers to tell you how encryption went when they delivered mail to you. Servers that support it send a summary once a day, listing how many connections negotiated TLS successfully and how many failed, with the reason. Publishing it changes nothing about how your mail is delivered: it is a feedback channel, not a policy. What it buys you is finding out that a certificate expired, that a mail host stopped offering STARTTLS, or that an MTA-STS policy is failing, before a customer tells you. The record is a single line, it lives at _smtp._tls under your domain, and this checker reads the whole of it, because unlike MTA-STS there is no second half sitting behind a web server a browser cannot reach.
The version, which must be the first thing in the record and must be spelled exactly that way. RFC 8460 defines it as case-sensitive text and tells senders to discard anything that does not begin with v=TLSRPTv1 followed by a semicolon, so v=tlsrptv1 is not a typo with cosmetic consequences: it is a record nobody reads.
Where the reports go. It takes one address or a comma-separated list, and only two kinds are allowed: mailto: for an inbox and https: for an endpoint that accepts a POST. Reports are JSON, gzipped, and arrive roughly daily from each provider that supports the standard.
If a sender finds more than one TLS-RPT record at the name, RFC 8460 says it must treat the domain as not implementing TLS-RPT at all. Two records is not a backup, it is an off switch, which is the same rule SPF and DMARC use and the same mistake people make when they add a second record instead of editing the first.
The standard defines an extension slot for future fields and tells senders to ignore any field they do not recognise, so an unknown tag can never break a record. Across every mailbox provider, relay and hosting operator this checker was tested against, no live record carries anything beyond the version and rua.
v=tlsrptv1 or v=TLSRPTV1 look right and collect nothing. The record is discarded before it is parsed, so there is no error anywhere: reports simply never arrive, and the only symptom is silence you were not expecting to be broken.
Usually the result of adding a new record during a migration instead of editing the old one. It switches reporting off rather than sending to both. Keep one record listing both destinations in its rua instead.
The comma separates the destination list, so an unencoded one inside an address splits it in half. The exclamation point is the DMARC size-limit suffix, which TLS-RPT does not have, and it must be written as %21. Both are required to be percent-encoded and both silently mangle the destination list.
Only mailto and https exist. A plain http endpoint is not a scheme any sender will use, so the reports are dropped rather than downgraded.
TLS reports arrive as gzipped JSON, daily, from every provider that supports the standard. Pointed at a shared inbox they become noise inside a week. Point them at a mailbox or an analytics service that parses them, or the record is doing nothing useful.
It reports, it does not require. If you want receiving servers to insist on TLS when they deliver to you, that is MTA-STS or DANE. TLS-RPT is how you find out whether either of them is working, which is why the two are usually deployed together.
