SMTP-TLS: STARTTLS, Ports und Zertifikate verstehen

Was SMTP-TLS schützt – und was Sie dafür beobachten müssen

Bei SMTP mit STARTTLS beginnt die Unterhaltung unverschlüsselt. Der Server kann nach EHLO die Erweiterung STARTTLS anbieten. Nimmt der Client dieses Angebot an, folgt zunächst der TLS-Handshake. Erst nach dessen erfolgreichem Abschluss wird die weitere SMTP-Unterhaltung über TLS geführt. Das Angebot allein belegt noch keine verschlüsselte Verbindung. RFC 3207, Abschnitte 3–4

Der E-Mail Security Check untersucht für SMTP-TLS aus seiner Prüfumgebung auf Port 25 höchstens drei unterschiedliche MX-Hosts der niedrigsten numerischen Präferenz. Das ist eine Stichprobe des eingehenden Transports; weitere gleichrangige Hosts und alle Backup-Präferenzstufen bleiben ungemessen. Die Stichprobe belegt weder sämtliche MX-Server und Netzwerkwege noch den ausgehenden Versand, Submission oder eine tatsächlich zugestellte Nachricht. Lesen Sie deshalb neben einem Befund immer seine Abdeckung und gegebenenfalls den Fehlerstatus.

TLS schützt jeweils die Verbindung, nicht automatisch die Nachricht über ihre gesamte Reise. Mailserver können Inhalte nach dem Empfang verarbeiten und speichern. Auch die Identität im sichtbaren From wird durch Transport-TLS nicht bestätigt. Dafür sind andere Verfahren und Prüfungen zuständig: SPF, DKIM und DMARC.

Warum ein STARTTLS-Angebot allein keinen Downgrade verhindert

Ein Angreifer auf einem ungeschützten Übertragungsweg kann versuchen, das STARTTLS-Angebot zu entfernen. Bei rein opportunistischem Versand hängt die Reaktion auf fehlendes oder gescheitertes TLS von der Senderkonfiguration ab; ein Rückfall auf Klartext kann möglich sein. Eine bereits wirksam angewandte MTA-STS-Policy im Modus enforce oder erfolgreich validierte, nutzbare DANE-Daten ändern die Entscheidung des unterstützenden Senders. Er darf die Anforderungen nicht einfach durch Klartext umgehen. Die genaue Wirkung hängt von Policy, Cache, DNSSEC und Validierung ab. MTA-STS und DNS-Sicherheit/DANE erläutern diese Bedingungen.

Bei einem gehosteten Maildienst betreibt der Anbieter häufig TLS-Software, Zertifikate und Erneuerung. Sie müssen trotzdem den richtigen Dienst, die angebotenen Einstellmöglichkeiten und die verfügbaren Nachweise kennen. Bei einem eigenen Server übernehmen Sie diese Aufgaben selbst oder übertragen sie ausdrücklich an einen Betreuer.

Port 25, 587 und 465 haben unterschiedliche Aufgaben

Korrekt umgesetzt können Submission auf Port 587 mit verpflichtendem STARTTLS und implizites TLS auf Port 465 vergleichbare Sicherheit bieten. Die Auswahl richtet sich nach den dokumentierten Einstellungen des Versanddienstes. Die Bezeichnung „SSL“ in einem Mailprogramm meint dabei häufig implizites TLS und ist keine Empfehlung, alte SSL-Protokolle zu aktivieren. RFC 8314, Abschnitt 3.3

Übertragen Sie die TLS-Pflicht eines Submission-Dienstes nicht pauschal auf den öffentlich referenzierten MX-Empfang auf Port 25. RFC 3207 untersagt dort, STARTTLS allgemein zur Voraussetzung für lokale Zustellung zu machen. Die senderseitige Durchsetzung einer Transportpolicy ist davon zu unterscheiden. RFC 3207, Abschnitt 4

