TLS-RPT Record Checker
Free TLS-RPT lookup tool - instantly verify your domain's SMTP TLS Reporting DNS record, validate it against RFC 8460, check that it pairs with your MTA-STS policy, and confirm your reporting addresses can actually receive reports.
Google
  • Google
  • Cloudflare
  • OpenDNS
  • Quad9
Enter a root domain - we query the TXT record at _smtp._tls automatically, validate it, and check your MTA-STS pairing.

Why Check Your TLS-RPT Record

Even a correctly configured mail server can silently fail to deliver over TLS. A TLS-RPT record is the only way to find out when that happens.

Catch TLS failures early
See exactly when sending mail servers cannot establish an encrypted connection to your domain, before it turns into a delivery problem.
Validate your MTA-STS setup
TLS-RPT reports surface any policy or connection failures caused by MTA-STS enforcement - this tool reads your live MTA-STS policy so you can see the pairing.
Confirm reports can arrive
A reporting address is useless if mail cannot reach it. We verify each rua destination actually has somewhere to deliver reports.

How to Use the TLS-RPT Checker

Running a TLS-RPT lookup takes seconds. Follow these three steps to verify your SMTP TLS Reporting setup.

1
Enter your domain. Type your root domain (e.g. example.com) - no need to add the _smtp._tls prefix, we handle that automatically.
2
Pick a resolver and check. Choose Google, Cloudflare, OpenDNS, or Quad9, then press Enter or click Check record to query DNS live from our server.
3
Review the results. We validate the version and rua tags against RFC 8460, inspect your paired MTA-STS policy, and confirm each reporting destination is reachable.

What Is a TLS-RPT Record?

SMTP TLS Reporting (TLS-RPT) is an email standard defined in RFC 8460 that lets domain owners receive reports about failures in delivering email over an encrypted TLS connection. It works alongside MTA-STS to reveal problems - failed certificate validation, downgrade attacks, unsupported STARTTLS - that would otherwise go unnoticed.

A single TXT record
Published at _smtp._tls.yourdomain.com, it tells receiving mail servers where to send aggregate reports about TLS connection attempts.
Reporting, not enforcement
TLS-RPT does not block or enforce anything itself. It is purely a feedback channel - the visibility layer that pairs with MTA-STS.
Free and low-effort
Two tags are all it takes. It is not mandatory, but it is a best practice that costs nothing and closes a real blind spot.
_smtp._tls.yourdomain.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
; v -> identifies the record as TLS-RPT (RFC 8460)
; rua -> where aggregate TLS reports are sent

TLS-RPT vs. MTA-STS: What's the Difference?

MTA-STS (Mail Transfer Agent Strict Transport Security) is an enforcement mechanism - it tells sending mail servers that your domain requires a valid, TLS-encrypted connection, and blocks delivery over unencrypted or misconfigured connections. TLS-RPT is a reporting mechanism - it does not enforce anything itself, but tells sending servers where to report both successful and failed TLS connection attempts, including ones caused by your MTA-STS policy.

The two are designed to work together: MTA-STS enforces encryption, and TLS-RPT gives you the feedback loop to know whether that enforcement is causing delivery problems. That is why this checker also inspects your MTA-STS policy - you can confirm both sides line up. You can dig into the enforcement side with our MTA-STS record checker.

TLS-RPT Tags Explained

Every TLS-RPT record is built from a small set of tags. Here is what each one means.

v=
Version (required)

Identifies the record as a TLS-RPT record. It must be the first tag and always set to TLSRPTv1.

rua=
Aggregate report URI (required)

Where aggregate TLS reports are sent. Accepts a mailto: address, an https:// endpoint, or a comma-separated list of both.

Common TLS-RPT Issues and How to Fix Them

Here is what typically goes wrong with a TLS-RPT setup, and what each result means for your domain.

