MTA-STS & TLS-RPT

TLS-RPT record checker

Validate your TLS-RPT DNS record and reporting addresses to receive TLS connection failure reports.

Please enter a valid domain name, without http:// prefix.

About

The TLS-RPT Checker looks up your TLS Reporting (TLS-RPT) DNS record at _smtp._tls.yourdomain.com and validates reporting addresses.

TLS-RPT complements MTA-STS by sending aggregate reports about TLS connection failures, helping you spot misconfigurations, certificate problems, and delivery issues before they affect mail flow.

Report address validation

Confirm rua aggregate reporting addresses are published and syntactically valid.

Live DNS lookup

See the exact TLS-RPT TXT record receivers find for your domain.

Visibility into TLS failures

Know whether reporting is configured so you can receive failure summaries from senders.

MTA-STS companion

Verify the reporting side of your TLS security stack alongside MTA-STS enforcement.

How to use this tool

Enter your domain

Provide the root domain, for example example.com, without http:// or paths.

Query TLS-RPT DNS

The tool looks up _smtp._tls.yourdomain.com for the TLS-RPT TXT record.

Parse reporting tags

rua (aggregate) and optional ruf (failure) addresses are extracted and validated.

Review results

Read pass/fail checks for record validity, reporting addresses, and any errors.

Understanding the results

A valid TLS-RPT record starts with v=TLSRPTv1 and includes at least one rua= reporting address where senders deliver TLS failure reports.

Valid record with reporting

TLS-RPT TXT record is present, contains v=TLSRPTv1, and has valid rua addresses.

Not found

No TLS-RPT record at _smtp._tls.yourdomain.com, you will not receive TLS failure reports.

Record found, issues

Record exists but has validation problems, missing rua, invalid addresses, or wrong version.

Hosted TLS-RPT

Indicates whether the record is delegated to a third-party provider via CNAME.

Important result fields

Valid TLS-RPT DNS record

Yes if the TXT record contains v=TLSRPTv1.

Aggregate Report (RUA) addresses

Email addresses where daily TLS failure summaries are sent.

Failure Report (RUF) addresses

Optional addresses for individual TLS failure samples, rarely used.

Hosted TLS-RPT

Whether DNS is delegated to a third-party TLS-RPT hosting provider.

Error Details

Count of validation issues, No means the record passed all checks.

Best practices & recommendations

Publish TLS-RPT with MTA-STS

Set up both records together, MTA-STS enforces TLS, TLS-RPT reports when it fails.

Use a dedicated reporting mailbox

Create a rua address you monitor regularly, or route reports to a TLS analytics service.

Review reports before enforcing

While MTA-STS is in testing mode, check TLS-RPT reports for unexpected failures.

Re-check after DNS changes

Verify the record after updates to confirm rua addresses and syntax are correct.

Frequently asked questions

TLS Reporting (RFC 8460) lets domain owners receive aggregate reports about TLS connection failures when senders deliver mail to their domain.

As a TXT record at _smtp._tls.yourdomain.com, for example: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

TLS-RPT is most useful alongside MTA-STS. Without MTA-STS, reports still help monitor TLS health but enforcement is not configured.

rua specifies aggregate reporting addresses (like DMARC rua). Senders email daily summaries of TLS failures to these addresses.

JSON files attached to email, similar in concept to DMARC aggregate reports. Use a parser or reporting service to analyze them.

Nothing is published at _smtp._tls.yourdomain.com. Add a TXT record with v=TLSRPTv1 and a rua address to start receiving reports.

You can, but a dedicated tls-reports@ mailbox keeps TLS failure data separate from authentication reports.

Run this check once, or have it watched 24/7.

SenderSignal monitors these signals continuously: 48 blacklists, SPF, DKIM, DMARC, TLS and more, with alerts in Slack, email and signed webhooks.

Start monitoring free All free tools