Ich zeige dir, wie du Mailserver TLS in Postfix sicher einstellst und starke Cipher-Suites auswählst, damit SMTP-Verbindungen konsequent geschützt laufen. Auf Basis erprobter Parameter für TLS 1.2/1.3, DANE, MTA-STS und moderner Schlüsselpaare führe ich dich Schritt für Schritt durch Konfiguration, Tests und Tuning, damit deine mail security sauber greift.
Zentrale Punkte
- Postfix sicher konfigurieren: TLS aktivieren, Protokolle einschränken, Logging setzen.
- Cipher priorisieren: ECDHE + GCM/CHACHA20, PFS erzwingen, Altlasten sperren.
- Zertifikate sauber halten: RSA+ECDSA, vollständige Chain, starke Kurven.
- DANE/MTA-STS nutzen: Richtlinien verankern und Downgrade-Risiken senken.
- Tests und Monitoring: OpenSSL, TLS-Scanner, MTA-Logs regelmäßig prüfen.
SMTP über TLS: was wirklich abgesichert wird
Ich sichere SMTP mit STARTTLS, damit E-Mail-Transport nicht im Klartext stattfindet. Opportunistisches TLS per smtpd_tls_security_level = may sorgt dafür, dass eingehende Verbindungen Verschlüsselung nutzen, sobald die Gegenstelle es anbietet. Für ausgehende Zustellungen setze ich mit smtp_tls_security_level = dane auf DNSSEC-gestützte Policy-Prüfungen, um Downgrade-Angriffe zu erschweren. Ohne TLS wären Mails auf dem Transportweg lesbar und manipulierbar, was besonders bei Formularen, Bestellungen oder Kontodaten gefährlich ist. Mit durchgängig aktivem TLS reduziere ich Abhör- und MITM-Risiken deutlich, und ich erreiche bessere Zustellquoten, weil große Anbieter sichere Verbindungen positiv bewerten.
Schlüssel, Zertifikate und Protokolle in Postfix
Ich halte zwei Zertifikate bereit: ein RSA-Zertifikat und ein ECDSA-Zertifikat, damit alte und neue MTAs optimal anknüpfen. Die Pfade in Postfix setze ich eindeutig, etwa smtpd_tls_cert_file für RSA und smtpd_tls_eccert_file für ECDSA, jeweils mit passendem Key. Für saubere Authentisierung achte ich auf die vollständige Chain, einen CN/SAN, der exakt zum Host passt, und eine Kurve wie secp384r1 für den ECDSA-Key. Ältere Protokolle deaktiviere ich strikt, also SSLv2 und SSLv3, um erzwungene Rückstufungen zu verhindern. Wenn du die Art des Zertifikats abwägst, hilft dir ein kurzer Blick auf DV, OV oder EV, damit du den passenden Vertrauensgrad wählst.
Cipher-Auswahl: Prioritäten für TLS 1.2/1.3
Ich priorisiere Cipher-Suites mit PFS, also ECDHE vor DHE, und setze auf GCM oder CHACHA20-POLY1305. Unter TLS 1.3 nimmt der Stack dir viele Altlasten ab, während TLS 1.2 weiterhin eine klare Liste braucht. Unsichere oder schwache Suiten wie RC4, 3DES, CAMELLIA, aNULL, eNULL streiche ich. Für Postfix nutze ich smtpd_tls_ciphers = high und eine restriktive tls_high_cipherlist, damit keine veralteten Algorithmen durchrutschen. Wenn du tiefer einsteigst, liefert dir der Cipher-Suites Leitfaden eine gut verständliche Einordnung ohne Ballast.
| TLS-Version | Bevorzugte Cipher-Suites | Status | Hinweis |
|---|---|---|---|
| TLS 1.3 | TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_GCM_SHA256 | aktiv | Auswahl fest im Protokoll, keine Altlasten mehr. |
| TLS 1.2 | ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-RSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305 | aktiv | PFS priorisieren, GCM/CHACHA bevorzugen. |
| Veraltet | RC4, 3DES, CAMELLIA, AES128-SHA, aNULL/eNULL | gesperrt | Aus Sicherheitsgründen vollständig deaktivieren. |
Postfix: konkrete Parameter für main.cf
Ich setze eine klare Konfiguration, damit der MTA sowohl eingehend als auch ausgehend sicher spricht. Für ephemeral ECDH lege ich mit smtpd_tls_eecdh_grade die Kurvenqualität fest und ich deaktiviere Kompression, um CRIME-ähnliche Angriffe zu vermeiden. Eine starke DH-Datei mit 4096 Bit verhindert schwache DHE-Aushandlungen. Protokolle schränke ich hart ein und erzwinge hohe Cipher-Qualität, wobei ich TLS 1.3 bevorzugt nutze. Zum Start hilft mir ein moderates Log-Level, um Handshakes zu prüfen, ohne das Journal zu fluten.
# Aktivierung und Policy
smtpd_tls_security_level = may
smtp_tls_security_level = dane
# Zertifikate (Beispielpfade)
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.de.cer
smtpd_tls_key_file = /etc/ssl/private/mail.example.de.key
smtpd_tls_eccert_file = /etc/ssl/certs/mail.example.de_ecc.cer
smtpd_tls_eckey_file = /etc/ssl/private/mail.example.de_ecc.key
# Protokolle und Cipher
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = high
tls_high_cipherlist = !aNULL:!eNULL:!RC4:!3DES:!CAMELLIA:HIGH:@STRENGTH
tls_ssl_options = NO_COMPRESSION
smtpd_tls_eecdh_grade = ultra
# DH-Parameter
smtpd_tls_dh1024_param_file = /etc/postfix/dh_4096.pem
# DNSSEC/DANE (sofern verfügbar)
smtp_dns_support_level = dnssec
# Logging
smtpd_tls_loglevel = 1
Ich halte die Zertifikatskette vollständig, achte auf korrekte Rechte für private Schlüsseldateien und prüfe nach dem Reload die Logs. Wenn TLS 1.2 für Altpartner nötig ist, bleibe ich streng bei GCM/CHACHA und sperre alles andere. Für TLS 1.3 setze ich auf die Standards des Stacks und vermeide Sonderpfade, die Wartung erschweren. OCSP-Stapling spielt bei SMTP nur dann eine Rolle, wenn ein vorgeschalteter Proxy es bereitstellt, daher prüfe ich das nur bei entsprechenden Setups. Nach jeder Änderung validiere ich mit OpenSSL, um Nebeneffekte früh zu erkennen und die email encryption konsistent zu halten.
Transport-Authentizität mit DANE, MTA-STS, SPF, DKIM und DMARC
Ich kombiniere TLS mit DANE, indem ich signierte TLSA-Records unter DNSSEC veröffentliche. Ergänzend setze ich MTA-STS, damit Gegenstellen wissen, dass mein Host TLS fordert und an welchen MX sie sich halten sollen. Für Identitätsbindung signiere ich ausgehende Mails mit DKIM und sichere die Domainzustellung per SPF-Regelwerk. DMARC legt schließlich fest, wie Empfänger mit Abweichungen umgehen sollen, was Spoofing stark erschwert. Diese Bausteine wirken zusammen: TLS schützt den Transport, während Authentisierung den Absender festigt und die Zustellquote spürbar hebt.
Wenn Performance ein Flaschenhals ist, optimiere ich Session-Resumption, Hardware-Features und den Handshake selbst. Ein Einstieg in praktische Kniffe gelingt dir mit TLS-Handshake schneller, damit die Latenz beim Verbindungsaufbau sinkt. Wichtig: Ich halte Cipher-Auswahl und Resumption im Gleichgewicht, denn schwache Kompromisse zahlen sich sicherheitlich nicht aus. Gerade bei hohem Mailaufkommen bringt eine zügige TLS-Aushandlung deutliche Einsparungen. So bleiben Durchsatz und Sicherheit im Lot.
Testen, Monitoring und Audits
Ich prüfe Handshakes lokal mit openssl und kontrolliere dabei Protokollversion, Cipher und Zertifikatskette. Der Befehl openssl s_client -connect mail.example.de:25 -starttls smtp zeigt mir live, was der Gegenserver aushandelt. Nach Konfigurationsänderungen nutze ich postfix check und schaue gezielt auf smtpd_tls_loglevel, um Fehlerbilder zu isolieren. Externe TLS-Scanner helfen bei einer Einordnung der öffentlichen Sichtbarkeit, besonders nach Zertifikatswechseln. Ein regelmäßiger Audit-Rhythmus schützt vor schleichenden Verschlechterungen, etwa wenn eine Library-Änderung Cipher-Prioritäten beeinflusst.
Häufige Fehlkonfigurationen und schnelle Fixes
Ich sehe oft veraltete Cipher wie AES128-SHA, die noch aktiv sind und PFS verhindern. Hier hilft ein strenger Cipher-String und die klare Sperre von LOW/MD5/RC4/3DES. Zweites Muster: fehlende Zwischenzertifikate, wodurch Gegenstellen die Chain nicht verifizieren können; ich ergänze die Bundle-Datei und teste erneut. Auf Appliances wie einer Synology setze ich das TLS-Profil auf modern und entferne Legacy-Optionen, damit SMTP-Server zeitgemäß sprechen. Bei Microsoft Exchange kontrolliere ich gezielt TLS 1.2/1.3-Policies, Zertifikatszuordnung pro Connector und eventuelle Cipher-Overrides in der Hostkonfiguration, damit die Handshake-Auswahl stimmt.
Vorausschau: TLS 1.3, 0-RTT und Post-Quantum
Ich bevorzuge TLS 1.3, weil der Handshake kürzer ist und alte Optionen entfallen, was Angriffsflächen reduziert. Die Auswahl der cipher ist dort klar begrenzt, und moderne Stacks liefern gute Defaults. 0-RTT nutze ich im SMTP-Kontext nicht, da Wiederholungsangriffe hier unnötige Risiken bringen. Für die Zukunft beobachte ich hybride Post-Quantum-Verfahren, die im Mailumfeld Einzug halten könnten, sobald Standardisierung und Support reifen. Wichtig bleibt, dass ich Policies und Monitoring so aufsetze, dass neue Verfahren später ohne Brüche integriert werden können.
Leistung und Zustellquote im Blick
Ich messe die Latenz des TLS-Handshakes und optimiere Caches, um Wiederverwendungen zu ermöglichen. Session-Resumption (Tickets/IDs) reduziert Rechenlast und beschleunigt wiederkehrende Verbindungen zwischen MTAs. Für Certificate Revocation setze ich auf stapelbare Informationen am vorgeschalteten Proxy, sofern vorhanden, um Zusatzzugriffe zu sparen. Große Empfänger bewerten sichere Transporte positiv, was die Zustellquote stärkt, während unsichere Pfade Spam- und Ablehnungsrisiken erhöhen. Mit klarer TLS-Policy, soliden DNS-Einträgen und sauberer Signaturkette lege ich eine verlässliche Basis für Deliverability.
Mein Setup-Fahrplan
Ich starte mit der Zertifikatsbeschaffung bei einer vertrauenswürdigen CA, generiere ECDSA und RSA und hinterlege beides sauber auf dem Host. Danach passe ich die main.cf mit den TLS-Parametern an, setze starke Cipher und deaktiviere alte Protokolle. Eine frische DH-Datei mit 4096 Bit kommt hinzu, gefolgt von Reload und ersten OpenSSL-Checks. Anschließend richte ich DANE ein, ergänze MTA-STS und verifiziere SPF/DKIM/DMARC auf Gültigkeit. Zum Schluss fahre ich Tests gegen externe Ziele, prüfe Logs im Betrieb und plane regelmäßige Audits ein, damit die Konfiguration langfristig sicher bleibt.
Fehlende Bausteine: Submission, SMTPS und SNI
Ich sichere nicht nur Port 25, sondern auch Submission (587) und optional SMTPS (465). Für Submission erzwinge ich Verschlüsselung und Authentisierung, damit Benutzerpasswörter nie im Klartext gehen. In master.cf aktiviere ich die Dienste und setze gezielte Overrides:
# Submission (Port 587) mit STARTTLS und Auth-Pflicht
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_auth_only=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
# SMTPS (Port 465) als Wrapper-Mode, falls benötigt
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o milter_macro_daemon_name=ORIGINATING
Wenn ich mehrere Mail-Domains auf einem Host mit eigenen Zertifikaten bediene, nutze ich SNI. Mit einer SNI-Map weise ich je Zielhost den passenden Zertifikatspfad zu und stelle sicher, dass auch MUA-Clients das korrekte Zertifikat sehen. So vereinbare ich Mandantentrennung mit konsistenter TLS-Identität.
Per-Domain-Policies: feingranular steuern
Neben der globalen Policy verwalte ich mit smtp_tls_policy_maps Ausnahmen und Verschärfungen pro Empfänger-Domain. Damit kann ich Legacy-Partner schrittweise migrieren oder besonders strenge Vorgaben für sensible Ziele durchsetzen.
# main.cf
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
# /etc/postfix/tls_policy (Beispieleinträge)
example.org dane-only
legacy.example.net may
secure.example.com secure
dane-only erzwingt DANE-Schutz ohne CA-Abhängigkeit, secure fordert eine gültige CA-Chain und verweigert Klartextzustellung, may bleibt opportunistisch. Nach Änderungen baue ich die Map mit postmap neu und lade Postfix neu.
DANE und MTA-STS: konkrete Umsetzung
Für DANE veröffentliche ich TLSA-Records unter DNSSEC. Ich nutze bevorzugt DANE-EE (3 1 1), weil es Pinnings auf den öffentlichen Schlüssel erlaubt und Zertifikatswechsel mit gleichem Key erleichtert. Ein exemplarischer TLSA-Record unter _25._tcp.mail.example.de sieht so aus:
_25._tcp.mail.example.de. IN TLSA 3 1 1 <sha256-spki-hash>
Den Hash erzeuge ich aus dem ECDSA- oder RSA-Zertifikat und achte darauf, ihn vor Ablauf zu rotieren. Wichtig ist, dass die DNS-Zone signiert ist und die Chain der Delegationen lückenlos validiert.
Für MTA-STS hoste ich die Policy-Datei über HTTPS und ergänze den TXT-DNS-Eintrag. So lege ich fest, dass Gegenstellen TLS sprechen und nur mit definierten MX akzeptiert werden. Eine minimalistische Policy-Datei:
version: STSv1
mode: enforce
mx: mail.example.de
max_age: 604800
Dazu kommt im DNS ein TXT-Eintrag unter _mta-sts.example.de mit der aktuellen Version. Optional richte ich TLS-RPT per TXT unter _smtp._tls.example.de ein, um Berichte über Policy-Verstöße zu erhalten. Diese Telemetrie hilft mir, Fehlschläge, Downgrades und fehlerhafte Zertifikate früh zu erkennen.
Protokolle verschärfen, Cipher präzisieren
Ich verschärfe Protokollgrenzen und setze Serverpräferenz durch. TLS 1.0/1.1 sind heute entbehrlich; ich erlaube eingehend und ausgehend nur noch TLS 1.2 und 1.3. Für TLS 1.2 definiere ich eine explizite Positivliste, um Mischbestände alter Cipher auszuschließen:
# Zusätzliche Härtung (main.cf)
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
# Explizite TLS 1.2-Cipherliste (nur PFS + AEAD)
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:!aNULL:!eNULL:!MD5:!RC4:!3DES:!CAMELLIA
# Serverpräferenz verwenden
tls_preempt_cipherlist = yes
Ich stelle sicher, dass ECDHE bevorzugt wird und DHE nur noch Fallback ist. Meine DH-Datei halte ich aktuell; unter TLS 1.3 spielt sie keine Rolle, aber für seltene DHE-Aushandlungen ist sie weiterhin nützlich.
Session-Resumption und Caches
Zur Beschleunigung aktiviere ich Session-Caches für Client und Server, um Wiederverbindungen günstiger zu machen. Gerade bei hohem Maildurchsatz sinken CPU-Last und Latenz spürbar:
# Session-Cache (main.cf)
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtp_tls_connection_reuse = yes
Ich beobachte die Trefferquote in den Logs und stelle sicher, dass keine zu kurzen ticket_lifetimes in der TLS-Library Resumption ausbremsen. Wichtig: Resumption darf die Policy nicht schwächen; ich bleibe bei gleichen Cipher-Anforderungen.
Zertifikatsbetrieb: Rotation und Chain-Pflege
Ich automatisiere die Verlängerung und den Reload des MTAs, damit keine abgelaufenen Zertifikate im Betrieb landen. Nach jeder Erneuerung prüfe ich, ob Leaf und Zwischenzertifikate vollständig im Bundle liegen. Für ECDSA/RSA-Dualbetrieb stelle ich sicher, dass beide Paare rotieren, bevor ein Massenwechsel bei Clients Probleme macht. Ich teste den SNI-Pfad und Submission separat, weil MUAs andere Fehlerbilder zeigen können als MTAs.
Logging und Diagnose vertiefen
Ich erhöhe temporär die Logtiefe, wenn ein Problem auftritt, und nutze Bordwerkzeuge für Gegenproben:
# gezieltes Logging (main.cf)
smtp_tls_loglevel = 1
smtp_tls_note_starttls_offer = yes
Mit posttls-finger ziel.example.com prüfe ich, welche Policy ein Remote-MTA erwartet und welche Cipher/Protokolle verhandelt werden. Ich nutze postconf -n | grep tls, um nur explizit gesetzte TLS-Parameter zu sehen; Abweichungen zu Defaults finde ich so schneller. In den Logs suche ich nach Begriffen wie no shared cipher, certificate verify failed oder protocol version, die direkt auf Cipher-Missmatch, Chain-Probleme oder zu strenge/zu lasche Protokollgrenzen hinweisen.
Kompatibilität steuern, ohne Sicherheit zu opfern
Ich plane Übergänge bewusst: Eingehend bleibe ich bei may, um Mails von Altservern nicht pauschal zu verlieren, protokolliere aber Klartext-Zustellungen. Ausgehend bleibe ich strikt (DANE/MTA-STS/secure) und nutze smtp_tls_policy_maps für Einzelfälle. Wenn vereinzelte Partner nur TLS 1.2 mit AES-GCM schaffen, ist das tragbar; alles darunter führe ich über abgestimmte Ausnahmen mit begrenzter Laufzeit, dokumentiere sie und nehme sie in die Migrationsplanung auf. So bleibt das Gesamtniveau hoch, ohne den Geschäftsbetrieb zu blockieren.
TLS-Defaults des Systems im Blick
Ich beachte, dass Postfix die TLS-Bibliothek des Systems nutzt. Updates an OpenSSL/LibreSSL können Cipher-Prioritäten und TLS-1.3-Verhalten ändern. Nach Systemupdates prüfe ich deshalb stichprobenartig Handshakes und vergleiche Output von postconf -n mit meinen Sollwerten. Ein gesetzter compatibility_level in Postfix hilft, stabile Defaults zu wahren, aber ich verlasse mich nicht blind darauf und dokumentiere explizite Abweichungen in der main.cf/master.cf.
Kurzbilanz für Admins
Ich halte fest: Starke Cipher mit PFS, saubere Zertifikate und klare Policies sind für SMTP entscheidend. TLS 1.3 nimmt dir Altlasten ab, während TLS 1.2 eine disziplinierte Cipher-Liste erfordert. DANE und MTA-STS härten den Transportweg, SPF/DKIM/DMARC sichern Identität und Reporting. Regelmäßige Tests und Log-Analysen zeigen früh, ob eine Änderung unerwünschte Nebenwirkungen bringt. Mit diesem Leitfaden stellst du deinen Mailserver sicher, performant und zukunftsfähig auf – ohne unnötige Risiken.
