certificate-not-trusted
Your certificate is not from a trusted authority
By Jose Pollman · Published
How it appears in a report
"result-type": "certificate-not-trusted"What it means
Senders could not trace your certificate chain to a trusted root. Under MTA-STS that means the session is refused, because MTA-STS requires a publicly trusted certificate.
Your mail server. This is your own receiving setup. The report describes senders failing to reach your MX, so the certificate, policy or DNS record at fault is yours to fix.
Worth being clear about the direction, because it is easy to get backwards: you publish TLS-RPT for your own domain, and senders report the failures they hit while delivering to you. So policy-domain and receiving-mx-hostname in your reports are yours, and sending-mta-ip belongs to whoever sent the report.
Why it happens
Either a genuinely self-signed certificate — normal for SMTP for years, and not acceptable under MTA-STS — or a perfectly good certificate served without its intermediate. The second is the more painful case, because it works in a browser: browsers fetch missing intermediates, and mail servers do not.
How to fix it
- Test the full chain as your server actually serves it on port 25, not just the leaf certificate.
- If an intermediate is missing, configure the server to send the complete chain. This is the most common cause and it is invisible from a browser.
- If the certificate is self-signed, replace it with one from a public CA — under MTA-STS a self-signed certificate cannot pass.
- If your mail is hosted, send the chain test result to your provider.