TLSRPT Lookup
TLSRPT Lookup helps you check tls reporting policy for smtp, for email authentication analysis, policy checks, and delivery troubleshooting.
Advertisement · Anuncio
Advertisement · Anuncio
Technical Analysis & Guide
What It Does
The TLS-RPT checker resolves the TXT record at _smtp._tls.<domain>, confirms it begins with v=TLSRPTv1 and splits the rua= tag into its individual reporting destinations. It then tells you how many endpoints were found and whether they include a mailto: address, an https: URL or both. The check is DNS-only: it does not send test reports, verify that the mailbox exists or read any reports you have received.
Why It Matters
- →Visibility into silent failures: Without TLS-RPT, a sender that cannot negotiate TLS with your MX just retries or downgrades, and you never learn it happened.
- →Safe MTA-STS and DANE rollouts: Reports in testing mode reveal certificate mismatches and missing MX patterns before enforce mode starts deferring real mail.
- →Certificate expiry alarms: A spike in certificate-expired failures from multiple senders is often the first signal that renewal automation broke on one MX.
- →Attack detection: Sudden starttls-not-supported results from one network can point to a middlebox stripping STARTTLS on the path to your servers.
- →Vendor accountability: When a hosted mail gateway handles inbound mail, reports give you independent evidence of its TLS behavior.
How to Read Results
- WARN 'TLS-RPT not configured': No TXT value beginning with v=TLSRPTv1 was found at _smtp._tls; the remediation shows a ready-to-adapt record.
- PASS 'TLS-RPT configured — N reporting endpoint(s)': The record parsed and N destinations were extracted from rua=.
- record: The full TXT string as published, useful for spotting typos such as a missing semicolon or a space inside the URI list.
- reportingEndpoints: Each destination on its own line, in the order receivers will see them.
- hasEmailReporting / hasHttpsReporting: Whether at least one mailto: or https: destination is present. Either alone is valid; HTTPS endpoints receive reports by POST.
- What PASS does not prove: That the mailbox accepts large gzip attachments or the HTTPS endpoint returns 2xx; confirm by checking that reports actually arrive within a day or two.
Technical Background
SMTP TLS Reporting is defined in RFC 8460 as the feedback channel for MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672). A domain publishes a single TXT record at _smtp._tls.example.com, for example v=TLSRPTv1; rua=mailto:[email protected],https://reports.example.com/tlsrpt. The rua tag accepts one or more comma-separated URIs using either the mailto: or https: scheme. If a resolver returns several records starting with v=TLSRPTv1, RFC 8460 tells senders to treat the domain as not participating, so stale duplicates effectively disable reporting.
Sending MTAs that support TLS-RPT keep counters of every SMTP session to your domain and, once per day, aggregate them into a JSON document with the media type application/tlsrpt+json, usually compressed as application/tlsrpt+gzip. Each report names the reporting organization, a date range in UTC, and one or more policy blocks. A policy block states which policy type applied (sts, tlsa or no-policy-found), the policy string itself, a total-successful-session-count, a total-failure-session-count and failure-details entries.
Failure-details explain exactly what went wrong. Result types include starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted and validation-failure for TLS negotiation problems; sts-policy-fetch-error, sts-policy-invalid and sts-webpki-invalid for MTA-STS policy retrieval issues; and tlsa-invalid, dnssec-invalid and dane-required for DANE. Entries also carry the sending MTA IP, the receiving MX hostname and the IP that was contacted, which makes it possible to pinpoint one misbehaving host in a pool.
Delivery of the reports follows the URI scheme. For mailto:, the report is sent as an email with the compressed JSON attached and a subject in the form Report Domain: example.com Submitter: mail.example.org Report-ID: <id>. For https:, the sender POSTs the report body to the URL and expects a 2xx answer. Unlike DMARC, RFC 8460 does not require a verification record when reports go to a different domain, so pointing rua at a third-party analysis service only needs the TXT entry.
TLS-RPT costs nothing to publish and has no effect on mail flow, so it belongs at the very start of any MTA-STS or DANE project. Expect the first reports within 24 to 48 hours from large providers, and a mailbox that receives only a few small attachments per day for most domains. Our checker confirms the DNS side; the real proof is reports arriving at the address listed.
Common Errors and How to Fix Them
- ProblemThe record is published at _tls._smtp.example.com or _smtp-tls.example.com, so senders never find it.
- FixThe label order is fixed by RFC 8460: create the TXT record at _smtp._tls.example.com exactly.
- ProblemThe rua value is written as [email protected] without a scheme.
- FixPrefix each destination with mailto: or https:, for example rua=mailto:[email protected], and separate several destinations with commas.
- ProblemTwo TXT records starting with v=TLSRPTv1 exist after a provider change, and reports stop arriving.
- FixSenders ignore the domain when more than one TLSRPT record is present. Merge the destinations into a single record with comma-separated rua URIs and delete the duplicate.
- ProblemThe reporting mailbox rejects messages with compressed attachments or has a tiny size limit, so reports bounce.
- FixUse a dedicated mailbox that accepts application/gzip attachments, whitelist it from attachment-stripping filters, or switch to an https: endpoint.
- ProblemReports arrive but nobody reads them, and an expired MX certificate goes unnoticed for weeks.
- FixRoute reports to a parser or monitoring service and alert when total-failure-session-count rises or when certificate-expired or sts-policy-fetch-error results appear.
Frequently Asked Questions
What is a TLS-RPT record and do I need one?
It is a DNS TXT record at _smtp._tls.yourdomain that tells other mail servers where to send daily reports about TLS problems when delivering to you. It does not change how mail flows, so it is safe to publish anytime. If you use or plan to use MTA-STS or DANE, it is essential; otherwise it still reveals certificate and STARTTLS issues you would not see.
How long until I receive TLS-RPT reports?
Reports cover a full UTC day and are sent after it ends, so the first ones typically arrive 24 to 48 hours after publishing the record. Only senders that implement RFC 8460 report, which includes several large mailbox providers. Low-volume domains may receive reports only on days when those providers actually delivered mail to them.
Can TLS-RPT reports go to a different domain or a third-party service?
Yes. RFC 8460 does not require the receiving domain to publish an authorization record, unlike DMARC external reporting. You can point rua=mailto: at a reporting service's address or use an https: URL they provide. Make sure the service can parse gzip-compressed JSON in the application/tlsrpt format.
What does sts-policy-fetch-error mean in a TLS-RPT report?
The sender found your _mta-sts TXT record but could not download the policy from https://mta-sts.yourdomain/.well-known/mta-sts.txt. Typical causes are a missing or invalid certificate on the mta-sts host, an HTTP redirect, a 404, or a timeout. Fix the hosting, then change the id in the TXT record so senders retry with confidence.
Is TLS-RPT the same as DMARC reporting?
No. DMARC aggregate reports, defined in RFC 7489, describe whether messages claiming to be from your domain passed SPF and DKIM alignment when you send mail. TLS-RPT describes whether other servers could set up encrypted connections when sending mail to you. They use different DNS names, formats and recipients, and most domains benefit from both.
Academic Documentation
Protocol context and primary references
DMARC.org
Domain-based Message Authentication standard
Open source →
SPF Project
Sender Policy Framework documentation
Open source →
IETF
Internet Engineering Task Force
Open source →
RFC Editor
Official RFC documentation
Open source →
IANA
Internet Assigned Numbers Authority
Open source →
M3AAWG
Operational guidance for email authentication and abuse handling.
Open source →
REST API Documentation
v1.0GET /api/tools/tlsrpt
curl -X POST https://epcybertools.com/api/tools/tlsrpt \
-H "Content-Type: application/json" \
-d '{"domain":"google.com"}'
{
"success": true,
"results": [
{ "test": "Sample Check", "status": "pass", "message": "All clear" }
]
}
Usage Examples
# Read the reporting record
dig +short TXT _smtp._tls.example.com
# Decompress a report saved from email and pretty-print the summary
gunzip -c report.json.gz | python3 -m json.tool | grep -E 'result-type|session-count'