SMTP-TLS & Zertifikate: Verschlüsselte E-Mail-Zustellung einrichten
STARTTLS auf Port 25, gültige Zertifikate und moderne TLS-Versionen sichern die Vertraulichkeit Ihrer E-Mail-Kommunikation. Ohne SMTP-TLS werden E-Mails im Klartext übertragen — jeder Netzwerkknoten zwischen Absender und Empfänger kann mitlesen.
Warum SMTP-TLS unverzichtbar ist: Vom Klartext-Protokoll zur Verschlüsselungspflicht
SMTP wurde 1982 als Klartext-Protokoll entworfen — jeder Netzwerkknoten zwischen Absender und Empfänger konnte mitlesen. STARTTLS (RFC 3207, 2002) brachte opportunistische Verschlüsselung, blieb aber angreifbar durch STRIPTLS-Downgrade. RFC 8314 (2018) erklärt Klartext-Submission als veraltet. Heute ist SMTP-TLS Compliance-Pflicht: BSI TR-03108, NIS2 Art. 21 Abs. 2 Buchstabe h und DSGVO Art. 32 verlangen Verschlüsselung der Kommunikation.
Geheimdienste und staatliche Akteure betreiben nachweislich großflächige Überwachung des E-Mail-Verkehrs an Internet-Austauschknoten. Nach den Snowden-Enthüllungen 2013 haben Google, Microsoft und andere die Verschlüsselung des E-Mail-Transports massiv ausgebaut — von rund 30 % TLS-Anteil 2013 auf über 96 % bei Gmail heute. Der Wolf-Agents Email Security Check bewertet SMTP-TLS mit 5 von 165 Punkten (3 Punkte für ein gültiges Zertifikat plus 2 Punkte für aktiven STARTTLS-Support auf Port 25) und ergänzt damit die 15 MTA-STS- und 20 DANE-Punkte zu einem geschlossenen Bild der Transport-Sicherheit.
STRIPTLS-Angriff — Ohne und mit MTA-STS/DANE-Schutz
Multimodales Zwei-Spalten-Bedrohungsbild: Links erfolgreicher STRIPTLS-Angriff ohne MTA-STS/DANE (rotes Schloss-gebrochen-Symbol — MitM entfernt 250-STARTTLS, Sender fällt auf Klartext zurück). Rechts wirksamer Schutz mit MTA-STS oder DANE (grünes Schloss-geschlossen-Symbol — Sender pinnt TLS-Pflicht über Policy/TLSA und verweigert Klartext-Zustellung). Brücken-Verweise zu Kapitel 06 (MTA-STS) und Kapitel 09 (DANE).
Managed vs Self-Hosted SMTP-TLS — Responsibility-Matrix mit 6 Aufgaben
Multimodale Responsibility-Matrix mit 2 Spalten (Managed Cloud links / Self-Hosted Postfix/Exim/Mailcow rechts) und 6 Zeilen (Mailserver-Software / TLS-Version / Cert-Verwaltung / Cipher-Liste / TLS-Logs / Compliance-Nachweis). Wolf-Agents Scanner unten als externer unabhängiger Prüfer beider Modelle. Beispiele: Microsoft 365 + Google Workspace links, eigener Postfix-Server rechts.
Die drei SMTP-Ports: 25, 587 und 465 — jeder hat seinen Verschlüsselungsmodus
SMTP nutzt drei Ports mit unterschiedlichen Verschlüsselungskonzepten. Port 25 (RFC 5321) trägt Server-zu-Server-Mail mit opportunistischem STARTTLS — das ist der Port, den Wolf-Agents prüft. Port 587 (RFC 6409) ist der authentifizierte Submission-Port für Mail-Clients; RFC 8314 mandatiert dort STARTTLS. Port 465 ist nach RFC 8314 für Implicit TLS rehabilitiert — die Verbindung beginnt sofort verschlüsselt, kein STRIPTLS möglich.
MTA-to-MTA (Server-zu-Server)
Der Standardport für die Zustellung zwischen Mailservern. STARTTLS wird angeboten, aber nicht erzwungen — anfällig für STRIPTLS-Downgrade. Schutz nur über MTA-STS oder DANE.
Submission (Client-zu-Server)
Authentifiziertes Einreichen durch Mail-Clients wie Outlook, Thunderbird, Apple Mail. RFC 8314 schreibt vor: Mail Submission Servers MUST support TLS 1.2 or later. Klartext-Submission ist veraltet.
Implicit TLS (Comeback)
Verbindung beginnt sofort mit TLS-Handshake — kein Klartext, kein STARTTLS-Upgrade. Inhärent STRIPTLS-resistent. RFC 8314 empfiehlt Implicit TLS gegenüber STARTTLS auf Submission-Ebene.
SMTP-Ports-Vergleichs-Architektur — Port 25 vs Port 587 vs Port 465
Multimodales Drei-Lanes-Architektur-Diagramm: Lane 1 Port 25 (Server-zu-Server RFC 5321, STARTTLS opportunistisch, Klartext-Phase), Lane 2 Port 587 (Client-zu-MTA Submission RFC 6409, STARTTLS Pflicht), Lane 3 Port 465 (Implicit TLS von Anfang an RFC 8314 § 3 rehabilitiert). Farb-Code: Port 25 gelb, 587 grün, 465 dunkelgrün.
STARTTLS-Handshake-Sequenz auf Port 25 — Klartext-Phase vs TLS-Phase
Multimodales UML-Sequence-Diagramm: 2 Lifelines (Client Sender-MTA + Server Empfänger-MX) mit 9 nummerierten Schritten. Klartext-Phase rot/orange markiert (Schritte 1-6: TCP, Server-Banner, EHLO, 250-STARTTLS-Liste, STARTTLS-Befehl, Ready). TLS-Phase grün markiert (Schritte 7-9: Handshake, EHLO erneut, MAIL FROM/RCPT TO/DATA). Annotation 'STRIPTLS-Risiko zwischen 4 und 5'.
STARTTLS-Handshake auf Port 25 im Detail
Client Server
| |
| 1. TCP-Verbindung auf Port 25 |
| --------------------------------------------->|
| |
| 2. Server-Banner (Klartext!) |
| <--------------------------------------------|
| 220 mx.example.com ESMTP Postfix |
| |
| 3. EHLO sender.example.org |
| --------------------------------------------->|
| |
| 4. Server-Fähigkeiten (inkl. STARTTLS) |
| <--------------------------------------------|
| 250-mx.example.com |
| 250-STARTTLS |
| 250 SIZE 52428800 |
| |
| 5. STARTTLS |
| --------------------------------------------->|
| |
| 6. 220 Ready to start TLS |
| <--------------------------------------------|
| |
| 7. TLS-Handshake (Version, Cipher, Cert) |
| <============================================>|
| |
| 8. EHLO erneut (jetzt verschlüsselt) |
| ============================================>|
| |
| 9. MAIL FROM / RCPT TO / DATA (verschlüsselt) |
| ============================================>|
Zwischen Schritt 1 und 6 ist die Verbindung unverschlüsselt. Ein aktiver Netzwerkangreifer kann die 250-STARTTLS-Zeile entfernen — der sendende Server fällt auf Klartext zurück. Genau dagegen schützen MTA-STS und DANE.
TLS-Versionen und Cipher Suites: Was BSI TR-02102-2 für Mailserver fordert
BSI TR-02102-2 in der Version 2026-01 (veröffentlicht Januar 2026) definiert die kryptografischen Mindestanforderungen für TLS im E-Mail-Transport. Pflicht ist TLS 1.2 mit Perfect Forward Secrecy, empfohlen wird TLS 1.3 als primäres Protokoll. SSLv2, SSLv3, TLS 1.0 und TLS 1.1 sind deaktiviert. PKCS#1-v1.5-Signaturen sind abgeschafft — nur noch RSA-PSS und ECDSA sind zulässig. DHE-basierte Cipher Suites laufen Ende 2029 aus.
| Version | Status | Sicherheit | Empfehlung |
|---|---|---|---|
| TLS 1.3 | RFC 8446, 2018 | Ausgezeichnet — nur AEAD-Cipher, PFS Pflicht, verschlüsselter Handshake | Primäres Protokoll |
| TLS 1.2 | RFC 5246, 2008 | Gut, wenn korrekt konfiguriert (ECDHE + AEAD) | Mindestversion (RFC 8314) |
| TLS 1.1 | Veraltet, RFC 8996 (2021) | Ungenügend — CBC-Mode-Schwachstellen | Deaktivieren |
| TLS 1.0 | Veraltet, RFC 8996 (2021) | Ungenügend — BEAST, POODLE-Varianten | Deaktivieren |
| SSLv3 / SSLv2 | Veraltet (POODLE) | Kritisch | Muss deaktiviert sein |
Empfohlene TLS-1.3-Cipher Suites laut BSI TR-02102-2
TLS_AES_128_GCM_SHA256— AES-128 im GCM-ModusTLS_AES_256_GCM_SHA384— AES-256 im GCM-ModusTLS_CHACHA20_POLY1305_SHA256— ChaCha20 + Poly1305
Für TLS 1.2 empfiehlt das BSI ausschließlich ECDHE mit AEAD-Cipher (AES-GCM oder ChaCha20-Poly1305). CBC-basierte Cipher sind nur noch mit Encrypt-then-MAC (RFC 7366) zulässig — in der Praxis sollten sie vermieden werden. Cloudflare berichtet im Cloudflare Radar (Dezember 2025), dass bereits rund 52 % des menschlichen Web-Traffics hybride Post-Quantum-Kryptografie (X25519MLKEM768) nutzen — Postfix 3.10 mit OpenSSL 3.5 ist dafür vorbereitet.
Zertifikatsanforderungen: Vier Kriterien für SMTP-TLS
Ein TLS-Zertifikat auf Ihrem Mailserver muss vier Bedingungen erfüllen, damit MTA-STS, DANE und strikte Sender die Verbindung akzeptieren: Gültigkeit (nicht abgelaufen), Hostname-Match (Subject/SAN entspricht dem MX-Hostnamen), eine öffentlich vertrauenswürdige CA (Let's Encrypt, DigiCert, Sectigo — keine selbst-signierten Zertifikate) und die vollständige Zertifikatskette inklusive Intermediate-CAs.
Gültigkeit
Das Zertifikat darf nicht abgelaufen sein. Strikte Sender (MTA-STS enforce, DANE) lehnen abgelaufene Zertifikate ab. SC-081v3: Ab 15. März 2026 maximal 200 Tage Laufzeit, ab 15. März 2027 maximal 100 Tage, ab 15. März 2029 maximal 47 Tage.
Hostname-Match (Subject/SAN)
Subject Alternative Name (SAN) oder Common Name (CN) muss exakt mit dem MX-Hostnamen übereinstimmen. Wildcard *.example.com deckt mx1.example.com ab, aber nicht mx1.mail.example.com (verschachtelt).
Vertrauenswürdige CA
Öffentlich vertrauenswürdige Certificate Authority — Let's Encrypt (kostenlos, ACME), DigiCert, Sectigo, ZeroSSL. Selbst-signierte Zertifikate werden von Google, Microsoft und MTA-STS-validierenden Servern abgelehnt.
Vollständige Kette
Server-Zertifikat plus alle Intermediate-CAs müssen ausgeliefert werden. Verwenden Sie fullchain.pem statt cert.pem — eine unvollständige Kette führt zu Validierungsfehlern bei sendenden Servern.
Zertifikatskette mit Intermediate-CAs — fullchain.pem als Trust-Path
Multimodales vertikales Trust-Path-Diagramm: Boden Server-Zertifikat (CN mx1.example.com + SAN), Mitte Intermediate-CA (Lets Encrypt R11), Spitze Root-CA (ISRG Root X1 — Self-Signed im Client-Trust-Store). Signiert-mit-Pfeile von unten nach oben. Rote X-Markierung Intermediate-Box: Wenn fehlt = Validierung schlägt fehl. RFC 5280 § 6 Cert Path Validation.
4 Zertifikats-Kriterien — Gültigkeit + Hostname + CA + Chain als Compliance-Modell
Multimodales 2x2-Compliance-Modell mit zentralem Wolf-Agents-Scanner-Hub und Pfeilen zu allen vier Kriterien. Top-Left Gültigkeit (Kalender-Icon, NotAfter, max 200 Tage SC-081v3), Top-Right Hostname-Match (Tag-Icon, SAN/CN), Bottom-Left Vertrauenswürdige CA (Schild-Icon, Issuer in CA-Bundle), Bottom-Right Vollständige Chain (Verknüpfung-Icon, fullchain.pem). Alle vier Pflicht.
# STARTTLS auf Port 25 testen (Server-zu-Server)
echo | openssl s_client -connect mx.example.com:25 -starttls smtp 2>/dev/null \
| grep -E "Protocol|Cipher|subject|issuer"
# Erwartete Ausgabe:
# Protocol : TLSv1.3
# Cipher : TLS_AES_256_GCM_SHA384
# subject=CN = mx.example.com
# issuer=C = US, O = Let's Encrypt, CN = R11
# Zertifikatsgültigkeit prüfen
echo | openssl s_client -connect mx.example.com:25 -starttls smtp 2>/dev/null \
| openssl x509 -noout -dates -subject
# Implicit TLS auf Port 465
openssl s_client -connect mx.example.com:465 -servername mx.example.com
# STARTTLS auf Submission Port 587
openssl s_client -connect mx.example.com:587 -starttls smtp -servername mx.example.comLet's Encrypt für Mailserver: ECDSA, certbot und Post-Renewal-Hook
Let's Encrypt stellt kostenlose, automatisch erneuerte TLS-Zertifikate aus — auch für Mailserver. Standard-Laufzeit 90 Tage, mit certbot voll automatisierbar. Wichtig: Das Zertifikat wird für den MX-Hostnamen ausgestellt (mx1.example.com), nicht für die Hauptdomain. Ein Post-Renewal-Hook lädt das neue Zertifikat ohne Downtime in Postfix oder Exim. ECDSA-Zertifikate (--key-type ecdsa) sind kompakter und schneller im Handshake als RSA.
# 1. Zertifikat für den MX-Hostnamen ausstellen
sudo certbot certonly --standalone \
--key-type ecdsa \
-d mx1.example.com \
--email admin@example.com \
--agree-tos
# 2. Post-Renewal-Hook anlegen (Mailserver-Reload nach Erneuerung)
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh <<'EOF'
#!/bin/bash
systemctl reload postfix
EOF
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
# 3. Automatische Erneuerung prüfen
systemctl status certbot.timer
sudo certbot renew --dry-runLets Encrypt Renewal-Lifecycle — 90-Tage-Cycle mit Post-Renewal-Hook
Multimodales zirkuläres Flow-Diagramm mit 5 Knoten: certbot.timer (täglich) → ACME-Server-Check (Restlaufzeit) → ACME-Renewal-Request (HTTP-01/DNS-01/TLS-ALPN-01) → Neues Cert (fullchain.pem + privkey.pem) → Post-Renewal-Hook (systemctl reload postfix/exim). Standard 90-Tage-Cycle, Renewal alle 60 Tage. Warnung: Ohne Hook bedient Mailserver ALTES Cert bis manuellem Reload.
Let's Encrypt 2026: Kurzlaufzeiten kommen schrittweise
- 15. Januar 2026: 6-Tage-Zertifikate als Opt-in über das ACME-Profil
shortlivedverfügbar — minimieren das Zeitfenster bei kompromittierten Schlüsseln und benötigen kein OCSP. - Mai 2026: 45-Tage-Zertifikate über das Opt-in-Profil
tlsservernach offiziellem Let's-Encrypt-Stufenplan. - 10. Februar 2027: Default-Profil wechselt auf 64 Tage.
- 16. Februar 2028: Default-Profil wechselt auf 45 Tage.
CA/Browser Forum SC-081v3: Zertifikatslaufzeiten ab 15. März 2026 schrumpfen
Das CA/Browser Forum hat am 11. April 2025 mit Ballot SC-081v3 einen verbindlichen Stufenplan zur Verkürzung der Zertifikatslaufzeiten beschlossen. Ab 15. März 2026 dürfen öffentlich vertrauenswürdige TLS-Zertifikate nur noch maximal 200 Tage gültig sein, ab 15. März 2027 maximal 100 Tage, ab 15. März 2029 maximal 47 Tage. Manuelle Zertifikatsverwaltung wird operativ unmöglich — ACME-Automatisierung wird Pflicht. Parallel verkürzt SC-085v2 die Wiederverwendung der Domain Control Validation (DCV).
Heute
Max. Laufzeit: 398 Tage · DCV-Wiederverwendung: 398 Tage Status quo bis 14. März 2026. Jahreszertifikate sind zulässig, manuelle Verwaltung möglich.
15. März 2026 — SC-081v3 Stufe 1
Max. Laufzeit: 200 Tage · DCV-Wiederverwendung: 200 Tage (SC-085v2) Erneuerung ca. alle 6 Monate statt jährlich. DigiCert hat SC-081v3 vorzeitig umgesetzt und stellt seit 24. Februar 2026 nur noch Zertifikate mit maximal 199 Tagen aus.
15. März 2027 — Stufe 2
Max. Laufzeit: 100 Tage · DCV-Wiederverwendung: 100 Tage Erneuerung ca. alle 3 Monate. Manuelle Verwaltung über mehrere Mailserver wird operativ unbeherrschbar.
CA/B Forum SC-081v3 Roadmap — 200 → 100 → 47 Tage Cert-Lifetime
Multimodale horizontale Timeline mit vier Meilensteinen und Farbverlauf von grün (heute, lang) über gelb/orange zu rot (2029, kurz). Pro Meilenstein Datum-Label + proportional schrumpfender Laufzeit-Balken (398d/200d/100d/47d). Annotation: Manuelle Verwaltung wird ab 2027 operativ unmöglich — ACME-Automatisierung Pflicht. Parallel: SC-085v2 verkürzt DCV-Wiederverwendung.
15. März 2029 — Stufe 3 (Endzustand)
Max. Laufzeit: 47 Tage · DCV-Wiederverwendung: 10 Tage ACME-Automatisierung wird Pflicht. Let's Encrypt mit 90-Tage-Zyklus ist bereits darauf vorbereitet, Certbot 4.0 unterstützt seit April 2025 Kurzlaufzeiten nativ.
Postfix vs. Exim: TLS-Direktiven im Komplementär-Vergleich
Wer einen eigenen Mailserver betreibt, wählt typischerweise zwischen Postfix (≥3.10) und Exim (≥4.99). Beide setzen TLS auf den gleichen RFC-Standards um, aber die Direktiven-Namen und das Verhalten unterscheiden sich substanziell. Die folgende Tabelle mappt die gleichen Aufgaben (Zertifikats-Anbindung, Cipher-Liste, MTA-STS-Client, DANE, Logging) auf die jeweiligen Konfigurations-Optionen — verifiziert gegen postfix.org/TLS_README.html und exim.org-Spec (Abruf 12. Mai 2026).
| Aspekt | Postfix (≥3.10) | Exim (≥4.99) |
|---|---|---|
| Inbound-TLS anbieten | smtpd_tls_security_level = may | tls_advertise_hosts = * (Default) |
| Outbound-TLS-Modus | smtp_tls_security_levelWerte: none / may / encrypt / dane / dane-only / fingerprint / verify / secure | Transport-spezifisch: hosts_try_tls / hosts_require_tls |
| Zertifikat-Pfad | smtpd_tls_cert_file (oder smtpd_tls_chain_files seit 3.4) | tls_certificate |
| Privater-Schlüssel-Pfad | smtpd_tls_key_file | tls_privatekey |
| Cipher-Liste | smtpd_tls_mandatory_ciphers = medium plus tls_medium_cipherlist für TLS 1.2 | tls_require_ciphers (OpenSSL-Format) |
| MTA-STS-Client | Nativ über smtp_tls_policy_maps plus postfix-mta-sts-resolver | Kein Client-Support (Exim-Spec: „Exim has no support for MTA-STS as a client“) |
| DANE-Client | smtp_tls_security_level = dane oder dane-onlyVoraussetzung: smtp_dns_support_level = dnssec | hosts_try_dane / hosts_require_daneVoraussetzung: Compile-Time SUPPORT_DANE = yes |
| TLS-RPT (RFC 8460) | Nativ seit Postfix 3.10 (Februar 2025) | Kein nativer Support — externe Tools nötig |
Postfix vs Exim TLS-Direktiven-Mapping — Gleiche Aufgabe andere SyntaxMultimodaler Zwei-Spalten-Stack-Vergleich: Postfix (>= 3.10) links + Exim (>= 4.99) rechts, beide mit 5 identischen Schichten (Zertifikat-Anbindung / Inbound Anbieten / Cipher-Liste / MTA-STS-Client / Logging) und unterschiedlichen Direktiven. Pfeil-Annotationen 'gleiche Aufgabe, andere Direktive'. KRITISCH: MTA-STS-Client-Unterstützung — Postfix ja (Snawoot), Exim nicht nativ. | ||
| TLS-Logging | smtpd_tls_loglevel = 1 und smtp_tls_loglevel = 1 (Stufen 0–4) | log_selector = +tls_cipher +tls_peerdn +tls_certificate_verified |
Quellen: postfix.org/TLS_README.html, postfix.org/announcements/postfix-3.10.0.html, exim.org TLS-Spec — alle Abruf 12. Mai 2026. Detaillierte Setup-Anleitungen pro MTA: SMTP-TLS für Postfix und SMTP-TLS für Exim.
TLS-RPT-Brücke: SMTP-TLS-Fehler als JSON-Reports erkennen
TLS-Verbindungsfehler werden über TLS-RPT (RFC 8460) als JSON-Reports an die Domain-Inhaber gemeldet. RFC 8460 § 4.3.1 (Negotiation Failures) definiert die fünf SMTP-TLS-relevanten Result Types starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted und validation-failure. § 4.3.3 (General Failures) empfiehlt validation-failure zusätzlich als Catch-all für unspezifische TLS-Fehler. Policy-spezifische Fehler (DANE, MTA-STS) gehören zu § 4.3.2 und damit in die jeweiligen Kapitel. Sie erkennen damit, wenn sendende Server Ihre Domain wegen TLS-Problemen nicht erreichen — bevor E-Mails verloren gehen.
| Fehlertyp (Result Type) | Bedeutung laut RFC 8460 § 4.3 | Typische Ursache |
|---|---|---|
starttls-not-supported | Empfangender MX bietet kein STARTTLS an | SMTP-Server ohne TLS-Konfiguration, falscher MX-Host oder Firewall blockiert Port 25 |
certificate-expired | Zertifikat ist abgelaufen | Fehlender Post-Renewal-Hook, Cert-Renewal-Job gestoppt, Monitoring fehlt |
certificate-host-mismatch | Zertifikat-CN/SAN passt nicht zum MX-Hostnamen | Zertifikat für Hauptdomain statt MX-Subdomain ausgestellt, falscher myhostname |
certificate-not-trusted | Zertifikat-Chain konnte nicht zu vertrauenswürdiger CA validiert werden | Selbst-signiertes Zertifikat, fehlendes Intermediate (cert.pem statt fullchain.pem) |
validation-failure | Allgemeiner TLS-Handshake-Fehler ohne spezifischere Kategorie | Cipher-Mismatch, Protokoll-Mismatch (z.B. TLS 1.0 erzwungen), MitM-Manipulation |
TLS-RPT-Setup (DNS-Record _smtp._tls, JSON-Aggregations-Reports, mailto/https-Endpoints) ist im Detail im Kapitel MTA-STS & TLS-RPT beschrieben — die fünf hier gelisteten Fehlertypen kommen unverändert dort in den Reports an. Policy-spezifische DANE-/MTA-STS-Fehler (RFC 8460 § 4.3.2: tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid) gehören thematisch zu Kapitel 06 bzw. zum Kapitel 09 DNS-Sicherheit (DNSSEC + DANE + CAA).
TLS-RPT-Fehler-Klassifikation aus SMTP-TLS-Sicht — RFC 8460 § 4.3
Multimodale Mind-Map mit Root TLS-RPT Result Types (RFC 8460 § 4.3) und vier Hauptzweigen: Negotiation Failures § 4.3.1 (SMTP-TLS-relevant — 4 Cert-Result-Types), Policy Failures DANE § 4.3.2 (gehört zu Kapitel 09), Policy Failures MTA-STS § 4.3.2 (gehört zu Kapitel 06), General Failures § 4.3.3 (SMTP-TLS-relevant). Annotation: SMTP-TLS-relevant sind Negotiation + General — Policy-Failures gehören zu MTA-STS bzw DANE.
Komplement: RFC 8689 — TLS-Required: No Header
RFC 8689 (Februar 2020) definiert den Header TLS-Required: No als Gegenstück zur strikten Empfänger-Policy: Absender markieren einzelne Nachrichten, für die TLS NICHT erzwungen werden soll — etwa bei legitimen Empfängern mit bekanntem Zertifikatsproblem oder bei Bounce-Reports an strikte DMARC-Reporting-Endpunkte. Postfix unterstützt den Header seit Version 3.10 (Februar 2025) nativ. Exim hat keinen RFC-8689-Support dokumentiert. Microsoft 365 und Google Workspace berücksichtigen den Header in ihren Mail-Flow-Engines nicht offiziell — Forced-TLS-Connectors (Microsoft) bzw. Secure-Transport-Compliance-Regeln (Google) bleiben dominant.
Quelle: RFC 8689 — SMTP Require TLS Option (Abruf 12. Mai 2026) und Postfix 3.10.0 Release Notes mit explizitem Header-Support.
SMTP-TLS als Compliance-Nachweis: NIS2, BSI TR-03108 und DSGVO Art. 32
SMTP-TLS mit gültigem Zertifikat und moderner TLS-Version ist die Grundlage für die Compliance-Triple aus NIS2, BSI TR-03108 und DSGVO Art. 32. NIS2 Art. 21 Abs. 2 Buchstabe h nennt Kryptografie und Verschlüsselung explizit. BSI TR-03108 fordert sicheren E-Mail-Transport mit TLS. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme zum Schutz personenbezogener Daten bei der Übertragung.
NIS2 Art. 21 Abs. 2 lit. h
NIS2 verlangt explizit den Einsatz von Kryptografie und Verschlüsselung als grundlegende Risikomanagement-Maßnahme. SMTP-TLS mit aktiviertem STARTTLS auf Port 25 und gültigem Zertifikat erfüllt diese Anforderung für die ausgehende und eingehende E-Mail-Kommunikation Ihrer Organisation.
BSI TR-03108
Die BSI Technische Richtlinie für sicheren E-Mail-Transport fordert TLS-Verschlüsselung des SMTP-Verkehrs mit mindestens TLS 1.2 und Perfect Forward Secrecy. In Kombination mit BSI TR-02102-2 (Version 2026-01) ergibt sich der konkrete Cipher-Katalog: ECDHE-basiert, AEAD, keine CBC-Cipher mehr.
DSGVO Art. 32 Abs. 1 lit. a
Verschlüsselung wird als technische Maßnahme zum Schutz personenbezogener Daten explizit genannt. Ein Mailserver ohne TLS überträgt personenbezogene Daten unverschlüsselt — ein klarer Verstoß gegen Art. 32. SMTP-TLS mit Log-Verifikation (Postfix smtpd_tls_loglevel = 1) dokumentiert TLS-Version und Cipher pro Zustellung als TOM-Nachweis.
SMTP-TLS adressiert konkrete Bedrohungen: Email-Spoofing über STARTTLS-Stripping (EFF: STARTTLS-Downgrade-Angriffe in den USA und Thailand belegt). Ohne durchgesetztes TLS kann ein Netzwerk-Angreifer den STARTTLS-Banner entfernen oder die Antwort manipulieren und damit die Klartext-Übertragung erzwingen. Vertiefung im Bedrohungs-Cluster.
NIS2 Art. 23 Meldepflichten: Ein erfolgreich durchgeführter STARTTLS-Stripping-Angriff mit Klartext-Mitlesen sensibler E-Mail-Inhalte kann als „erheblicher Sicherheitsvorfall“ qualifizieren — es greifen die 24-Stunden-Frühwarnung an die zuständige nationale CSIRT-Stelle, die 72-Stunden-Vorfallsmeldung mit Erstbewertung und der Abschlussbericht innerhalb eines Monats. SMTP-TLS-Logs (Postfix smtpd_tls_loglevel, Exim log_selector +tls_cipher) und TLS-RPT-Reports liefern die forensische Datenbasis für die Meldung.
Der Wolf-Agents Email Security Check prüft alle 165 Kriterien zeichengenau — inklusive der 5 SMTP-TLS-Punkte (Zertifikat 3, STARTTLS 2), 15 MTA-STS-Punkte und 20 DANE-Punkte. Das Monitoring überwacht Zertifikats-Ablauf, TLS-Version und Cipher-Suiten alle 6 Stunden und alarmiert 30 Tage vor Cert-Expiry.
Wie steht Ihre Domain bei SMTP-TLS?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.
Häufig gestellte Fragen
Was ist STARTTLS und warum reicht es ohne MTA-STS nicht aus?
STARTTLS (RFC 3207) ist ein Upgrade-Mechanismus, der eine bestehende Klartext-SMTP-Verbindung auf TLS hochstuft. Ein Angreifer im Netzwerkpfad kann das STARTTLS-Angebot aus der Server-Antwort entfernen — der sendende Server fällt dann auf Klartext zurück (STRIPTLS-Angriff). MTA-STS (Kapitel 06) und DANE (Kapitel 09) verhindern genau diesen Downgrade, indem sie TLS-Verschlüsselung per DNS-Policy bzw. DNSSEC-gestütztem TLSA-Record verbindlich machen.
TLS 1.2 oder TLS 1.3 — welche Version sollte mein Mailserver unterstützen?
Beide. BSI TR-02102-2 (Version 2026-01) fordert mindestens TLS 1.2 mit Perfect Forward Secrecy und empfiehlt TLS 1.3 als primäres Protokoll. RFC 8314 schreibt für Mail Submission Servers ebenfalls TLS 1.2 als Mindestversion fest. SSLv2, SSLv3, TLS 1.0 und TLS 1.1 müssen deaktiviert werden. Postfix und Exim deaktivieren SSLv2/SSLv3 seit 2015 standardmäßig — die alten TLS-Versionen müssen Sie explizit ausschließen.
Wie lange dürfen TLS-Zertifikate noch gültig sein?
Ab dem 15. März 2026 maximal 200 Tage (CA/Browser Forum Ballot SC-081v3, beschlossen am 11. April 2025). Der Stufenplan: 100 Tage ab 15. März 2027 und 47 Tage ab 15. März 2029. Parallel verkürzt SC-085v2 die Wiederverwendung der Domain Control Validation (DCV) ebenfalls schrittweise. Manuelle Zertifikatsverwaltung wird operativ unmöglich — ACME-Automatisierung mit Let's Encrypt oder einer kommerziellen CA wird Pflicht.
Sind selbst-signierte Zertifikate auf Produktions-Mailservern zulässig?
Technisch funktioniert STARTTLS auch mit selbst-signierten Zertifikaten, aber strikte Validierer lehnen sie ab. MTA-STS im Enforce-Modus, DANE und große Provider wie Google validieren das Zertifikat gegen vertrauenswürdige CAs. Setzen Sie auf öffentlich erreichbaren Mailservern ein Let's-Encrypt-Zertifikat ein — kostenlos, automatisierbar und von allen großen Mailservern akzeptiert. Selbst-signierte Zertifikate sind nur in geschlossenen Test-Umgebungen vertretbar.
Ist Let's Encrypt für Produktions-Mailserver sicher?
Ja. Let's Encrypt-Zertifikate sind von allen großen Mail-Providern (Google, Microsoft, IONOS, Strato) anerkannt und werden von certbot automatisch alle 90 Tage erneuert. Mit dem Post-Renewal-Hook (--deploy-hook "systemctl reload postfix") wird das neue Zertifikat ohne Downtime in den Mailserver geladen. Wichtig: Das Zertifikat muss für den MX-Hostnamen ausgestellt sein, nicht für die Hauptdomain — andernfalls scheitert die Hostname-Validierung bei MTA-STS oder DANE.
Was passiert, wenn mein TLS-Zertifikat abläuft?
Bei opportunistischem STARTTLS akzeptieren die meisten sendenden Server abgelaufene Zertifikate noch — sie fallen entweder auf Klartext zurück oder ignorieren die Validierung. Sobald Sie MTA-STS im Enforce-Modus oder DANE aktiviert haben, lehnen sendende Server die Zustellung ab — E-Mails bleiben in der Warteschlange. TLS-RPT-Reports zeigen den Fehlertyp <code>certificate-expired</code>. Richten Sie deshalb 30 Tage vor Ablauf eine Monitoring-Warnung ein.
Wie teste ich SMTP-TLS auf meinem Mailserver?
Drei Wege: Erstens openssl s_client -connect mx.example.com:25 -starttls smtp für STARTTLS auf Port 25, zweitens testssl.sh --starttls smtp mx.example.com:25 für einen umfassenden Cipher- und Vulnerability-Report, drittens der Wolf-Agents Email Security Scanner, der STARTTLS-Support, TLS-Version, Zertifikatsgültigkeit, Hostname-Match und Chain-Vollständigkeit zeichengenau pro MX-Host prüft.