SMTP-TLS für Postfix
Postfix ist der am weitesten verbreitete Open-Source-MTA. Die TLS-Konfiguration steuern Sie über main.cf — smtpd_tls_security_level=may für opportunistisches TLS auf Port 25, smtpd_tls_mandatory_ciphers=medium für BSI-konforme Cipher und Post-Renewal-Hook für unterbrechungsfreie Zertifikatserneuerung.
SMTP-TLS bei Postfix (Self-Hosted)
Postfix-TLS-Konfiguration ist explizit dokumentiert in postfix.org/TLS_README.html: smtpd_tls_security_level akzeptiert die Werte may (opportunistisch), encrypt (TLS-Pflicht) und none. Für Port 25 ist may zwingend — encrypt würde Mailserver ohne TLS abblocken, was sich für eingehenden Server-zu-Server-Mail nicht eignet. Seit Postfix 3.4 ist TLS 1.3 standardmäßig aktiv, ältere SSL/TLS-Versionen sind seit 2015 default deaktiviert.
Die TLS-Logging-Levels reichen laut Postfix-Doku von 0 (disabled) bis 4 (kompletter Hex-Dump). Für DSGVO-Nachweise und tägliches Monitoring ist smtpd_tls_loglevel = 1 ausreichend — es loggt eine Summary-Zeile pro Verbindung mit TLS-Version, Cipher und Peer-Common-Name in /var/log/mail.log. Der Wolf-Agents Email Security Scanner prüft pro Postfix-MX-Host die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2, den Common Name des Zertifikats gegen den MX-Hostnamen und die vollständige Chain zeichengenau — er warnt insbesondere vor häufigen Self-Hosted-Drifts: abgelaufene Let's-Encrypt-Zertifikate ohne Renewal-Hook, Hostname-Mismatch zwischen myhostname in main.cf und dem tatsächlichen MX-Eintrag, sowie unvollständige Zertifikats-Ketten durch versehentliche Nutzung von cert.pem statt fullchain.pem.
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) ist Postfix-Logging zentral: smtpd_tls_loglevel = 1 (eingehend) plus smtp_tls_loglevel = 1 (ausgehend) dokumentiert pro Mail die genutzte TLS-Version. Die Logs liegen in /var/log/mail.log (Debian/Ubuntu) oder /var/log/maillog (CentOS/RHEL). Für ausgehenden MTA-STS-Schutz benötigen Sie zusätzlich postfix-mta-sts-resolver — siehe MTA-STS für Postfix. Postfix 3.10 unterstützt seit Februar 2025 nativ TLSRPT (RFC 8460) für eingehende Verbindungen.
Let's-Encrypt-Zertifikat für den MX-Hostnamen ausstellen
Das Zertifikat MUSS für den MX-Hostnamen ausgestellt sein, nicht für die Hauptdomain. Bei MX-Record mx1.example.com brauchen Sie ein Zertifikat mit CN/SAN mx1.example.com. ECDSA-Schlüssel sind kompakter und schneller im Handshake — certbot erstellt sie mit dem Flag --key-type ecdsa.
Bei freiem Port 80 nutzen Sie den Standalone-Modus (certbot startet einen temporären Webserver). Falls Port 80 bereits von nginx/Apache belegt ist, verwenden Sie den Webroot-Modus. Wenn Port 80 von außen nicht erreichbar ist (typisch hinter einer restriktiven Firewall), nutzen Sie die DNS-Challenge — funktioniert mit jedem DNS-Provider, der API-Updates erlaubt.
# Let's-Encrypt-Zertifikat für den MX-Hostnamen ausstellen
sudo certbot certonly --standalone \
--key-type ecdsa \
-d mx1.example.com \
--email admin@example.com \
--agree-tos --non-interactive
# Alternative: DNS-Challenge (wenn Port 80 nicht erreichbar)
sudo certbot certonly --manual --preferred-challenges dns \
-d mx1.example.com
# Auto-Renewal prüfen
systemctl status certbot.timer
sudo certbot renew --dry-run
# Zertifikatsdetails anzeigen
sudo certbot certificatesPostfix-TLS-Konfiguration in main.cf hinterlegen
Die zentrale Postfix-Konfiguration für SMTP-TLS in /etc/postfix/main.cf. Wichtig: smtpd_tls_security_level=may (NICHT encrypt) für Port 25 — encrypt würde Mailserver ohne TLS abblocken. Mandatory-Ciphers=medium aktiviert die Postfix-interne Cipher-Klassifikation, die mit BSI TR-02102-2-Empfehlungen weitgehend übereinstimmt (ECDHE plus AEAD-Cipher).
Für TLS 1.3 ist seit Postfix 3.4 keine zusätzliche Konfiguration nötig — die Liste der TLS-1.3-Cipher steuert OpenSSL eigenständig. Für TLS 1.2 setzen Sie tls_medium_cipherlist auf die BSI-konformen ECDHE-AES-GCM-Suiten. Wer Postfix 3.10 mit OpenSSL 3.5 nutzt, hat Forward-Kompatibilität für hybride Post-Quantum-Cipher (X25519MLKEM768) — die Parameter tls_eecdh_auto_curves und tls_ffdhe_auto_groups können dafür leer bleiben (OpenSSL-Steuerung).
# === /etc/postfix/main.cf — SMTP-TLS-Konfiguration ===
# Quelle: postfix.org/TLS_README.html + postfix.org/postconf.5.html (Abruf 11. Mai 2026)
# --- Eingehend (smtpd, Port 25 + Port 587) ---
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.example.com/privkey.pem
# WICHTIG: 'may' für Port 25 — opportunistisches TLS
# 'encrypt' nur auf Port 587 verwenden (Submission)
smtpd_tls_security_level = may
# Alte Protokolle hart deaktivieren
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Cipher-Stärke "medium" laut Postfix-Doku — entspricht den BSI-TR-02102-2-Empfehlungen
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_ciphers = medium
# TLS-Logging für DSGVO-TOM-Nachweis und Debugging
smtpd_tls_loglevel = 1
# ECDH-Kurve für Forward Secrecy
smtpd_tls_eecdh_grade = auto
# Session-Cache
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_session_cache_timeout = 3600s
smtpd_tls_received_header = yes
# --- Ausgehend (smtp, Port 25 outbound) ---
smtp_tls_security_level = may
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_ciphers = medium
smtp_tls_loglevel = 1
# Optional: CA-Bundle für Zertifikats-Validierung
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
# --- TLS-1.3-Cipher (Postfix >= 3.4 default) ---
# Cipher-Liste für TLS 1.2 entspricht BSI TR-02102-2 (ECDHE + AEAD)
tls_medium_cipherlist = \
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:\
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
# --- Konfiguration anwenden ---
# postfix check # Syntax-Prüfung
# postfix reload # Reload ohne Downtimesmtpd_tls_security_level — wann was?
- none: Kein TLS — nur für interne Test-Setups, niemals produktiv
- may (empfohlen für Port 25): Server bietet STARTTLS an, aber akzeptiert auch Klartext-Verbindungen — Pflicht für die globale E-Mail-Erreichbarkeit auf Port 25
- encrypt (NUR für Port 587 Submission): Server lehnt Klartext-Verbindungen ab — sinnvoll auf Submission-Ports, gefährlich auf Port 25
- Outbound smtp_tls_security_level: Werte sind none, may, encrypt, dane, dane-only, fingerprint, verify, secure — laut postfix.org/TLS_README.html.
daneaktiviert DANE-Validierung beim Senden
Post-Renewal-Hook für certbot anlegen
Let's-Encrypt-Zertifikate laufen nach 90 Tagen ab. Certbot erneuert automatisch über systemd-Timer, aber Postfix lädt das neue Zertifikat erst nach systemctl reload postfix. Ohne Post-Renewal-Hook bedient Postfix nach der Erneuerung weiterhin das alte Zertifikat — bis ein manueller Reload erfolgt oder Postfix neu startet.
Lösung: Ein Skript in /etc/letsencrypt/renewal-hooks/deploy/, das nach erfolgreicher Cert-Erneuerung systemctl reload postfix aufruft. Certbot führt alle Skripte in diesem Verzeichnis nur nach erfolgreicher Erneuerung aus (nicht bei Dry-Run, nicht bei Fehlern) — kein Risiko unnötiger Postfix-Reloads. Das ist die Standard-Practice für Self-Hosted-Mailserver mit ACME-Automatisierung.
# Post-Renewal-Hook: Mailserver nach Cert-Erneuerung reloaden
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh <<'EOF'
#!/bin/bash
# certbot ruft alle Skripte in renewal-hooks/deploy/ NACH erfolgreicher
# Erneuerung auf — nur dann muss postfix reloaden.
systemctl reload postfix
EOF
chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-postfix.sh
# Test-Run (kein echter Reload — nur Dry-Run)
sudo certbot renew --dry-run
# Erwartete Ausgabe enthält: "Running deploy-hook command"
# Logs prüfen
journalctl -u certbot.timer --since "1 hour ago"TLS-Handshake und Cipher per openssl s_client verifizieren
Nach Konfigurations-Apply (postfix check + postfix reload) testen Sie den STARTTLS-Handshake auf Port 25 von einem externen Host. Wichtig: Der Test muss von außerhalb des Servers laufen — auf dem Mailserver selbst funktioniert der Self-Connect anders als ein echter MTA-to-MTA-Aufbau. testssl.sh ist das umfangreichste Tool für Cipher- und Vulnerability-Audits.
Bei Auffälligkeiten zeigt der Wolf-Agents Email Security Scanner pro MX-Host die TLS-Version, die Cipher-Familie, das Zertifikat plus Chain — alle gegen BSI TR-02102-2 und SC-081v3 (Zertifikatslaufzeit) geprüft. Bei abgelaufenen Zertifikaten oder schwachen Cipher meldet der Scanner sofort. Für tägliche Compliance-Nachweise (DSGVO Art. 32): grep "TLS connection established" /var/log/mail.log liefert pro Verbindung TLS-Version und Cipher — das ist auditierbarer Output für DSGVO-Berichte.
# STARTTLS auf Port 25 testen — von außerhalb des Servers!
echo | openssl s_client \
-connect mx1.example.com:25 \
-starttls smtp \
-servername mx1.example.com \
2>/dev/null | grep -E "Protocol|Cipher|subject|issuer"
# Erwartete Ausgabe nach korrekter Konfiguration:
# Protocol : TLSv1.3 (oder TLSv1.2 — Postfix verhandelt höchste verfügbare)
# Cipher : TLS_AES_256_GCM_SHA384 (TLS 1.3) oder ECDHE-ECDSA-AES256-GCM-SHA384 (TLS 1.2)
# subject=CN = mx1.example.com
# issuer=C = US, O = Let's Encrypt, CN = R11 (oder ähnlich)
# Postfix-TLS-Konfiguration anzeigen
postconf | grep -E "tls_security_level|tls_protocols|tls_mandatory_ciphers"
# TLS-Logs prüfen (smtpd_tls_loglevel=1 muss gesetzt sein)
grep "TLS connection established" /var/log/mail.log | tail -20
# Erweitert: testssl.sh für Cipher-Audit
./testssl.sh --starttls smtp mx1.example.com:25Hinweis für ausgehenden MTA-STS-Schutz
- Postfix als Sender: Bei smtp_tls_security_level=may stellt Postfix opportunistisch verschlüsselt zu — kein Schutz vor STRIPTLS
- MTA-STS-Validierung beim Senden: Benötigt
postfix-mta-sts-resolver— siehe MTA-STS für Postfix - DANE-Validierung:
smtp_tls_security_level = daneaktiviert DANE — siehe Kapitel 09 DNS-Sicherheit - Postfix 3.10 TLSRPT-Reporting: Nativer Support für RFC 8460 — eingehende TLS-Fehler werden automatisch als Reports versendet
Häufige SMTP-TLS-Probleme bei Postfix
Die folgenden drei Postfix-spezifischen Probleme treten in Self-Hosted-Setups regelmäßig auf — smtpd_tls_security_level versehentlich auf encrypt für Port 25 gesetzt, Hostname-Mismatch zwischen myhostname und MX-Eintrag, sowie unvollständige Zertifikats-Kette durch Nutzung von cert.pem statt fullchain.pem.
smtpd_tls_security_level = encrypt auf Port 25 — externe Mailserver werden abgewiesen
Symptom: Nach Setzen von smtpd_tls_security_level = encrypt in main.cf können viele externe Mailserver Ihre Domain nicht mehr erreichen — Bounce-Logs zeigen "454 4.7.0 TLS not available due to local problem".
Ursache: encrypt erzwingt TLS für ALLE eingehenden Verbindungen, auch auf Port 25. Mailserver, die nur opportunistisches TLS sprechen (oder Klartext), werden abgewiesen — ihre Mails landen in der Queue oder fallen ganz aus. Die Postfix-Doku warnt explizit: encrypt eignet sich nur für Submission-Ports.
Lösung: Auf Port 25 zwingend smtpd_tls_security_level = may verwenden. Für Port 587 Submission können Sie encrypt setzen — dort sind alle modernen Clients TLS-fähig. Die Erzwingung von TLS gegenüber sendenden Servern erfolgt über MTA-STS, nicht über die Postfix-Konfiguration auf Port 25.
Hostname-Mismatch: myhostname unterscheidet sich vom MX-Eintrag
Symptom: MTA-STS-validierende Sender lehnen Zustellungen ab — Wolf-Agents Scanner zeigt "certificate-host-mismatch". Der MX-Record zeigt auf mx1.example.com, das Postfix-myhostname ist aber auf server.example.com gesetzt.
Ursache: Postfix verwendet myhostname für den eigenen Hostnamen im EHLO und für das Common-Name-Matching gegen das Zertifikat. Wenn myhostname und MX-Hostname auseinandergehen, scheitert die Validierung bei strikten Sendern (MTA-STS enforce, DANE).
Lösung: myhostname auf den MX-Hostnamen setzen: myhostname = mx1.example.com. Das Zertifikat muss CN/SAN mx1.example.com haben. Nach postfix reload mit openssl s_client verifizieren — das gelieferte Zertifikat muss dem MX-Hostnamen entsprechen.
Unvollständige Zertifikatskette: cert.pem statt fullchain.pem
Symptom: TLS-RPT-Reports zeigen sts-webpki-invalid oder strikte Sender brechen den Handshake mit "certificate verify failed" ab. Wolf-Agents Scanner meldet "Chain unvollständig — Intermediate fehlt".
Ursache: In main.cf ist smtpd_tls_cert_file = .../cert.pem gesetzt — cert.pem enthält nur das Server-Zertifikat, nicht die Intermediate-CAs. Sendende Server können die Chain nicht zur Trust-Root verifizieren.
Lösung: smtpd_tls_cert_file = .../fullchain.pem verwenden — fullchain.pem enthält Server-Zertifikat plus Intermediates. Nach postfix reload per openssl s_client -showcerts die Chain prüfen — es müssen mindestens 2 Zertifikate ausgeliefert werden (Server + 1+ Intermediate-CAs).
NIS2, BSI TR-03108 und DSGVO Art. 32: Postfix mit Logs als TOM-Nachweis
NIS2 Art. 21 Abs. 2 Buchstabe h fordert Kryptografie und Verschlüsselung — Postfix mit korrektem smtpd_tls_security_level=may auf Port 25 und encrypt auf Port 587 erfüllt das technisch. BSI TR-03108 verlangt sicheren E-Mail-Transport mit TLS plus Perfect Forward Secrecy — die Postfix-Mandatory-Ciphers=medium-Konfiguration mit ECDHE-Cipher-Liste setzt das nach BSI TR-02102-2 (Version 2026-01) korrekt um. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: smtpd_tls_loglevel = 1 und smtp_tls_loglevel = 1 dokumentieren TLS-Version und Cipher pro Verbindung in /var/log/mail.log. Bei Audits liefern Sie die Log-Auszüge als TOM-Nachweis. In Kombination mit postfix-mta-sts-resolver (für ausgehende MTA-STS-Validierung) und postfix-policyd-spf (für SPF-Enforcement) bauen Sie eine vollständige Server-zu-Server-E-Mail-Sicherheit. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft pro Postfix-MX-Host die TLS-Version, die Cipher nach BSI TR-02102-2, das Zertifikats-Hostname-Match und die Chain-Vollständigkeit zeichengenau.
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.