Read your TLS reports
On every plan
A TLS report says whether the servers that delivered mail to your domain could encrypt their connections to your mail servers. Open the domain, then its TLS-RPT page. A failure there is about mail coming in to you, not mail you send. Each failure names a reason, and the reason says where to look.
Start getting them
TLS reports start once the domain has a TLS-RPT record at _smtp._tls.example.com with your reporting address in it. The Records tab builds it: see the TLS-RPT record. Our DNS checks tell you when the record is missing or sends the reports somewhere else.
What the page shows
The page covers the window you choose under Window, as the Reports page does.
- A card for each policy the reports covered, with its domain and its type: an MTA-STS policy, a DANE policy, or no policy published. The card lists the MX hosts the policy names. Its sentence sums up the window: how many sessions succeeded, how many failed, and the most common reason.
- A chart of succeeded and failed sessions, day by day.
- A table of failures, most sessions first. Each row says what happened in a sentence, with the fix where one is known, the receiving MX host, the sending server's IP address and the number of failed sessions.
- The reports, newest first. Each opens with the same three tabs as an aggregate report: Parsed, Raw and Download.
What each failure means
Each failure carries one of the result types RFC 8460 defines. The table of result types gives each one's sentence, and its fix where one is known. They fall into four groups:
- No encryption at all.
starttls-not-supported: the receiving server did not offer STARTTLS. Check that every MX host offers it. - The certificate on an MX host.
certificate-host-mismatch,certificate-expired,certificate-not-trustedandvalidation-failure. An expired certificate is renewed on the MX host. - DANE.
tlsa-invalid,dnssec-invalidanddane-required: the receiving server's TLSA record did not match its certificate, did not pass DNSSEC validation, or was missing where DANE was required. - Your MTA-STS policy.
sts-policy-fetch-error,sts-policy-invalidandsts-webpki-invalid: the sending server could not fetch the policy file over HTTPS, could not read it, or did not trust the certificate of the host that serves it.
The TLS failures alert
From Pro up, the TLS failures alert is on by default. It fires when one day's reports show at least 10 failed sessions, and the failures are at least 1 percent of that day's sessions. The alert gives the fix for the most common reason, where one is known. It stays quiet for 7 days after a domain's first report. From Teams up, an admin can change both thresholds.
The MTA-STS checks that go with them
The reports say what happened to the connections. Our DNS checks say what your MTA-STS policy asks for. In testing mode, sending servers report problems and deliver anyway. Enforced, they insist on TLS to your mail servers, and they refuse to deliver to a server the policy does not name.
Set the policy to testing first, read the TLS reports until they are clean, and only then set it to enforce. When the reports show sts-policy-fetch-error, our check of the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt says whether we could fetch it too.
Published 27 October 2026 · Checked 27 October 2026