1  Client -> Server: TCP connection to mx.example.com:25
2  Server -> Client: 220 mx.example.com ESMTP
3  Client -> Server: EHLO client.example.net
4  Server -> Client: 250-mx.example.com
                    250-STARTTLS
                    250 SIZE 52428800
5  Client -> Server: STARTTLS
6  Server -> Client: 220 Ready to start TLS
7  Client <-> Server: TLS handshake
8  Client -> Server: EHLO client.example.net  [after successful TLS handshake]
9  Client -> Server: MAIL FROM / RCPT TO / DATA  [over established TLS]

TLS-Version und Cipher Suite getrennt beurteilen

TLS 1.3 ist die aktuelle Protokollgeneration; die aktuelle Spezifikation ist RFC 9846 vom Juli 2026. TLS 1.2 bleibt für bestehende Interoperabilitätsanforderungen relevant. Für Submission und Mailzugriff verlangen RFC 8314 und dessen Update RFC 8997 Unterstützung für TLS 1.2 oder neuer. Diese konkrete Anforderung betrifft nicht pauschal jeden SMTP-Empfang auf Port 25.

Bei TLS 1.3 beschreibt die Cipher Suite das AEAD-Verfahren und die Hashfunktion. Schlüsselaustausch und Signaturalgorithmus werden separat ausgehandelt. Beispiele für standardisierte TLS-1.3-Suites sind TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 und TLS_CHACHA20_POLY1305_SHA256. Diese Beispiele sind keine vollständige Konfiguration und keine BSI-Empfehlungsliste. RFC 9846

Für TLS 1.2 sind ECDHE mit AEAD-Verfahren eine geeignete Ausgangsbasis für die konkrete Systemkonfiguration. Beachten Sie den aktuellen Normstand: RFC 10015 vom Juli 2026 verbietet unter anderem endlichen DHE- und RSA-Schlüsselaustausch in TLS 1.2. Das ist kein Verbot von RSA zur Authentifizierung in einer ECDHE-RSA-Suite und betrifft nicht DHE in TLS 1.3. Ein alter Cipher-String sollte daher nicht allein wegen einer früheren Empfehlung unverändert übernommen werden. RFC 10015, Abschnitte 2–4

Die BSI TR-02102-2 enthält ein eigenes, datiertes Empfehlungsprofil. Ihre Fassung 2026-01 nennt beispielsweise andere TLS-1.3-Empfehlungen als die obigen Protokollbeispiele. Falls Sie dieses Profil benötigen, prüfen Sie auch Gruppen, Signaturen, Schlüssellängen und Anwendungszeitraum. Eine einzelne erfolgreiche Verbindung zeigt weder sämtliche angebotenen Suites noch die vollständige Erfüllung eines solchen Profils.

Zertifikate: Welche Identität wird wie geprüft?

Bei einer PKIX-basierten Prüfung müssen Name und Vertrauenskette zur Verbindung passen. Für MTA-STS verlangt der sendende MTA unter anderem eine gültige PKIX-Kette zu einem für ihn vertrauenswürdigen Root und den passenden MX-Namen in der subjectAltName-Erweiterung. Ein angezeigter Ausstellername oder Subject-CN allein belegt das nicht. RFC 8461, Abschnitt 4.2

Ein Wildcard-Name wie *.example.com deckt beim üblichen DNS-Namensabgleich genau eine linke Namensebene ab: mx.example.com, aber weder example.com noch mx.eu.example.com. Maßgeblich sind die Identitätsregeln des jeweiligen Protokolls; aktuelle allgemeine TLS-Regeln verwenden SAN-Identitäten statt eines CN-Fallbacks. RFC 9525, Abschnitt 6

Ein selbst signiertes oder abgelaufenes Zertifikat bedeutet deshalb nicht „gleichwertig mit Klartext“. Entscheidend sind ausgehandelte Verschlüsselung und tatsächlich angewandte Authentifizierung. Für die Interoperabilität müssen Sie allerdings sämtliche vorgesehenen Gegenstellen und deren Vertrauensmodelle berücksichtigen.

