TLS-RPT Checker

Why check your TLS-RPT

SMTP transport uses TLS opportunistically: if negotiation fails, the connection falls back to cleartext silently. Your emails go out in the clear and nobody warns you. Worse, a man-in-the-middle can actively strip STARTTLS to force that fallback.

TLS-RPT (RFC 8460) does not fix the encryption gap (MTA-STS does), but it finally gives you visibility. Every sending MTA that fails to establish TLS emits a JSON report to the rua address you publish. Without this mechanism, you are blind.

Verifying the configuration before forgetting about it in a corner of DNS is essential:

• Missing record → you know nothing about TLS failures, no audit trail
• Invalid rua URI → MTAs cannot deliver the reports, they get dropped
• Multiple records → sending MTAs ignore a duplicated TLS-RPT, no report is sent

Common use cases:

• After publishing → confirm the record is correctly propagated
• Email security audit → validate TLS coverage and failure visibility
• Before MTA-STS enforce → make sure TLS-RPT collects reports during the testing phase

How to use this checker in 3 steps

Step 1: enter the domain to analyze

Type the domain exactly as it appears in your email addresses:

• captaindns.com (main domain)
• marketing.captaindns.com (subdomain if you send from a subdomain)

The tool automatically queries _smtp._tls.domain and retrieves the published TXT record.

Step 2: review the results

The checker displays:

Step 3: fix the flagged issues

Results are graded by severity:

• Critical → the record is invalid, no report will be sent
• Warning → working but exposes risk or partial coverage
• Info → non-blocking best practice (unknown tag, MTA-STS missing)

Fix the DNS, wait for propagation, then run the checker again.

What is TLS-RPT

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a mechanism that:

1. Publishes a report address in DNS for the receiving domain
2. Asks sending MTAs to emit a JSON report when TLS fails
3. Provides a trail of encryption failures (expired certificate, downgrade, mismatch)

The architecture is deliberately minimal: a single TXT record published at _smtp._tls.domain, containing the version and one or more rua= URIs.

Example TLS-RPT record:

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

This record tells sending MTAs (Gmail, Outlook, etc.) to send their TLS failure reports to tls-reports@captaindns.com.

Difference from MTA-STS: TLS-RPT is the companion of MTA-STS, not an alternative. MTA-STS enforces TLS encryption, TLS-RPT reports failures. The two protocols live at separate locations (_mta-sts.domain for STS, _smtp._tls.domain for RPT) and work together.

What the checker verifies

Five dimensions are analyzed in parallel to produce a 0-100 score:

Published DNS record

Record syntax

Reporting URIs

rua quality

• The rua URI domain matches the checked domain (internal destination)
• The domain is different (external destination): valid with no recipient-side authorization
• The https URI answers with valid HTTPS (light server-side probe)

Overall hygiene

• MTA-STS published alongside (score bonus +2)
• No unknown tag polluting the record
• Policy consistent with the domain's mail deployment

Common diagnostics and fixes

Missing record (missing_record)

Cause: no TXT exists at _smtp._tls.captaindns.com.

Fix: publish

_smtp._tls.captaindns.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

Missing rua tag (rua_missing)

Cause: the record contains v=TLSRPTv1 but no destination.

Fix: add at least one URI: v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com. Without rua, no MTA will send a report.

Invalid rua URI (rua_invalid_uri)

Cause: the URI is malformed (missing mailto:, whitespace in the address, unknown scheme).

Fix examples:

- rua=tls-reports@captaindns.com         # Missing mailto:
+ rua=mailto:tls-reports@captaindns.com

- rua=mailto: tls-reports@captaindns.com # Whitespace after mailto: forbidden
+ rua=mailto:tls-reports@captaindns.com

Multiple records (multiple_records)

Cause: more than one TLS-RPT TXT exists at _smtp._tls.captaindns.com.

Fix: RFC 8460 §3 mandates a single record. Identify duplicates, keep the one to apply, remove the rest.

CNAME on _smtp._tls (cname_on_smtp_tls)

Cause: _smtp._tls.domain is a CNAME pointing elsewhere.

Fix: no RFC forbids a CNAME at this location. The checker reports it as a warning, not an error: Microsoft 365 ignores an aliased _smtp._tls. A direct TXT record remains the safe setup.

MTA-STS companion missing (mta_sts_companion_missing)

Cause: TLS-RPT is published but MTA-STS is not.

Fix: deploy MTA-STS to give TLS-RPT reports a purpose. See the MTA-STS Checker and the complete guide.

Send reports to a third-party domain

You can direct your TLS-RPT reports to a domain you do not control, for example a third-party analyzer. Unlike DMARC, RFC 8460 defines no recipient-side authorization record: a rua pointing to a third-party domain works with no extra publication.

The mechanism

Your domain: captaindns.com rua URI: mailto:tls-reports@uriports.com

No record is required on uriports.com. The report is sent directly. Trust rests on two safeguards laid out in RFC 8460 §7:

• mailto: the report is DKIM-signed by the sending MTA, which authenticates its origin.
• https: the destination domain controls its own collection endpoint (DNS ownership).

RFC 8460 §7 deliberately dropped any additional verification mechanism, since the amplification risk is lower than with DMARC.

Common pitfalls

• Do not carry over the DMARC mechanism: DMARC requires a [domain]._report._dmarc.[third-party] record to authorize a rua to a third-party domain. TLS-RPT has no equivalent. Publishing a _report._tls record is pointless and no MTA expects it.
• Verify the destination: simply make sure the mailto address or the https collection URL is correct and operational.

TLS-RPT and MTA-STS: combined deployment

The two protocols form defense in depth:

Recommended deployment order

1. Publish TLS-RPT first to collect reports
2. Deploy MTA-STS in testing mode without blocking delivery
3. Observe the TLS-RPT reports for 2 to 4 weeks to identify problem MX hosts
4. Switch MTA-STS to enforce mode when reports are clean
5. Keep TLS-RPT indefinitely for continuous monitoring

Without MTA-STS: TLS-RPT reports failures but no policy compels sending MTAs to use TLS. You see the problems without being able to prevent them.

Without TLS-RPT: MTA-STS enforces TLS but you will never know that a legitimate MTA is blocked by your policy. Risk of silent non-delivery.

Complementary tools and resources

Resources:

• TLS-RPT: the complete guide
• Configure TLS-RPT on Microsoft 365, Google Workspace and OVHcloud
• Analyzing TLS-RPT reports day-to-day
• RFC 8460 - SMTP TLS Reporting
• RFC 8461 - MTA-STS