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
• No external authorization → if you delegate to a third-party analyzer, its servers reject the reports

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, retrieves the published TXT record and resolves external authorization when needed.

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 with 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 → no external authorization needed
• The domain is different → verify the presence of [domain]._report._tls.[third-party] (cross-domain authorization)
• The https URI answers with valid HTTPS (light probe server-side)

Overall hygiene

• MTA-STS published in parallel (Hygiene bonus +2)
• No unknown tag polluting the record
• Policy consistent with the domain 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: the RFC forbids CNAME at this location. Publish a direct TXT instead.

External authorization required (rua_unauthorized_external)

Cause: the rua address uses a domain different from the TLS-RPT domain.

Fix: the receiving domain (e.g. uriports.com) must publish:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

This record authorizes report delivery for captaindns.com.

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.

Cross-domain authorization and external rua

RFC 8460 inherits the DMARC convention (RFC 7489 §7.1): a domain cannot ask another domain to receive its reports without explicit consent.

The mechanism

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

The external domain uriports.com must publish:

captaindns.com._report._tls.uriports.com. IN TXT "v=TLSRPTv1"

Without this record, compliant sending MTAs refuse to forward reports to uriports.com (they protect third-party analyzers from redirection abuse).

Common pitfalls

• Confusion with DMARC: DMARC uses _report._dmarc.[third-party], TLS-RPT uses _report._tls.[third-party]. Verify the correct prefix.
• Multiple watched domains: a multi-tenant analyzer (Postmark, Uriports, Dmarcian, Valimail, Sendmarc) must publish one record per client domain (client1.com._report._tls.postmarkapp.com, client2.com._report._tls.postmarkapp.com, etc.).
• No wildcard allowed: an explicit record per (watched domain, analyzer domain) pair is required.
• The checker automatically flags external rua entries without published authorization.

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 for 2 to 4 weeks the TLS-RPT reports 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
• RFC 7489 §7.1 - Cross-domain reporting