SMTP-TLS — generische Anleitung nach RFC + BSI
Diese Anleitung gilt für jeden RFC-konformen Mailserver: Postfix, Exim, sendmail, Halon, OpenSMTPD oder kommerzielle MTAs. Die Anforderungen kommen aus RFC 5321, RFC 3207, RFC 8314 und der BSI-Compliance-Triple BSI TR-03108, BSI TR-02102-2 und DSGVO Art. 32.
SMTP-TLS vendor-neutral nach Standards
Wer keinen der dokumentierten Provider nutzt — sondern sendmail, OpenSMTPD, Halon oder einen kommerziellen MTA — folgt direkt den RFC- und BSI-Standards. Die Pflicht-Mindestversion laut RFC 8314 ist TLS 1.2 für Submission Servers. RFC 8996 markiert TLS 1.0 und 1.1 als veraltet, BSI TR-02102-2 in der Version 2026-01 spezifiziert die zulässigen Cipher-Suiten. RFC 8314 selbst empfiehlt Implicit TLS auf Port 465 gegenüber STARTTLS für Submission-Verbindungen.
Die Architektur ist immer gleich: Ein gültiges Zertifikat für den MX-Hostnamen, eine moderne TLS-Version (1.2 oder 1.3), eine BSI-konforme Cipher-Suite und ein automatisierter Erneuerungsprozess. Let's Encrypt mit ACME ist der Standardweg, weil Zertifikate kostenlos und vollautomatisch erneuert werden — ab 15. März 2026 sind das ohnehin Pflicht-Voraussetzungen wegen Ballot SC-081v3. Der Wolf-Agents Email Security Scanner prüft pro MX-Host die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2, das Zertifikats-Hostname-Match und die Chain-Vollständigkeit zeichengenau — unabhängig vom konkreten MTA. Das ist gerade bei kommerziellen Mailservern (Cisco IronPort, Proofpoint, Barracuda, Mimecast) wertvoll, wo Sie auf die Anbieter-Konfiguration angewiesen sind.
Für die Compliance-Triple (NIS2 Art. 21 Abs. 2 Buchstabe h zur Kryptografie, BSI TR-03108 zum sicheren E-Mail-Transport, DSGVO Art. 32 Abs. 1 Buchstabe a zur Verschlüsselung) gibt es vendor-neutral drei nachweisbare Anforderungen: Erstens TLS 1.2 oder höher mit Perfect Forward Secrecy aktiv; zweitens TLS-Logs pro Verbindung (TLS-Version plus Cipher plus Peer-CN) als TOM-Audit-Trail; drittens regelmäßige externe Scans als Eigenkontrolle. Bei kommerziellen MTAs (z.B. Cisco IronPort) erfolgt die Cipher-Konfiguration über die Admin-UI — die konkreten Schritte unterscheiden sich pro Vendor, die Anforderungen sind gleich.
TLS-Versionen gegen RFC 8314 und BSI prüfen
RFC 8314 schreibt für Mail Access Servers und Mail Submission Servers TLS 1.2 als Mindestversion fest. RFC 8996 deklariert TLS 1.0 und 1.1 als veraltet. BSI TR-03108 verlangt zusätzlich Perfect Forward Secrecy — was ECDHE-Cipher in der Suite-Liste voraussetzt. Bei einem RFC-konformen Mailserver sollte der openssl s_client-Test mindestens TLS 1.2 anzeigen, idealerweise TLS 1.3.
Vendor-spezifische TLS-Deaktivierungen sehen unterschiedlich aus: Bei Postfix in main.cf mit smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1, bei Exim mit OpenSSL-Backend über runtime-Optionen, bei Microsoft Exchange Server über die Windows Registry und SCHANNEL-Konfiguration. Lesen Sie die Vendor-Doku zu "disable old TLS versions" für Ihren konkreten MTA — der Kern bleibt: TLS 1.2 plus 1.3 aktiv, alles darunter aus.
# === Vendor-neutrale TLS-Baseline für SMTP-Server ===
# Quellen:
# - RFC 5321 (SMTP, https://datatracker.ietf.org/doc/html/rfc5321)
# - RFC 3207 (STARTTLS, https://datatracker.ietf.org/doc/html/rfc3207)
# - RFC 8314 (Cleartext Considered Obsolete, https://datatracker.ietf.org/doc/html/rfc8314)
# - RFC 8446 (TLS 1.3, https://datatracker.ietf.org/doc/html/rfc8446)
# - RFC 8996 (TLS 1.0 + 1.1 deprecation, https://datatracker.ietf.org/doc/html/rfc8996)
# - BSI TR-02102-2 Version 2026-01 (Cipher-Empfehlungen)
# - BSI TR-03108 (Sicherer E-Mail-Transport)
# TLS-Versionen
# PFLICHT-AKTIV: TLS 1.2 (mit ECDHE + AEAD), TLS 1.3
# PFLICHT-DEAKTIVIERT: SSLv2, SSLv3, TLS 1.0, TLS 1.1
# TLS-1.3-Cipher (laut BSI TR-02102-2 empfohlen)
# TLS_AES_128_GCM_SHA256
# TLS_AES_256_GCM_SHA384
# TLS_CHACHA20_POLY1305_SHA256
# TLS-1.2-Cipher (BSI-konform, nur ECDHE + AEAD)
# ECDHE-ECDSA-AES256-GCM-SHA384
# ECDHE-RSA-AES256-GCM-SHA384
# ECDHE-ECDSA-AES128-GCM-SHA256
# ECDHE-RSA-AES128-GCM-SHA256
# ECDHE-ECDSA-CHACHA20-POLY1305
# ECDHE-RSA-CHACHA20-POLY1305
# Zertifikat-Anforderungen
# - CN/SAN matcht den MX-Hostnamen exakt
# - Issuer: öffentlich vertrauenswürdige CA (Let's Encrypt, DigiCert, Sectigo, ZeroSSL)
# - Gültig: nicht abgelaufen, ab 15. März 2026 max. 200 Tage (CA/B SC-081v3)
# - Vollständige Kette: fullchain.pem mit Intermediate-CAsZertifikat für MX-Hostname ausstellen und Chain prüfen
Vier Anforderungen an das Mailserver-Zertifikat sind RFC- und Provider-übergreifend gleich: Erstens Gültigkeit (nicht abgelaufen, ab 15. März 2026 max. 200 Tage laut CA/Browser Forum Ballot SC-081v3); zweitens Hostname-Match (Subject/SAN entspricht exakt dem MX-Hostnamen); drittens öffentlich vertrauenswürdige CA (Let's Encrypt, DigiCert, Sectigo, ZeroSSL — keine selbst-signierten Zertifikate); viertens vollständige Chain (fullchain.pem mit Intermediate-CAs, nicht nur cert.pem).
Let's Encrypt ist der pragmatische Standard für die meisten Self-Hosted-Setups: kostenlos, ACME-automatisierbar, 90-Tage-Laufzeit. ECDSA-Schlüssel sind kompakter und schneller als RSA — bei certbot mit --key-type ecdsa aktivierbar. Für Setups mit DNS-Challenge (Port 80 nicht erreichbar) gibt es certbot-DNS-Plugins für die meisten DNS-Provider (Route53, Cloudflare DNS, OVH DNS etc.). Die Erneuerung läuft über systemd-timer oder Cron — ein Post-Renewal-Hook reload den Mailserver. Ab 15. März 2026 wird das wegen SC-081v3 ohnehin Pflicht: 200-Tage-Maximal-Laufzeit macht manuelle Erneuerung unpraktikabel.
Schritt-für-Schritt vendor-neutral
- certbot installieren:
apt install certbotoderdnf install certbot— Standard auf allen modernen Distros - Zertifikat ausstellen:
certbot certonly --standalone --key-type ecdsa -d mx1.example.com(Port 80 muss frei sein) - Mailserver konfigurieren: Pfad
/etc/letsencrypt/live/mx1.example.com/fullchain.pemals Server-Zertifikat einbinden — Vendor-spezifische Direktive siehe Provider-Doku - Post-Renewal-Hook: Skript in
/etc/letsencrypt/renewal-hooks/deploy/, das den Mailserver reload — nach Cert-Erneuerung führt certbot automatisch alle Skripte dort aus - Auto-Renewal verifizieren:
systemctl status certbot.timer+certbot renew --dry-run
Cipher-Suite nach BSI TR-02102-2 konfigurieren
BSI TR-02102-2 in der Version 2026-01 (veröffentlicht 27. Januar 2026) definiert die zulässigen Cipher-Suiten für TLS in deutschen Behörden und regulierten Unternehmen. Wichtige Änderungen ggü. älteren Versionen: PKCS#1 v1.5-Signaturen sind abgeschafft (nur RSA-PSS und ECDSA), DHE-basierte Cipher sind nur noch bis Ende 2029 empfohlen (danach ausschließlich ECDHE), TLS 1.2 läuft Ende 2031 aus (BSI-Empfehlung wird ab 2032 nicht erneuert).
Konkret zulässig sind drei TLS-1.3-Cipher (TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256) und ECDHE-basierte TLS-1.2-Cipher mit AEAD (AES-GCM oder ChaCha20-Poly1305). CBC-basierte Cipher-Suiten sollten vermieden werden — selbst mit Encrypt-then-MAC (RFC 7366) sind sie nur Übergangs-Optionen. Die konkrete Cipher-Konfiguration unterscheidet sich pro Vendor: Bei Postfix über tls_medium_cipherlist, bei Exim über tls_require_ciphers, bei Microsoft Exchange über die SCHANNEL-Registry. Wolf-Agents Scanner klassifiziert automatisch nach BSI-Empfehlung.
Verifikation per openssl s_client und testssl.sh
Vier Tools sind bei jedem RFC-konformen Mailserver einsetzbar: Erstens openssl s_client für den einzelnen TLS-Handshake-Test; zweitens testssl.sh für umfassenden Cipher- und Vulnerability-Audit; drittens internet.nl Mail Test (vom niederländischen Standardisierungsgremium) für DANE/MTA-STS-Check inklusive; viertens der Wolf-Agents Email Security Scanner für die Gesamtbewertung mit Provider-Erkennung und Compliance-Bezug.
openssl s_client zeigt Protocol, Cipher, Subject, Issuer und das gelieferte Zertifikat. Mit -showcerts wird die vollständige Chain ausgegeben — wichtig zur Verifikation, ob fullchain.pem korrekt eingebunden ist. testssl.sh läuft typischerweise 2-3 Minuten pro Host und produziert einen detaillierten Bericht mit Cipher-Liste, bekannten Schwachstellen (POODLE, BEAST, Heartbleed, Logjam, FREAK), Forward-Secrecy-Status und Zertifikatsdaten. Für regulierte Umgebungen ist die Kombination openssl-Schnelltest plus testssl-Tiefenaudit Standard.
# Verifikations-Kommandos (vendor-neutral)
# 1) MX-Records ermitteln
dig MX ihre-domain.de +short
# Erwartete Ausgabe: alle MX-Hosts mit Preferences
# 2) Pro MX-Host: STARTTLS auf Port 25 testen
echo | openssl s_client \
-connect mx1.example.com:25 \
-starttls smtp \
-servername mx1.example.com \
2>/dev/null | grep -E "Protocol|Cipher|subject|issuer|notBefore|notAfter"
# 3) Cipher-Audit mit testssl.sh
# Installation: git clone https://github.com/drwetter/testssl.sh
./testssl.sh --starttls smtp mx1.example.com:25 \
--severity LOW \
--color 0
# 4) Implicit TLS auf Port 465 (Submission, RFC 8314)
openssl s_client -connect mx1.example.com:465 -servername mx1.example.com
# 5) STARTTLS auf Port 587 (Submission mit Authentifizierung, RFC 6409)
openssl s_client -connect mx1.example.com:587 -starttls smtp -servername mx1.example.com
# 6) Online-Tools (vendor-neutral)
# - Wolf-Agents Email Security Check (5 SMTP-TLS Punkte plus Kontext)
# - testssl.sh (Open Source, Cipher- und Vulnerability-Audit)
# - Internet.nl Mail Test (Niederländer-Government, DANE/MTA-STS-Check inklusive)
# - Hardenize Email TestHäufige SMTP-TLS-Probleme (vendor-neutral)
Die folgenden drei Probleme treten bei nahezu jedem Mailserver auf, unabhängig vom Vendor — selbst-signiertes Zertifikat in Produktion, Hostname-Mismatch zwischen Zertifikat und MX-Eintrag, und unvollständige Zertifikatskette durch Verwendung von cert.pem statt fullchain.pem.
Selbst-signiertes Zertifikat in Produktion
Symptom: Strikte Validierer (MTA-STS enforce, DANE-konfigurierte Empfänger, Google-Compliance-Regeln) lehnen Mails ab. Wolf-Agents Scanner meldet "Self-signed certificate".
Ursache: Beim Installieren eines neuen Mailservers wird oft ein selbst-signiertes Zertifikat als Default angelegt. Das funktioniert technisch für STARTTLS — wird aber von strikten Validierern als gleichwertig zu Klartext behandelt (kein öffentlicher Trust Chain).
Lösung: Let's-Encrypt-Zertifikat ausstellen — siehe Schritt 2. Auch in Test-Setups produktiver Service-Subdomains ist Let's Encrypt der korrekte Weg. Selbst-signierte Zertifikate bleiben nur für komplett geschlossene interne Test-Netze vertretbar.
Hostname-Mismatch: Zertifikat passt nicht zum MX-Eintrag
Symptom: openssl s_client zeigt subject=CN = example.com, aber der MX-Record zeigt auf mail.example.com. Strikte Sender lehnen die Verbindung ab — "TLS hostname mismatch".
Ursache: Das Zertifikat wurde für die Hauptdomain ausgestellt, der MX zeigt aber auf eine Subdomain. Beide müssen übereinstimmen — entweder Zertifikat für die Subdomain ausstellen oder MX auf die Hauptdomain umstellen.
Lösung: Neues Zertifikat für den exakten MX-Hostnamen ausstellen: certbot certonly --standalone --key-type ecdsa -d mail.example.com. Mailserver-Konfiguration auf das neue Zertifikat umstellen (Pfade in fullchain.pem und privkey.pem aktualisieren). Reload erforderlich.
Unvollständige Zertifikatskette: cert.pem statt fullchain.pem
Symptom: Manche Mailserver können das Zertifikat nicht zur Trust-Root verifizieren — TLS-RPT-Reports zeigen sts-webpki-invalid. Wolf-Agents Scanner meldet "Chain unvollständig".
Ursache: Im Mailserver wurde cert.pem als Zertifikat-Pfad eingetragen — die Datei enthält nur das Server-Zertifikat, nicht die Intermediate-CAs. Sendende Server, die die CA-Trust-Chain nicht selbst kennen, können die Validierung nicht abschließen.
Lösung: Stattdessen fullchain.pem verwenden — Let's Encrypt liefert das automatisch in /etc/letsencrypt/live/[domain]/fullchain.pem. fullchain.pem enthält Server-Zertifikat plus alle Intermediate-CAs. Mit openssl s_client -showcerts kontrollieren: Es müssen mindestens 2 Zertifikate ausgeliefert werden.
NIS2, BSI TR-03108 und DSGVO Art. 32: Vendor-neutrale Compliance-Pfade
NIS2 Art. 21 Abs. 2 Buchstabe h fordert Kryptografie und Verschlüsselung als grundlegende Risikomanagement-Maßnahme — vendor-neutral erfüllt jeder Mailserver mit aktiviertem STARTTLS auf Port 25 und gültigem Zertifikat diese Anforderung. BSI TR-03108 verlangt sicheren E-Mail-Transport mit TLS plus Perfect Forward Secrecy — die ECDHE-AEAD-Cipher-Liste aus BSI TR-02102-2 (Version 2026-01) setzt das technisch um. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: Pro MTA gibt es vendor-spezifische Log-Mechanismen — bei Postfix smtpd_tls_loglevel, bei Exim log_selector +tls_cipher, bei Microsoft Exchange Message Trace, bei kommerziellen MTAs typischerweise eine Audit-Trail-Funktion in der Admin-UI. Halten Sie pro MTA mindestens 6 Monate Logs für DSGVO-Audits bereit. Die zentrale Anforderung ist vendor-neutral: TLS 1.2 oder höher mit PFS aktiv, gültiges Zertifikat für MX-Hostname, automatisierte Erneuerung. Für die Outbound-Erzwingung gegen STRIPTLS-Downgrade-Angriffe ergänzt MTA-STS die SMTP-TLS-Basis — vendor-neutrale Setup-Anleitung siehe MTA-STS providerunabhängig. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft pro MX-Host die TLS-Version, die Cipher nach BSI TR-02102-2, das Zertifikats-Hostname-Match und die Chain-Vollständigkeit zeichengenau — unabhängig vom verwendeten MTA.
SMTP-TLS-Anleitung auch für:
Wie steht Ihre Domain bei SMTP-TLS?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.