Mit OpenSSL gezielt prüfen

Das folgende Beispiel ist für die dokumentierten Optionen von OpenSSL 3.5 formuliert. Ersetzen Sie den Beispielhost durch einen eigenen oder autorisierten Dienst. Es wurde hier nicht ausgeführt.

openssl s_client -connect mx.example.com:25 -starttls smtp \
  -servername mx.example.com -verify_hostname mx.example.com \
  -verify_return_error -brief

-servername sendet SNI als Hinweis zur Zertifikatsauswahl. -verify_hostname fordert den angegebenen Namensabgleich an. -verify_return_error sorgt dafür, dass Verifikationsfehler den Prüfversuch abbrechen; ohne diese Option kann das Diagnosewerkzeug trotz solcher Fehler fortfahren. Dokumentieren Sie außerdem den verwendeten Vertrauensspeicher. Diese Prüfung bildet weder MTA-STS samt Policyabruf noch eine DNSSEC-/DANE-Validierung vollständig nach. Kontrollieren Sie für MTA-STS den SAN ausdrücklich, statt aus einem OpenSSL-Namensmatch jede Protokollanforderung abzuleiten. OpenSSL: s_client

Submission hat häufig einen anderen Hostnamen. Verwenden Sie dafür den vom Versanddienst angegebenen Namen:

openssl s_client -connect smtp.example.com:465 \
  -servername smtp.example.com -verify_hostname smtp.example.com \
  -verify_return_error -brief

openssl s_client -connect smtp.example.com:587 -starttls smtp \
  -servername smtp.example.com -verify_hostname smtp.example.com \
  -verify_return_error -brief

Unterdrücken Sie Fehlerausgaben nicht. Ein Timeout oder eine vom lokalen Netz blockierte Verbindung ist kein Nachweis fehlender TLS-Unterstützung. Die Beispiele führen keine Anmeldung und keinen Nachrichtenversand vor.

Zertifikate automatisiert erneuern und im Dienst übernehmen

Let's Encrypt stellt öffentlich vertrauenswürdige Zertifikate über ACME bereit. ACME ist ein geeigneter Automatisierungsweg, aber keine allgemeine SMTP- oder gesetzliche Pflicht. Wählen Sie ein Verfahren, das der Betreiber dauerhaft betreuen kann.

Ermitteln Sie zuerst die benötigten Namen. Ein Zertifikat für example.com deckt den MX mx1.example.com nicht allein dadurch ab, dass dieser die E-Mails der Domain empfängt. Umgekehrt kann die Domain selbst der tatsächliche Dienstname sein. Entscheidend ist die verwendete Referenzidentität.

Das folgende Certbot-Beispiel setzt einen selbst verwalteten Dienst, eine passende Certbot-Installation und administrativen Zugriff voraus. Für die Standalone-HTTP-01-Prüfung muss Port 80 lokal verfügbar und öffentlich für den angeforderten Namen erreichbar sein. Ist das nicht möglich, wählen Sie eine geeignete dokumentierte Challenge-Methode; ein DNS-Plugin benötigt eine eigene Einrichtung.

sudo certbot certonly --standalone --key-type ecdsa \
  --cert-name mx1.example.com -d mx1.example.com \
  --email admin@example.com --agree-tos

Die Beispielnamen und Kontaktadresse sind zu ersetzen. Prüfen Sie die ECDSA-Unterstützung der vorgesehenen Gegenstellen; ein RSA-Zertifikat kann eine andere Kompatibilitätsentscheidung sein. Zertifikatsschlüssel und TLS-Schlüsselaustausch sind unterschiedliche Dinge.

Nach der Ausstellung verbinden Sie den Dienst mit den richtigen Dateien: cert.pem enthält das Blattzertifikat, chain.pem die Zwischenzertifikate, fullchain.pem beide und privkey.pem den privaten Schlüssel. Der Schlüssel muss geschützt bleiben und für den zuständigen Dienst lesbar sein. Die benötigte Dateiform und der Ladevorgang hängen vom MTA ab.

