Auf welchen Namen das Zertifikat lauten muss
Nicht auf die Domain, sondern auf den MX-Hostnamen — also auf das, was im MX-Record steht:
Das Zertifikat der Website ist der häufigste Fehlgriff: Es lautet auf deinedomain.de und www.deinedomain.de, aber ein prüfender Absender verbindet sich zu mail.deinedomain.de und findet diesen Namen nicht. Entweder das Zertifikat bekommt den MX-Namen als zusätzlichen SAN-Eintrag, oder der Mailserver bekommt ein eigenes.
Bei mehreren MX-Hosts braucht jeder seinen Namen im Zertifikat — als eigenes Zertifikat je Host oder als ein Zertifikat mit allen Namen im SAN.
Vier Namen, die zusammenpassen sollten
Für eine saubere Einrichtung zeigen alle auf dasselbe:
- Der MX-Record nennt
mail.deinedomain.de. - Der PTR-Record der IP löst auf
mail.deinedomain.deauf, und dieser Name wieder auf dieselbe IP. - Der HELO-Name, mit dem der Server sich meldet, ist derselbe.
- Das Zertifikat lautet auf diesen Namen.
Diese vier Übereinstimmungen sind der stärkste einzelne Faktor für die Reputation eines eigenen Mailservers — wichtiger als jede Feineinstellung am Filter. Wie der PTR-Teil eingerichtet wird, steht unter Reverse DNS einrichten.
Die Kette muss vollständig sein
Ein häufiger Fall: Im Browser sieht das Zertifikat gut aus, per SMTP schlägt die Prüfung fehl. Ursache ist eine fehlende Zwischenzertifizierungsstelle. Browser holen fehlende Glieder oft selbst nach, SMTP-Clients tun das nicht. Ausgeliefert werden muss deshalb die vollständige Kette:
In der Ausgabe muss unter Certificate chain mehr als ein Zertifikat stehen, und am Ende Verify return code: 0 (ok).
Der Hook, der fast immer fehlt
Eine automatische Erneuerung schreibt neue Dateien — der laufende Mailserver arbeitet aber mit dem, was er beim Start gelesen hat. Ohne einen Reload nach der Erneuerung liefert er das alte Zertifikat weiter aus, bis es abläuft. Das Ergebnis ist dann 454 4.7.0 TLS not available oder eine fehlgeschlagene Prüfung beim Gegenüber.
Der Reload gehört deshalb in den Erneuerungsvorgang selbst, nicht in einen separaten Zeitplan. Ebenso zu prüfen: ob der unprivilegierte Prozess die neuen Dateien überhaupt lesen darf — nach einer Erneuerung gehören sie oft wieder root allein.
Selbst ausgestellt oder von einer CA?
- Opportunistische Verschlüsselung: beides gleichwertig. Der Absender prüft nicht, er verschlüsselt nur.
- MTA-STS: Es muss ein Zertifikat einer öffentlichen CA sein und auf den MX-Namen lauten. Ein selbst ausgestelltes führt im
enforce-Modus zur Zustellverweigerung. - DANE: Mit Usage 3 funktioniert auch ein selbst ausgestelltes Zertifikat, weil der TLSA-Record selbst der Vertrauensanker ist.
Wer beides einsetzt, nimmt ein CA-Zertifikat auf den MX-Namen — damit sind beide Verfahren abgedeckt.
Prüfen
Der MX-Check baut zu jedem MX-Host eine echte STARTTLS-Verbindung auf und zeigt Aussteller, Namen im SAN, Restlaufzeit, Schlüsselstärke und ob die Kette verifiziert werden konnte.