TLS-RPT Checker

Verify your SMTP TLS Reporting (TLS-RPT) record used to receive diagnostic reports about inbound TLS mail delivery issues.

Beta Feature

TLS-RPT (SMTP TLS Reporting) detects issues with mail transport encryption. Enhanced report parsing and failure correlation is planned for the next update.

Our TLS-RPT Checker retrieves the SMTP TLS Reporting record at _smtp._tls.yourdomain.com and validates its reporting destinations. TLS-RPT is what turns silent email encryption failures into daily reports you can actually act on.

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) is a standard, defined in RFC 8460, that asks sending mail servers to send you a daily report whenever they have trouble establishing a secure connection to your mail servers.

It is published as a DNS TXT record at _smtp._tls.yourdomain.com and contains one or more destinations — a mailto: address or an https: endpoint — where reports should be delivered.

The reports are JSON documents summarising successful and failed sessions, with the reason for each failure: an expired certificate, a hostname mismatch, a STARTTLS negotiation that did not complete, or an MTA-STS policy that could not be validated.

Delivers daily reports on inbound TLS connection failures
Published as a TXT record at _smtp._tls.yourdomain.com
Reports arrive as JSON, usually gzip compressed
Defined in RFC 8460 as the companion to MTA-STS
Reports come from major providers including Google and Microsoft

Why TLS-RPT Matters

SMTP TLS failures are invisible by design. When a sending server cannot negotiate encryption, it usually falls back to plaintext and delivers the message anyway. Nothing is logged on your side, no alert fires, and you have no way of knowing that mail arrived unencrypted.

TLS-RPT is the only mechanism that gives you that visibility. It is also what makes MTA-STS safe to deploy: without reports, moving to enforce mode means guessing whether your policy is correct, and the first sign of a mistake is bounced mail from real senders.

TLS failures are otherwise completely silent on the receiving side
Reveals expired or mismatched certificates before they cause rejections
Essential for validating an MTA-STS policy before enforcing it
Can expose active downgrade attacks against your inbound mail
Costs nothing beyond a single DNS record and a mailbox

How This TLS-RPT Checker Works

The tool queries the TLS-RPT DNS record and validates each reporting destination it declares.

Validates the domain input against format and SSRF safety checks
Queries DNS for a TXT record at _smtp._tls.yourdomain.com
Parses the v=TLSRPTv1 version tag and the rua= destinations
Validates that each destination is a well-formed mailto: or https: URI
Reports whether reporting is correctly configured

How to Use the TLS-RPT Checker

Enter your domain name in the input field
Run the check to retrieve the TLS-RPT record
Confirm the record starts with v=TLSRPTv1
Check that each rua= destination is an address or endpoint you monitor
If no record is found, publish one before deploying MTA-STS

Understanding Your TLS-RPT Results

A TLS-RPT record is short, but each part has a specific role:

Field / Value	Meaning
`v=TLSRPTv1`	The version tag. Required, and it must be the first tag in the record.
`rua=mailto:`	An email address that receives the daily JSON reports as attachments. The simplest option, and it can be a mailbox on the same domain.
`rua=https:`	An HTTPS endpoint that receives reports by POST. Preferred at scale, since the volume of report mail can be substantial.
`Multiple rua`	Several destinations separated by commas. All of them receive a copy, which is useful when both your team and a monitoring vendor need the data.
`No record`	No reports are sent. Any TLS failure on inbound mail happens silently, and you have no way to detect it.

Common Problems & How to Fix Them

You have no visibility into inbound TLS failures at all.

Add a TXT record:
Name: _smtp._tls
Value: v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

Use a dedicated mailbox rather than a personal one — reports arrive daily from every major provider and will quickly clutter an inbox that is used for anything else.

JSON reports are difficult to interpret by hand, so in practice they accumulate unread and the record provides no value.

Route them to a parser. Several free and commercial services ingest TLS-RPT reports and present failures as a dashboard. At minimum, set an alert on the volume of failure reports so a spike is noticed.

If your own mail is broken, reports about the breakage cannot be delivered either — a circular dependency that hides exactly the problems you most need to see.

Point rua= at a mailbox on a different domain, or add a second destination on independent infrastructure so reports still arrive during an outage.

The version tag must be exactly v=TLSRPTv1 and must come first. Destinations must be valid URIs including the mailto: or https: scheme.

A common mistake is writing a bare email address without the mailto: prefix, which makes the whole record invalid. Re-check the syntax and republish.

Best Practices

Publish TLS-RPT before deploying MTA-STS so you have data from day one
Use a dedicated mailbox rather than a personal or shared inbox
Point at least one destination at infrastructure independent of the domain itself
Feed reports into a parser rather than reading raw JSON
Review reports weekly, and daily during an MTA-STS rollout
Set an alert on sudden increases in failure volume
Keep the record in place permanently, not just during a migration

Security Recommendations

Treat a sudden spike in TLS failures as a possible active downgrade attack, not merely a certificate problem
Ensure the reporting destination is monitored, since an unread report is equivalent to no reporting at all
Use HTTPS endpoints for high volumes, and confirm the endpoint itself is authenticated and rate-limited
Be aware reports are submitted by third parties, so treat their contents as untrusted input in any parser you build
Avoid pointing reports exclusively at a mailbox on the domain being monitored
Correlate TLS-RPT data with certificate expiry monitoring to catch problems before senders do

Frequently Asked Questions

TLS-RPT is a standard that asks sending mail servers to report failures in establishing encrypted SMTP connections to your domain. It is published as a DNS TXT record at _smtp._tls.yourdomain.com and delivers daily JSON reports.

No, they are independent, and TLS-RPT is useful on its own for spotting certificate and STARTTLS problems. That said, they are designed as a pair — deploying TLS-RPT first is what makes an MTA-STS rollout safe.

A JSON summary of successful and failed sessions over a 24-hour period, with the failure type for each — certificate expired, hostname mismatch, STARTTLS not supported, or MTA-STS policy validation failure — plus the sending IP addresses involved.

One per sending organisation per day, so typically a handful from the major providers such as Google, Microsoft and Yahoo. Volume scales with how many distinct organisations send you mail, which is why a dedicated mailbox is recommended.

Yes. Point the rua= tag at whatever address or endpoint the service provides. You can list multiple destinations separated by commas so your own team and a vendor both receive copies.

No. It reports on failures that other servers encounter when connecting to you. For outbound visibility you would need the recipient domain to publish its own TLS-RPT record, and your own sending infrastructure to generate reports for it.

Yes, precisely because TLS failures are silent. Mail that arrives unencrypted still arrives, so everything looks fine from the outside. TLS-RPT is the only way to find out that it happened.