Features How it works Pricing Tools About Contact
Sign in Start now
Free Tool

TLS-RPT Report Analyzer

Upload your SMTP TLS reports to see whether mail to your domain is delivered over an encrypted connection, which servers fail, and why.

Reports are processed in your browser. Nothing is uploaded to our servers.

SMTP TLS Report Analysis
MailIntela product of CloudNow Solutions
Total Sessions
SMTP connections reported
TLS Success Rate
sessions delivered over valid TLS
Reporting Sources
organizations that sent reports
Findings

Want ongoing visibility into your email security?

MailIntel watches your DMARC reports continuously and alerts you when something needs attention.

Apply for monitoring
Analytics
Sessions per day
SuccessfulFailed
Failure types
failed sessions by reason
Policies by domain
Reporting organizations
Failure details
DateReporterDomainFailure typeReceiving MXReceiving IPSessions
Each report covers one day of connection attempts made by the reporting organization's mail servers to your domain. Report data was processed locally in the browser and was not uploaded. Generated with MailIntel TLS-RPT Report Analyzer.
Guide

Understanding SMTP TLS and MTA-STS reports

TLS-RPT reports tell you whether other mail servers could connect to yours securely. They're the only way to know if MTA-STS or DANE is blocking legitimate mail.

What is a TLS-RPT report?

SMTP TLS Reporting (TLS-RPT, RFC 8460) lets mail providers such as Google and Microsoft send you a daily summary of their attempts to deliver mail to your domain over an encrypted connection.

Each report is a JSON file, usually compressed as .json.gz. It lists how many connections succeeded, how many failed, and the reason for each failure, such as an expired certificate or a mail server that doesn't support encryption. Reports never include message content.

How do I start receiving reports?

Publish a DNS TXT record at _smtp._tls.yourdomain.com:

v=TLSRPTv1; rua=mailto:tls-reports@yourdomain.com

Reports usually start arriving within a day or two. TLS-RPT is most useful alongside MTA-STS, which tells sending servers to require a valid encrypted connection to your mail servers, and DANE, which does the same using DNSSEC.

Common failure types and what to fix

  • starttls-not-supported: one of your mail servers doesn't offer encryption. Enable STARTTLS on it.
  • certificate-expired / certificate-not-trusted: renew the certificate, or install the full certificate chain from a trusted authority.
  • certificate-host-mismatch: the certificate doesn't cover the MX hostname. Issue one that includes it.
  • sts-policy-fetch-error / sts-webpki-invalid: senders couldn't load your MTA-STS policy over HTTPS. Check the mta-sts. subdomain and its certificate.
  • sts-policy-invalid: the MTA-STS policy file has a syntax error, or doesn't list all your MX hosts.

Common questions

Is it safe to upload my reports here?
Yes. The analyzer runs entirely in your browser, and your files are never uploaded to our servers.
Which file formats are supported?
Raw .json reports and compressed .json.gz, .gz and .zip files. You can analyze several at once.
What does "no-policy-found" mean?
The sender found no MTA-STS or DANE policy for your domain. Mail was still delivered, but senders weren't required to use encryption.
Are TLS-RPT reports the same as MTA-STS reports?
Yes. People often call them MTA-STS reports, because TLS-RPT is how senders report MTA-STS (and DANE) results back to you. The reports use the same JSON format either way.
Testing or enforce mode?
In testing mode, failures are only reported. In enforce mode, servers that honor MTA-STS won't deliver over an insecure connection, so fix all failures before switching.