Build a TLS-RPT record
How it works
Pick a destination
A mailbox you read, an alias that feeds a parser, or an https endpoint at a reporting vendor. Reports arrive once a day per sending server, as gzipped JSON attachments.
List the domains
Every domain that receives mail on its own MX needs its own record. Sending-only domains that do not accept inbound mail get nothing useful, so start with the domains in your MX.
Check what is live
The tool reads the existing _smtp._tls record for each domain, flags duplicates, and tells you whether MTA-STS is published so the reports have something to report on.
Publish and leave it
One TXT record per domain, TTL 3600. Copy the row or export the whole set as CSV for a bulk DNS import.
What TLS-RPT actually reports
TLS-RPT is defined by RFC 8460. A sending server that tried to deliver mail to your domain writes down whether the TLS session succeeded, and once a day it posts a summary to the address in your record: how many sessions it attempted, how many succeeded, and for the failures, the reason — expired certificate, hostname mismatch, STARTTLS stripped, no policy found, policy fetch error. It is delivery telemetry from the other side of the connection, which you cannot get any other way.
The record itself is trivial. v=TLSRPTv1 must come first, then rua= with one or more destinations separated by commas. A mailto: destination gets the report as an attachment; an https:// destination gets it POSTed. Unlike DMARC, there is no external authorization record to publish — any address anywhere can be named without the receiving domain's permission, because the reports are about transport, not about your mail.
Why it only matters next to MTA-STS
Without a policy, TLS between mail servers is opportunistic: if STARTTLS is offered it is used, if not the mail goes in the clear, and nobody complains. MTA-STS turns that into a rule — senders must use TLS with a valid certificate matching your MX, or not deliver at all. That rule is what produces failures worth knowing about, and TLS-RPT is the channel they come back on. Publishing MTA-STS in enforce mode without TLS-RPT means you have told the world to refuse mail under certain conditions and given yourself no way to find out when it happened.
The safe order is: publish MTA-STS in testing mode and TLS-RPT at the same time, watch the reports for a couple of weeks, and only move to enforce once the failure count is zero. The MTA-STS checker confirms the policy file and the DNS record agree before you do.
Choosing the destination
A plain mailbox works and gets boring fast: one attachment per sending organisation per day, and for a domain that receives mail from Google, Microsoft, Amazon SES and a few hundred others, that is a lot of gzipped JSON nobody opens. Three sane options: an alias that forwards into a parser, a free tier at a reporting service, or a mailbox you check once a month and only when something else looks wrong. What you should not do is point it at a mailbox on a domain with no MX — the tool checks that, because reports that bounce are worse than no reports.
Sending domains and subdomains
TLS-RPT is looked up on the domain in the recipient address, so it belongs on domains that receive mail. If your cold email fleet sends from domains that also accept replies — which it should, since a domain that cannot receive mail fails the most basic sender check — each of those domains wants the record. Subdomains do not inherit it; send.example.com needs its own _smtp._tls.send.example.com. Generate the whole fleet in one pass here and import the CSV.
Frequently asked questions
Is TLS-RPT worth publishing if I have no MTA-STS policy?
Only mildly. With no policy there is nothing for a sender to violate, so the reports mostly confirm that opportunistic TLS worked. Publish both, or publish neither and do it properly later.
Does the rua address need to be on my own domain?
No. TLS-RPT has no external destination authorization step, which is the thing DMARC requires. Any mailbox or https endpoint can be named. It does need working MX if it is a mailbox.
Can I list two destinations?
Yes, comma-separated inside one rua tag. Keep the record under 255 characters so your DNS host does not have to split the TXT string.
Where exactly does the record go?
A TXT record with the host _smtp._tls on the domain. Most DNS panels add the domain for you, so type _smtp._tls and not the whole name, or you will end up with _smtp._tls.example.com.example.com.
How often do reports arrive?
Once a day per sending organisation, and only from senders that support TLS-RPT — the large providers do. A quiet domain may get nothing for days, which is not a fault.
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 and Microsoft 365 inboxes
- 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.