Die vier üblichen Ursachen
- Keine gemeinsame Protokollversion. Aktuelle Server lehnen TLS 1.0 und 1.1 ab, ältere Gegenstellen können TLS 1.2 nicht. Bleibt keine Version übrig, endet der Handshake sofort. Das ist inzwischen die häufigste Ursache überhaupt.
- Keine gemeinsame Cipher-Suite. Seltener, aber möglich, wenn eine Seite auf moderne AEAD-Verfahren beschränkt ist und die andere nur alte CBC-Suiten anbietet.
- Unvollständige Zertifikatskette. Der Server liefert nur sein eigenes Zertifikat ohne Intermediate. Manche Clients ergänzen das selbst, andere brechen ab. Ein Test, der lokal funktioniert und von außen nicht, deutet fast immer hierauf.
- Eine Middlebox greift ein. Firewalls mit SMTP-Inspektion verstümmeln die
EHLO-Antwort oder dasSTARTTLS-Kommando, um mitlesen zu können. Erkennbar daran, dass der Server von außen kein STARTTLS anbietet, direkt auf ihm aber schon.
Selbst nachstellen
Der Handshake lässt sich einzeln prüfen, ohne eine Mail zu senden:
openssl s_client -starttls smtp -connect mx.example.com:25 -crlf
Interessant in der Ausgabe:
Protocol / Cipher → was ausgehandelt wurde
Verify return code → 0 (ok) oder ein Kettenfehler
Certificate chain → enthaelt sie das Intermediate?
Kommt gar keine Ausgabe, unterstützt die Gegenstelle STARTTLS nicht oder etwas dazwischen entfernt es. Ein EHLO im Klartext zeigt, ob 250-STARTTLS überhaupt angekündigt wird.
Wenn TLS erzwungen ist
Die Meldung „TLS is required, but was not offered“ ist ein anderer Fall: Hier hat deine Seite verpflichtendes TLS konfiguriert, die Gegenstelle bietet aber keines an. Das kann eine bewusste Richtlinie sein — oder eine MTA-STS-Policy beziehungsweise ein DANE-Record, der Verschlüsselung vorschreibt, während der Zielserver sie gerade nicht liefert.