Check TLS-RPT
Email addresses work too — everything after the @ is used.
How it works
Lookup
The TXT record at _smtp._tls. is fetched over DNS-over-HTTPS from your browser.
Parse
Tags are split on semicolons. The version must be TLSRPTv1 and rua must hold at least one mailto: or https: address.
Context
MTA-STS and MX are checked at the same time, because a report address with no policy behind it enforces nothing.
Verdict
Valid, needs attention, or broken — with the corrected record ready to copy when nothing is published.
What TLS-RPT does
When a sending server tries to deliver to you and the TLS handshake fails — expired certificate, hostname mismatch, a policy it cannot fetch — it has no way to tell you. The mail either falls back to plaintext or is not delivered at all, and both are invisible from your side. TLS-RPT gives receivers an address to send a daily summary of those failures, so you find out about a broken certificate on an MX from the report rather than from a client asking why mail stopped.
Why it goes with MTA-STS
MTA-STS is the policy that says "only deliver to me over TLS, and only to these hosts". If that policy has a mistake in it, or a certificate lapses, a strict sender will refuse to deliver — and that is exactly the failure TLS-RPT reports. I publish them together on every domain I set up. Publishing MTA-STS in enforce mode without TLS-RPT is flying blind; publishing TLS-RPT without MTA-STS still catches opportunistic TLS failures, which is worth having, but it is only half the job.
What the report address needs
The mailbox at the rua address receives JSON attachments from Google, Microsoft and others every day for each domain. That is fine for one or two domains. Across a sending fleet of forty it is a lot of unread mail, which is why people point rua at a reporting service. If you do, the address still has to accept mail — a service that quietly lapsed means the record validates and the reports vanish.
Faults this catches
Two records at the same name, which receivers treat as none. A rua that is neither mailto nor https. A missing version tag or one placed after the rua. Reports pointed at a domain that has nothing to do with yours, which may be intentional but is worth a second look. And the most common one: a TLS-RPT record on a domain that has no MX, left over from a template applied to every zone in an account.
Frequently asked questions
What is a TLS-RPT record?
A TXT record at _smtp._tls.yourdomain that tells receiving mail servers where to send daily reports about TLS delivery failures. The format is v=TLSRPTv1; rua=mailto:address.
Do I need TLS-RPT for cold email?
It is not a deliverability signal in itself, but it is the only way to find out that an MTA-STS policy or a certificate on your mail host is silently breaking inbound delivery. On domains that receive replies, yes.
Can rua be an https URL?
Yes. RFC 8460 allows https: endpoints that accept a POST of the JSON report. Most people use mailto because it needs no server.
Why does the checker warn about MTA-STS?
Because TLS-RPT reports failures against a policy. Without MTA-STS, receivers still send reports about opportunistic TLS failures, but nothing is being enforced, so the record does less than people assume.
Who actually sends TLS reports?
Google and Microsoft send them for every domain that publishes a record and receives mail from them. Smaller providers vary. Expect at least one report a day per domain from Google alone.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.