SMTP TLS reporting policy
DNS & Records
DNS Lookup Every DNS record for any domain A Record Lookup IPv4 addresses for a domain AAAA Record Lookup IPv6 addresses for a domain MX Lookup Mail servers for a domain NS Lookup Authoritative name servers TXT Lookup TXT records, SPF, verification CNAME Lookup Canonical name (alias) records SOA Lookup Start of Authority record SRV Lookup Service location records CAA Lookup Which CAs may issue certificates Reverse DNS (PTR) IP address to hostname DNSSEC Check Is the domain signed and validated? DNS Health Check A full delegation & DNS report cardEmail Deliverability
SPF Check Validate your Sender Policy Framework record DMARC Check Inspect and grade your DMARC policy DKIM Check Find and validate your DKIM public key Blacklist Check Check an IP against email blocklists (DNSBLs) SMTP Test Connect to a mail server and check STARTTLS MTA-STS Check Enforced TLS policy for inbound mail BIMI Check Brand logo record for email TLS-RPT Check SMTP TLS reporting policyNetwork & Web
SSL Certificate Check Inspect a site's TLS certificate and expiry HTTP Header Check Inspect response headers, redirects and security Ping (TCP) Reachability and latency over TCP Port Check Which common ports are openDomain
WHOIS Lookup Registration data for domains, IPs and ASNsTLS-RPT (SMTP TLS Reporting) lets a domain receive daily reports about TLS connection failures from sending servers, so you can detect mail being delivered insecurely. IPeek reads the _smtp._tls TXT record and shows the reporting destinations. It complements MTA-STS and DANE by giving you visibility into how those policies perform in the wild.
TLS-RPT is published as a single DNS TXT record at _smtp._tls.your-domain. The record holds a version tag and an rua= tag listing where reports should be sent, either a mailto address or an HTTPS endpoint. Sending servers that support the standard aggregate the results of their TLS negotiations with your MX hosts over a day and deliver a JSON report to those destinations. Each report counts successful and failed sessions and categorizes failures, such as certificate validation errors or STARTTLS being unavailable, giving you a feedback loop on real delivery.
IPeek confirms whether the _smtp._tls TXT record exists and shows the rua destinations it parses. Verify the version is TLSRPTv1 and that each rua target is a valid mailbox or HTTPS URL you actually monitor. The record itself does not enforce anything; it only requests reports, so its presence means senders know where to send TLS failure data. Once reports arrive, look at the failure types: certificate-expired, validation failures, and starttls-not-supported each point to a specific fix on your receiving infrastructure before they cause silent delivery problems.
MTA-STS and DANE enforce TLS on inbound mail, but enforcement is only safe if you can see what it does to real traffic. TLS-RPT supplies that visibility: when you deploy MTA-STS in testing mode, the reports reveal which senders hit TLS failures before you switch to enforce. The same applies to DANE TLSA mismatches. Treat TLS-RPT as the monitoring layer for your TLS posture, deployed alongside, not instead of, the enforcement mechanisms, so you catch certificate and configuration problems early.
It is a TXT record published at _smtp._tls.your-domain that requests TLS failure reports. The record contains a v=TLSRPTv1 version tag and an rua= tag specifying where reports go, as a mailto address or an HTTPS URL. Sending servers that support TLS-RPT use it to know where to deliver their daily aggregate reports about TLS connections to your domain.
A TLS-RPT report is a JSON document summarizing one day of TLS negotiations between a sending server and your MX hosts. It counts successful and failed sessions and breaks failures down by type, such as expired certificates, certificate validation errors, or STARTTLS being unavailable. This lets you pinpoint which receiving hosts or certificates are causing insecure or failed deliveries.
No. TLS-RPT is purely a reporting mechanism and enforces nothing on its own. Enforcement comes from MTA-STS or DANE, which require TLS and can block insecure delivery. TLS-RPT sits alongside those policies as a monitoring layer, giving you visibility into how often TLS succeeds or fails so you can deploy enforcement confidently.
Publish a TXT record at _smtp._tls.your-domain containing v=TLSRPTv1 and an rua= tag pointing to a mailbox or HTTPS endpoint you monitor, for example rua=mailto:tlsrpt@your-domain. Choose a destination you actually watch, since reports arrive daily as JSON. Pair it with MTA-STS or DANE so the reports describe how your enforced TLS policy is performing.
TLS-RPT provides the visibility that makes MTA-STS safe to deploy. When you publish an MTA-STS policy in testing mode, sending servers report any TLS failures through TLS-RPT, so you see which senders would be blocked before switching to enforce. The two are designed to work together: MTA-STS sets the policy, and TLS-RPT tells you how it is performing in practice.