“certificate verification failed” — when the MX certificate does not hold

The four failure patterns

1. Name mismatch. The certificate says mail.example.com while the MX record points at mx1.example.com. Only the subject alternative name list counts today; a common name alone has not been sufficient for years. The name from the MX record has to be in there.
2. Missing intermediate. The server sends only its leaf certificate. Browsers often compensate, mail servers rarely do. The full chain must be served — with Let's Encrypt that means fullchain.pem, not cert.pem.
3. Expired. Usually a renewal after which the mail server was never reloaded. Certbot does not touch Postfix and Dovecot on its own; without a deploy hook the renewed certificate sits on disk while the old one is still in memory.
4. Self-signed. Harmless under purely opportunistic TLS, an immediate abort under MTA-STS or DANE.

When it actually hurts

Without a policy, mail servers encrypt even against an invalid certificate — the alternative would be plaintext, which is worse. That is why the fault often goes unnoticed for a long time, showing up only as a log warning.

Publish an MTA-STS policy in enforce mode or a TLSA record, however, and validation becomes binding. From that moment every certificate problem produces rejected mail — for every sender whose server honours the policy. This is exactly why a phase of testing with evaluated TLS-RPT reports belongs before any switch to enforce.

Checking