Für eine bereits passend konfigurierte Postfix-Installation unter systemd kann ein erfolgreicher Deploy-Hook den Reload auslösen. Ein mögliches Skript im Certbot-Verzeichnis /etc/letsencrypt/renewal-hooks/deploy/ lautet:

#!/bin/sh
set -eu
systemctl reload postfix

Installieren Sie es mit passenden Eigentums- und Ausführungsrechten; verwenden Sie es nur, wenn dieser Dienstname und Reloadweg zu Ihrem System passen. Ein neuer Zertifikatsstand auf der Festplatte ist noch kein Beleg, dass der laufende Dienst ihn ausliefert.

sudo certbot renew --dry-run

Ein Dry-run prüft den Erneuerungsweg, führt Deploy-Hooks jedoch standardmäßig nicht aus. --run-deploy-hooks kann sie ausdrücklich einbeziehen; dabei verwendet Certbot nach erfolgreichem Dry-run das aktive Zertifikat, nicht das Testzertifikat. Prüfen Sie vor dieser Option die Auswirkungen des Hooks. Auch ein Exitstatus 0 von certbot renew beweist nicht allein eine neue Ausstellung oder einen gelungenen Reload: Es kann schlicht noch kein Zertifikat zur Erneuerung anstehen. Certbot: Verwendung und Hooks

Verlassen Sie sich nicht auf einen fest programmierten „alle 90 Tage“-Termin. Am 13. September 2026 beschreibt Let's Encrypt für classic 90 Tage, für tlsserver 45 Tage und für shortlived 160 Stunden. Die angekündigte Verkürzung von classic sieht 64 Tage ab 10. Februar 2027 und 45 Tage ab 16. Februar 2028 vor. Profile, ACME-Client und Erneuerungssteuerung müssen zusammenpassen; maßgeblich bleibt die tatsächlich ausgestellte Gültigkeit. Aktuelle Profile, angekündigter Zeitplan

CA/B-Laufzeiten: Ausstellungsdatum und Geltungsbereich beachten

Die CA/B-Baseline-Requirements betreffen öffentlich vertrauenswürdige TLS-Serverzertifikate in ihrem Anwendungsbereich. Sie sind keine universelle Laufzeitregel für jede private PKI oder jedes DANE-Zertifikat. Nach der aktuellen Fassung 2.3.0 gelten folgende Höchstwerte für neu ausgestellte Zertifikate:

Die Wiederverwendung einer Validierung und die Lebensdauer eines Zertifikats sind verschiedene Fristen. Die Stufen kürzen ältere Zertifikate nicht rückwirkend. Eine CA darf kürzere Zertifikate ausstellen, wie die Let's-Encrypt-Profile zeigen. Automatisierung wird dadurch betriebspraktisch wichtiger; daraus entsteht keine vorgeschriebene Bindung an Certbot oder ACME. CA/B Forum, Abschnitte 4.2.1 und 6.3.2

Postfix und Exim: dieselbe Aufgabe, unterschiedliche Stellschrauben

Die Tabelle ordnet dokumentierte Konfigurationsrollen zu. Sie ist keine getestete Konfiguration. Prüfen Sie vor einer Änderung die eingesetzte Version, die TLS-Bibliothek und die Richtung: Bei Postfix bezeichnet smtpd_ typischerweise den empfangenden SMTP-Server, smtp_ den ausgehenden SMTP-Client.

Ein encrypt-Wert bedeutet nicht automatisch vollständige Serverauthentifizierung. Auch ein MTA-STS-Resolver darf eine funktionierende DANE-Entscheidung nicht unbemerkt ersetzen. Primärbelege: Postfix TLS, Postfix TLS-RPT, Exim TLS.

TLS-RPT: Fehlerberichte sind eine andere Beobachtung

