What this analysis does
Paste or upload a standard TLS-RPT report to quantify failed SMTP TLS sessions and identify the result types and receiving infrastructure responsible for the largest transport-security failures.
TLS reporting is the only routine signal showing when a sender could not establish the transport security your domain asked for. Without it, an MTA-STS policy is published on the assumption that it works, and failures are invisible until someone reports missing mail.
The failure class identifies the layer
Reports classify failures rather than describing them in prose, and the class points directly at the layer to investigate. Certificate problems — expiry, hostname mismatch, an incomplete chain — belong to the receiving MX configuration. Policy retrieval failures belong to the DNS record or the HTTPS endpoint serving the policy file.
Negotiation failures are a third class, indicating that a session could not agree on acceptable parameters. That usually means a protocol or cipher mismatch between a strict sender and a receiver still offering only legacy configurations.
- Certificate failures point at the receiving mail exchanger.
- Policy retrieval failures point at the DNS record or the HTTPS endpoint.
- Negotiation failures point at protocol or cipher mismatch.
A low failure count can still be a real problem
Failure volume reflects the sending pattern of the reporting senders, not the severity of the underlying fault. A misconfigured exchanger that receives little traffic produces few failures while being just as broken as a busy one.
Which sender reports the failure matters as much as how many. Consistent failures from a single major provider indicate a condition specific to that path, while the same failure appearing across several independent senders indicates a problem in your own configuration.
Audit the MTA-STS and TLS-RPT setupRead the failure type guide
Publish reporting before enforcing policy
The correct sequence publishes TLS-RPT first, then runs MTA-STS in testing mode, and only then moves to enforce. Reporting during the testing period is what turns an untested policy into a verified one, because senders report what would have failed without refusing any delivery.
Keep reporting in place permanently afterwards. Certificates expire, exchangers change, and providers update their requirements. TLS-RPT is the mechanism that surfaces those changes as data rather than as an outage.
Example: one exchanger with a name mismatch
Evidence supplied
A report showing certificate hostname-mismatch failures affecting a single receiving MX.
How to read the result
The analysis attributes the failures to that specific exchanger and identifies the certificate name as the layer to correct, distinguishing it from a policy retrieval or negotiation problem that would require a different fix.
Known limits
- Only senders that implement TLS reporting contribute data, so coverage is partial.
- Reports are aggregated over a period and do not identify individual messages.
- A report describes what a sender observed, which can differ from the current state of your configuration.
Common questions
Do TLS reports contain message content?
No. They summarize session outcomes and failure classes between sending and receiving infrastructure.
Is a zero-failure report a good sign?
It indicates no reported failures in that window from senders that report. It does not prove that every sender succeeded.
Can TLS-RPT be published without MTA-STS?
Yes, and it is a useful first step. Reporting alone provides visibility into transport failures before any policy is enforced.