How to Check a Domain's TLS-RPT Record (And Its Report Addresses)
To check a domain's TLS-RPT record, read the TXT record at _smtp._tls.<domain>. A valid one starts v=TLSRPTv1; and names where reports go with rua=. The bulk TLS-RPT checker reads it for up to 100 domains a run (500 after a free Google sign-in), checks it against RFC 8460, tests each report destination and notes whether the domain also has MTA-STS. For a single domain in full detail, use the TLS-RPT checker.
This is a DNS-only check. Nothing is sent to your mail servers and no report is requested.
What TLS-RPT is
TLS reporting lets a domain ask sending mail servers to report problems they had negotiating TLS when delivering to it. RFC 8460 defines it. The domain publishes one TXT record, for example:
_smtp._tls.example.com. TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
The rua= tag says where reports go: a mailto: address or an https: endpoint. It is most useful next to MTA-STS, which tells senders a domain's mail must be delivered over TLS. The reports show where that fails. Our guide to checking MTA-STS before enforcing it shows the two working together.
Step 1: paste the domains
Paste domains, email addresses or URLs, one per line. Use up to 100 a run without an account, or 500 after a free Google sign-in. Include every domain that receives mail, not just your main one.
Step 2: run the check
Each domain's record is read over DNS, then each report destination is checked, 10 domains per request. No report is sent and no endpoint is called.
Step 3: read each row
| Result | What it means | What to do |
|---|---|---|
| Valid | One correct record, and its destinations can receive reports | Nothing to fix |
| Has issues | The record is there but something is wrong. The first problem is shown | Fix the record, then check again |
| No record | No _smtp._tls TXT record |
Optional. Add one if you publish MTA-STS or want TLS failure reports |
| Lookup failed | DNS did not answer properly | Try again later |
What the check tests
That exactly one record starts with v=TLSRPTv1;, that its syntax is valid, and that each destination can receive reports. The version and rua= tags are case-sensitive, so v=tlsrptv1 is flagged. A second TLS-RPT record on the same name is a fault. A mailto: address's domain must have an MX record, and an https: host must resolve to a public address. Plain http: destinations are not allowed by the RFC and are flagged.
That last point catches a common slip: a report address on a domain that has no mail set up, so every report bounces. The row lists every destination's result.
Step 4: fix what it flags
- Two records. Delete one. Senders may ignore a name with more than one.
- Wrong case or typo. Rewrite it exactly as
v=TLSRPTv1; rua=mailto:.... - Report address on a domain without MX. Use a mailbox that exists, or a reporting service's endpoint.
- http: destination. Switch it to
https:or amailto:address.
Publish changes as a TXT record at the _smtp._tls name. If the record does not appear straight away, public DNS can serve a cached answer for up to the record's TTL.
Does every domain need one
No. It is optional, and a domain that does not receive mail gets little from it. A No record row is not an error in itself. Read it next to the domain's MX and MTA-STS results in the CSV. If you publish an MTA-STS policy, add TLS-RPT so you find out when a sender cannot use TLS to reach you, ideally before you switch the policy to enforce. To check MTA-STS itself across a list, use the bulk MTA-STS checker.
Where it fits among your other email DNS records
TLS-RPT is monitoring, not authentication. It does not affect whether mail from you is accepted. For the records that do, see SPF, DKIM and DMARC explained, and for checking many domains at once, monitoring sending domains for SPF, DKIM and DMARC.
What this check cannot do
- It checks DNS only. It cannot tell whether reports arrive or anyone reads them.
- A valid record does not mean the domain's mail servers support TLS. That is what the reports are for.
- Public DNS can serve a cached answer for up to the record's TTL.
- It does not read the reports themselves.
- The limit is 100 domains a run without an account and 500 signed in.
Check the addresses you send to
Correct DNS gets mail to the door; the address still has to exist. Upload your list on the verify page: the first 100 email checks are free with a Google sign-in, no card. Each address comes back valid, risky or invalid with a reason, and nothing is sent to anyone on the list. For larger or recurring lists, see bulk email verification, list cleaning and pricing.
Check your domains now
Paste them into the bulk TLS-RPT checker.
Common questions
How do I check a domain's TLS-RPT record?
Read the TXT record at _smtp._tls.yourdomain.com. It should start v=TLSRPTv1; and name a report destination with rua=. A bulk TLS-RPT checker reads it for many domains, checks it against RFC 8460 and tests each destination.
Does every domain need a TLS-RPT record?
No. It is optional, and a domain that does not receive mail has little use for it. It matters most for domains that publish MTA-STS or that want to know when a sender cannot use TLS to reach them.
What does a valid TLS-RPT record look like?
A TXT record at _smtp._tls.<domain> that starts v=TLSRPTv1; and names where reports go with rua=, as a mailto: address or an https: endpoint.
Can the checker tell me whether reports arrive?
No. It only reads DNS. It never sends a report and never calls a reporting endpoint, so it cannot say whether reports arrive or anyone reads them.
Are http: report destinations allowed?
No. RFC 8460 does not allow plain http: destinations, so the checker flags them.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.