Ein aktiver Prüfversuch und ein TLS-RPT-Bericht beantworten verschiedene Fragen. Der DNS-/SMTP-Check von Wolf wertet keine TLS-RPT-Berichte aus. TLS-RPT sammelt Angaben teilnehmender sendender Systeme über deren Zustellversuche im Berichtszeitraum. Ein vorhandener DNS-Eintrag allein beweist weder, dass diese Systeme berichten, noch dass ein Bericht empfangen oder ausgewertet wurde. Ein leerer Posteingang ist kein Nachweis fehlerfreier Zustellung.

Die ersten vier Typen stehen in RFC 8460 Abschnitt 4.3.1; validation-failure ist der allgemeine Typ aus Abschnitt 4.3.3. Die Tabelle ist eine Erklärung der Berichtssprache und keine Messmatrix eines realen Systems. Ein solcher Fehler belegt für sich allein keinen Angriff.

Daneben stehen Policyfehler: etwa tlsa-invalid, dnssec-invalid und dane-required für DANE sowie sts-policy-fetch-error, sts-policy-invalid und sts-webpki-invalid für MTA-STS. Besonders wichtig: sts-webpki-invalid betrifft die PKIX-Authentifizierung beim HTTPS-Abruf der MTA-STS-Policy, nicht pauschal die Zertifikatskette des SMTP-Servers. RFC 8460, Abschnitt 4.3

REQUIRETLS und TLS-Required: No nicht verwechseln

Die SMTP-Erweiterung REQUIRETLS gibt eine Anforderung für die Weiterleitung einer Nachricht mit. Das Nachrichtenfeld TLS-Required: No bittet dagegen darum, empfangsseitige TLS-Policies bei dieser Nachricht zu übergehen; vorhandenes TLS soll weiterhin versucht werden. Sind beide vorhanden, hat die REQUIRETLS-Anforderung Vorrang. Diese Mechanismen hängen von den beteiligten Systemen und deren Unterstützung ab; ein MX-Handshake prüft sie nicht für die ganze Route. RFC 8689

Postfix unterstützt TLS-Required: No seit 3.10 und die SMTP-Erweiterung seit 3.11. Das sind verschiedene Versionsanschlüsse. Leiten Sie daraus keine Zusage für einen beliebigen gehosteten Versanddienst ab. Postfix REQUIRETLS

Technische Nachweise richtig begrenzen

Dokumentieren Sie Host, Port, Richtung, Zeitpunkt, Prüfumgebung, verwendetes Vertrauensmodell und beobachtetes Ergebnis. Bewahren Sie Fehler und offene Prüfstufen als solche auf. Logs und TLS-RPT können eine Untersuchung unterstützen, beweisen aber allein weder einen bestimmten Angriff noch die vollständige Transportstrecke einer Nachricht. Für die Auswertung konkreter Nachrichten hilft der Abschnitt zu Headerbefunden; für die Abgrenzung zu Absenderangriffen die Übersicht der Bedrohungen.

Rechtliche und vertragliche Anforderungen haben einen eigenen Geltungsbereich. Beispielsweise verlangt § 30 BSIG von den erfassten Einrichtungen angemessene, risikobezogene Maßnahmen; ein einzelnes Protokoll ist dadurch nicht für jede Organisation vorgeschrieben. Die BSI TR-03108 beschreibt ein konkretes Anforderungsprofil für E-Mail-Diensteanbieter mit weiteren organisatorischen und technischen Anforderungen. Ein TLS-Scan, ein Zertifikat oder ein Cipher-String ist kein vollständiger Konformitätsnachweis. § 30 BSIG, BSI TR-03108, Version 2.0

Auch Artikel 32 DSGVO nennt Verschlüsselung im Rahmen angemessener, risikobezogener Maßnahmen; er macht aus einem SMTP-TLS-Befund keine pauschale Datenschutzfreigabe. Die Einordnung dieser deutschen beziehungsweise europäischen Quellen ist keine Freigabe für andere Märkte oder ein Nachweis, dass eine Meldepflicht ausgelöst wurde. DSGVO, Artikel 32