No record found
Nothing at _smtp._tls
No TXT record exists at the correct host, so you receive no TLS delivery failure reports at all.
Publish a TXT record at _smtp._tls.yourdomain.com with a valid v= and rua= tag.
Malformed v= tag
Not recognized as TLS-RPT
The record does not start with v=TLSRPTv1, so mail servers will not treat it as a TLS-RPT record.
Make v=TLSRPTv1 the exact, first tag in the record.
Missing or invalid rua=
Reports have nowhere to go
No reporting destination is defined, or a mailto/https URI is malformed, so reports cannot be delivered.
Add at least one valid mailto: or https: URI, and confirm the destination can receive it.
Multiple records
More than one TLS-RPT record
Two or more TLS-RPT records at the same host is not permitted by RFC 8460 and may cause validation errors.
Consolidate to exactly one TLS-RPT record with all destinations in one rua tag.

How to Read Your TLS-RPT Reports

Once your record is live, receiving mail servers will start sending periodic aggregate reports to your rua destination. Here is what is inside them.

Policy details
The type of policy in effect (e.g. sts, no-policy-found) for the sending domain covered by the report.
Summary counts
Total successful and failed TLS connection attempts during the reporting window, usually a 24-hour period.
Failure details
Categorized failure types - certificate expired, hostname mismatch, STARTTLS not supported - with example source IPs.

Raw JSON reports are difficult to read at scale, especially once you are receiving them from dozens of different mail providers. PowerDMARC's platform automatically parses TLS-RPT reports into a readable dashboard alongside your DMARC, SPF, and MTA-STS data.

How to Publish a TLS-RPT Record

Log in to your DNS provider and add a new TXT record with these values.

Host / Name
_smtp._tls
Type
TXT
TTL
3600 (default)
Propagation
Up to 48 hours
Value
v=TLSRPTv1; rua=mailto:[email protected]

DNS changes can take up to 48 hours to propagate fully, though most providers update within a few hours. Once live, use the checker above to confirm it is published correctly.

Frequently Asked Questions

Is TLS-RPT the same as DMARC?
No. DMARC reports on authentication (SPF/DKIM) failures for messages sent from your domain. TLS-RPT reports specifically on failures to establish an encrypted TLS connection when mail is delivered to your domain. They are complementary but independent standards.
Is my domain data sent to your servers?
The domain you enter is sent to our server, which runs the DNS lookup for you against the public resolver you choose - the same query anyone could run with a dig command. We don't log or store the domains you check or the records returned.
Do I need MTA-STS to use TLS-RPT?
No, TLS-RPT can be deployed on its own. It is most valuable when paired with MTA-STS, though, since it will report on any connection or policy failures that MTA-STS enforcement causes. This checker also inspects your MTA-STS policy so you can see how the two line up.
Is TLS-RPT mandatory?
No, TLS-RPT is optional and not required by any major mailbox provider. It is a free, low-effort way to gain visibility into TLS delivery problems that would otherwise be invisible, and it is considered best practice alongside DMARC, SPF, DKIM, and MTA-STS.
Can I use multiple rua addresses?
Yes. You can list multiple destinations separated by commas, mixing mailto: and https: URIs - for example rua=mailto:[email protected],https://reports.example.com/tlsrpt. This tool validates each one and checks that email destinations can actually receive mail.
Can reports be sent to a different domain than mine?
Yes. Unlike DMARC, RFC 8460 defines no external-destination authorization record for TLS-RPT, so you can point rua at a third-party processor (such as PowerDMARC) with no extra DNS setup. This tool flags external destinations for clarity, but they are perfectly valid.
Why is my TLS-RPT record showing as not found?
Either the record has not been published yet, DNS changes have not fully propagated, or the record was added at the wrong host - it must be exactly _smtp._tls.yourdomain.com, not just yourdomain.com.
Can I use an https endpoint instead of email for reports?
Yes. RFC 8460 supports both mailto: and https: reporting URIs. An https endpoint must accept HTTP POST requests carrying the report as a gzip-compressed JSON payload - typically used by larger organizations or platforms like PowerDMARC that process reports automatically.

Automate your email authentication

PowerDMARC monitors your DMARC, SPF, DKIM, BIMI, MTA-STS, and TLS-RPT records in one dashboard - with alerts the moment something breaks.

Book a demo Start 15-day trial