So funktioniert’s
Stellt ein Mailserver eine Nachricht an deine Domain zu, sucht er die MX-Records heraus, verbindet sich auf Port 25 mit dem MX-Host und schaltet per STARTTLS auf TLS um. Ab dann sind Absender, Empfänger und Inhalt auf diesem Abschnitt verschlüsselt. Das ist Verschlüsselung von Server zu Server, keine Ende-zu-Ende-Verschlüsselung: Auf den Servern selbst liegt die Mail im Klartext.
Was diese Verschlüsselung taugt, hängt von zwei Dingen ab. Das Zertifikat des Mailservers sollte von einer öffentlichen CA stammen, gültig sein und den MX-Hostnamen enthalten, also etwa mail.example.com und nicht nur den Namen der Website. Die ausgehandelte TLS-Version sollte mindestens 1.2 sein; TLS 1.0 und 1.1 sind seit RFC 8996 abgekündigt.
Ohne MTA-STS oder DANE nehmen sendende Server es mit dem Zertifikat meist nicht genau und verschlüsseln auch mit einem abgelaufenen oder selbst signierten. Mit diesen Verfahren wird das Zertifikat dagegen streng geprüft: Ist es ungültig, unterbleibt die Zustellung.
Warum gefährlich
Ein abgelaufenes oder falsch benanntes Zertifikat am Mailserver fällt oft lange niemandem auf, weil die meisten Absender trotzdem zustellen. Sobald die Domain aber MTA-STS im Modus enforce oder DANE nutzt, bleiben Mails hängen und kommen nach Tagen als unzustellbar zurück.
Veraltete Protokolle wie TLS 1.0 und 1.1 lehnen viele Absender inzwischen ab. Je nach deren Einstellung landet die Mail dann im Klartext oder gar nicht bei dir. Und wer sich allein auf opportunistisches TLS verlässt, ist gegen Angreifer auf dem Netzweg nicht geschützt.
So vermeidest du es
- Auf jedem MX-Host ein Zertifikat einer öffentlichen CA installieren, dessen Namen den MX-Hostnamen enthalten, und es automatisch verlängern lassen.
- Nach jeder Verlängerung sicherstellen, dass der Maildienst das neue Zertifikat auch lädt, etwa per Reload von Postfix oder Exim.
- Mindestens TLS 1.2 erlauben, TLS 1.0 und 1.1 abschalten und TLS 1.3 aktivieren, wo die Software es unterstützt.
- Mit MTA-STS oder DANE festlegen, dass Absender nur verschlüsselt und mit gültigem Zertifikat zustellen, und mit TLS-RPT Berichte über Fehler einholen.
- Zertifikat und TLS-Version der Mailserver dauerhaft überwachen, nicht nur bei der Einrichtung.
So erkennt DomainWarn es
Der Check SMTP baut zu bis zu fünf MX-Hosts eine Verbindung auf Port 25 auf, handelt per STARTTLS TLS aus und bewertet das vorgezeigte Zertifikat. Abgelaufen, ungültige Kette, selbst signiert oder nicht passend zum MX-Hostnamen eröffnet den Incident „Mailserver-Zertifikat fehlerhaft“, eine Restlaufzeit unter 14 Tagen ist eine Warnung. Handelt ein Server nur TLS 1.0, 1.1 oder SSLv3 aus, folgt „Mailserver mit schwachem TLS“. Ein Zertifikatswechsel am Mailserver erscheint als Änderung.
Welche Cipher-Suites ein Server anbietet, listet DomainWarn nicht auf; bewertet werden die ausgehandelte Version und das Zertifikat. Der SMTP-Check läuft nur, wenn Port 25 für die Prüfserver freigeschaltet ist. Unabhängig davon kannst du den Check Zertifikat auf den Hostnamen eines Mailservers richten, mit STARTTLS auf Port 25, 587 oder 143 oder mit direktem TLS auf 465 oder 993.
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.