TLS-RPT Record Checker

What does this TLS-RPT checker verify?

This tool performs a complete analysis of TLS-RPT configuration for any domain:

1. DNS Lookup: Queries _smtp._tls.domain for TXT records
2. Syntax Validation: Checks RFC 8460 compliance
3. URI Verification: Validates all reporting addresses
4. External Authorization: Checks authorization records for third-party destinations
5. Best Practices: Recommends improvements

Understanding TLS-RPT records

DNS location

TLS-RPT records are published as TXT records at a specific subdomain:

_smtp._tls.captaindns.com  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@captaindns.com"

Record structure

Supported URI schemes

mailto: - Reports sent as email

rua=mailto:tlsrpt@captaindns.com

https: - Reports POSTed to endpoint

rua=https://tlsrpt.captaindns.com/report

External domain authorization

When reports go to an external domain, authorization is required.

Scenario

Your domain: captaindns.com Report destination: mailto:reports@analyzer.com

Authorization required

The external domain (analyzer.com) must publish:

captaindns.com._report._tls.analyzer.com  TXT  "v=TLSRPTv1"

What this tool checks

1. Detects external reporting destinations
2. Queries for authorization record
3. Reports missing authorization as error
4. Shows correct authorization record format

Common issues detected

No TLS-RPT record found

Cause: Domain hasn't configured TLS-RPT Impact: No TLS failure reports received Fix: Generate a TLS-RPT record and publish to DNS

Invalid version tag

Cause: Wrong version string (e.g., "v=TLSRPT1") Impact: Record ignored by sending servers Fix: Use exactly v=TLSRPTv1 (case-sensitive)

Missing reporting URI

Cause: No rua= tag in record Impact: Record invalid, no reports sent Fix: Add rua=mailto:address@domain.com or rua=https://endpoint

External authorization missing

Cause: Third-party destination hasn't authorized Impact: Reports to that destination may be rejected Fix: Request authorization record from destination domain

TLS-RPT and MTA-STS relationship

These two protocols work together:

Recommended deployment order

1. Deploy MTA-STS in testing mode

   • Policy at https://mta-sts.captaindns.com/.well-known/mta-sts.txt
   • DNS record at _mta-sts.captaindns.com

2. Configure TLS-RPT

   • Enables visibility before enforcing
   • See what would fail

3. Monitor reports

   • Check for unexpected failures
   • Identify misconfigured senders

4. Enforce MTA-STS

   • Switch from mode: testing to mode: enforce
   • Continue monitoring via TLS-RPT

Sample TLS-RPT reports

Reports are JSON documents (often gzip-compressed). Key fields:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2024-01-15T00:00:00Z",
    "end-datetime": "2024-01-16T00:00:00Z"
  },
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-domain": "captaindns.com"
    },
    "summary": {
      "total-successful-session-count": 1523,
      "total-failure-session-count": 12
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "203.0.113.1",
      "failed-session-count": 12
    }]
  }]
}

FAQ - Frequently asked questions

Q: What is TLS-RPT and what does this tool check?

A: TLS-RPT (SMTP TLS Reporting) is a DNS-based mechanism for receiving reports about TLS encryption failures when servers send email to your domain. This tool looks up the _smtp._tls.captaindns.com TXT record, validates its syntax against RFC 8460, checks reporting URIs, and verifies external domain authorization when needed.

Q: Where should the TLS-RPT record be published?

A: The TLS-RPT record must be published as a TXT record at _smtp._tls.captaindns.com. The record value starts with v=TLSRPTv1 and includes one or more reporting URIs.

Q: What is external domain authorization?

A: When your TLS-RPT record sends reports to an email address on a different domain (e.g., tlsrpt@thirdparty.com), the receiving domain must authorize this. They publish a TXT record at captaindns.com._report._tls.thirdparty.com with value v=TLSRPTv1. Without this, reports may be rejected.

Q: Why is my TLS-RPT record not found?

A: If no record is found, the domain hasn't configured TLS-RPT. This means no TLS failure reports will be received. To set up: 1) Generate a record with our TLS-RPT Generator, 2) Validate syntax, 3) Publish as TXT at _smtp._tls.captaindns.com, 4) Use this tool to verify.

Q: Should I use mailto or https for reporting?

A: mailto: is simpler - reports arrive as email attachments. https: enables automation via webhooks. Start with mailto: for visibility, add https: for monitoring tool integration. You can specify both in the same record.

Q: How does TLS-RPT relate to MTA-STS?

A: MTA-STS enforces TLS encryption for incoming mail. TLS-RPT reports when that enforcement fails. Without TLS-RPT, you won't know about connection failures. Deploy both: MTA-STS for security, TLS-RPT for visibility.

Complementary tools

Useful resources

• RFC 8460 - SMTP TLS Reporting (official specification)
• RFC 8461 - MTA-STS (companion protocol)
• Google Workspace - Configure TLS reporting
• Microsoft 365 - Inbound SMTP TLS