„certificate verification failed“ — wenn das MX-Zertifikat nicht trägt

Die vier Fehlerbilder

1. Name passt nicht. Das Zertifikat lautet auf mail.example.com, der MX-Record verweist aber auf mx1.example.com. Maßgeblich ist heute ausschließlich die Subject Alternative Name-Liste; ein Common Name allein genügt seit Jahren nicht mehr. Der Name im MX-Record muss dort stehen.
2. Intermediate fehlt. Der Server liefert nur sein Blattzertifikat. Browser gleichen das oft aus, Mailserver selten. Ausgeliefert werden muss die vollständige Kette — bei Let's Encrypt also fullchain.pem, nicht cert.pem.
3. Abgelaufen. Meist eine Erneuerung, nach der der Mailserver nie neu geladen wurde. Certbot fasst Postfix und Dovecot nicht von selbst an; ohne Deploy-Hook läuft das erneuerte Zertifikat auf der Platte, während im Speicher noch das alte steckt.
4. Selbstsigniert. Bei rein opportunistischem TLS unkritisch, unter MTA-STS oder DANE ein sofortiger Abbruch.

Wann es wirklich weh tut

Ohne Policy verschlüsseln Mailserver auch gegen ein ungültiges Zertifikat — die Alternative wäre Klartext, und das wäre schlechter. Deshalb bleibt der Fehler oft lange unbemerkt und steht nur als Warnung im Log.

Veröffentlichst du dagegen eine MTA-STS-Policy im Modus enforce oder einen TLSA-Record, wird die Prüfung verbindlich. Ab diesem Moment führt jedes Zertifikatsproblem zu abgewiesenen Mails — und zwar für alle Absender, deren Server die Policy beachten. Deshalb gehört vor jede Umstellung auf enforce eine Phase mit testing und ausgewerteten TLS-RPT-Berichten.

Prüfen