SMTP-TLS für Exim

Exim ist nach Postfix der zweitverbreitetste Open-Source-MTA. STARTTLS wird laut offizieller Exim-Doku per Default für alle Hosts angeboten (tls_advertise_hosts=*), das Zertifikat über tls_certificate/tls_privatekey eingebunden. DANE wird als Client unterstützt, MTA-STS laut Exim-Spec ausdrücklich NICHT.

SMTP-TLS prüfen Plattform entdecken

Exim · SMTP-TLS-Anleitung

Von Wolf-Agents Security Team · Aktualisiert: 12. Mai 2026

SMTP-TLS bei Exim (Self-Hosted)

Die Exim-TLS-Spezifikation (exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html) dokumentiert das Setup explizit: tls_advertise_hosts hat Default-Wert "*" — STARTTLS wird automatisch jedem verbindenden Host angeboten. Zertifikat und privater Schlüssel werden per tls_certificate und tls_privatekey eingebunden, beide als PEM-Pfade. Cipher-Auswahl bei OpenSSL-Backend: tls_require_ciphers im OpenSSL-Listen-Format.

Bei Exim ist eine wichtige fachliche Klarstellung relevant: Die offizielle Exim-Spec schreibt explizit "Exim has no support for MTA-STS as a client". Das heißt: Exim als Sender prüft KEINE MTA-STS-Policies der Empfängerdomain — ein MTA-STS-Enforce-Setup beim Empfänger schützt nicht, wenn Exim sendet. Wer Exim als Sender betreibt und MTA-STS-Schutz beim Senden braucht, hat zwei Optionen: Erstens Exim hinter einen Postfix-Smarthost mit postfix-mta-sts-resolver stellen (Postfix übernimmt dann die MTA-STS-Validierung); zweitens DANE als Client aktivieren — DANE wird in der Exim-Spec als unterstützt geführt (compile-time SUPPORT_DANE=yes). Der Wolf-Agents Email Security Scanner prüft pro Exim-MX-Host die TLS-Version, die Cipher-Stärke nach BSI TR-02102-2, das Common-Name-Match gegen den MX-Hostnamen und die Chain-Vollständigkeit zeichengenau — er warnt besonders vor klassischen Exim-Drifts: zu restriktive tls_require_ciphers (legitime moderne Cipher werden abgelehnt), Hostname-Mismatch (SAN gegen MX) und unvollständige Chain durch versehentliche Nutzung von cert.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 Exim-Logging zentral: Mit log_selector = +tls_cipher +tls_peerdn +tls_certificate_verified in der Konfiguration dokumentiert Exim pro Verbindung die TLS-Version, den Cipher und ob das Peer-Zertifikat verifiziert wurde — die Logs liegen in /var/log/exim4/mainlog (Debian/Ubuntu) bzw. /var/log/exim/mainlog (RHEL/CentOS). Bei Audits liefern Sie die Logs als TOM-Nachweis. Exim 4.99 (Release 28. Oktober 2025) und der Security-Release 4.99.1 (Dezember 2025) schließen zwei sicherheitsrelevante Lücken: CVE-2025-26794 ist eine SQL-Injection in der SQLite-Hints-Implementierung mit ETRN-Serialisierung (Exim 4.98 vor 4.98.1, CVSS 9.8 critical); für bestimmte Rate-Limit-Konfigurationen ist erst Exim 4.99.1 vollständig gefixt. CVE-2025-30232 ist eine Use-after-free-Schwachstelle bei lokalem Command-Line-Zugriff mit Privilege-Escalation-Potenzial (Exim 4.96 bis 4.98.1, CVSS 7.8–8.1 high). Update auf Exim ≥ 4.99.1 dringend empfohlen.

Ausführliche SMTP-TLS-Einführung

1 Schritt 1 von 4

Let's-Encrypt-Zertifikat für den MX-Hostnamen ausstellen

Wie bei Postfix muss das Zertifikat 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 werden auch von Exim mit OpenSSL korrekt verarbeitet — der Handshake ist schneller als mit RSA.

# 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

# Auto-Renewal prüfen
systemctl status certbot.timer
sudo certbot renew --dry-run

# Zertifikatsdetails anzeigen
sudo certbot certificates

2 Schritt 2 von 4

Exim-TLS-Konfiguration in exim.conf hinterlegen

Exim-Konfiguration wird zentral in /etc/exim4/exim4.conf.template (Debian/Ubuntu, mit dpkg-reconfigure update-exim4.conf) oder /etc/exim/exim.conf (RHEL/CentOS) gepflegt. tls_advertise_hosts hat laut Spec-Doku Default-Wert "*" — STARTTLS wird also bereits angeboten, ohne dass Sie etwas konfigurieren. Pflicht sind tls_certificate und tls_privatekey, sinnvoll sind tls_require_ciphers für BSI-Konformität.

Die Cipher-Liste folgt dem OpenSSL-Format — Beispielwert aus der Exim-Spec: HIGH:!MD5:!SHA1 (sehr generisch). Für BSI TR-02102-2-Konformität setzen Sie explizit ECDHE-AES-GCM-Suiten plus ChaCha20-Poly1305. Beachten Sie: tls_require_ciphers gilt für beide Richtungen (smtpd und smtp), während Postfix separate Variablen hat. Die log_selector-Erweiterung mit +tls_cipher +tls_peerdn +tls_certificate_verified ist Pflicht für DSGVO-TOM-Nachweise.

# === /etc/exim4/exim4.conf.template (Debian/Ubuntu) ===
# Quelle: exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html
# (Abruf 11. Mai 2026)

# --- Zertifikat und Privater Schlüssel ---
tls_certificate = /etc/letsencrypt/live/mx1.example.com/fullchain.pem
tls_privatekey  = /etc/letsencrypt/live/mx1.example.com/privkey.pem

# --- STARTTLS für alle Hosts anbieten ---
# Default ist laut Exim-Doku bereits "*" — explizit setzen für Klarheit
tls_advertise_hosts = *

# --- Cipher-Liste nach BSI TR-02102-2 (Version 2026-01) ---
# Format: OpenSSL-Cipher-Liste (Exim mit OpenSSL-Backend)
# Quelle Cipher-Auswahl: BSI TR-02102-2 — ECDHE plus AEAD-Cipher
tls_require_ciphers = 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

# --- log_selector erweitern: TLS-Details pro Verbindung loggen ---
# Pflicht für DSGVO-TOM-Nachweis
log_selector = +tls_cipher +tls_peerdn +tls_certificate_verified

# --- Outbound-Transport (für Senden) ---
# In der Transport-Section "remote_smtp" sind diese Optionen üblich:
# remote_smtp:
#   driver = smtp
#   hosts_try_tls = *           # opportunistic TLS
#   tls_verify_certificates = /etc/ssl/certs/ca-certificates.crt
#   # tls_dane_require_tls für DANE-Validierung aktivieren
#   # (DANE wird laut Exim-Spec als Client unterstützt; MTA-STS NICHT)

# --- Konfiguration anwenden ---
# exim -bV   # Build- und Versionsanzeige
# exim -C /etc/exim4/exim4.conf.template -C   # Syntax-Test (Konfig validieren)
# systemctl restart exim4

Wichtige Exim-TLS-Optionen aus der Spec

tls_advertise_hosts: Default ist * — STARTTLS wird allen Hosts angeboten. Negative Werte (z.B. !192.168.0.0/16) schließen interne Hosts aus
tls_certificate / tls_privatekey: PEM-Pfad — beide Pflicht für TLS-Server-Modus
tls_require_ciphers: OpenSSL-Format. Spec-Beispiel: HIGH:!MD5:!SHA1. Für BSI TR-02102-2: explizite ECDHE-AES-GCM-Liste
DANE als Client: Aktivierung über compile-time SUPPORT_DANE=yes — in den meisten Distros bereits gesetzt. Runtime über hosts_try_dane und tls_dane_require_tls in der Transport-Section
MTA-STS als Client: Laut Spec NICHT unterstützt — Workaround: Exim hinter Postfix-Smarthost mit postfix-mta-sts-resolver, siehe MTA-STS für Postfix

3 Schritt 3 von 4

Post-Renewal-Hook für certbot anlegen

Exim lädt das TLS-Zertifikat beim Start in den Speicher — ein einfaches reload wie bei Postfix reicht nicht. Nach Zertifikatserneuerung muss systemctl restart exim4 ausgeführt werden, damit das neue Zertifikat geladen wird. Der Post-Renewal-Hook automatisiert das.

Der Restart ist sehr schnell (typisch unter einer Sekunde), eingehende Verbindungen während des Restarts werden vom OS-Kernel kurzzeitig gequeuet — keine sichtbaren Auswirkungen für sendende MTAs. Alternative für Zero-Downtime-Setups: Mehrere Exim-Instanzen hinter einem Load-Balancer und rollender Restart. Für kleine bis mittlere Mailserver ist der einfache systemctl restart völlig ausreichend.

# Post-Renewal-Hook: Exim nach Cert-Erneuerung neu starten
# Hinweis: Exim braucht restart (nicht reload), weil tls_certificate beim Start geladen wird
cat > /etc/letsencrypt/renewal-hooks/deploy/reload-exim.sh <<'EOF'
#!/bin/bash
systemctl restart exim4
EOF

chmod +x /etc/letsencrypt/renewal-hooks/deploy/reload-exim.sh

# Test
sudo certbot renew --dry-run
# Erwartete Ausgabe enthält: "Running deploy-hook command"

# Logs prüfen
journalctl -u certbot.timer --since "1 hour ago"

4 Schritt 4 von 4

TLS-Handshake und Logs verifizieren

Nach Konfigurations-Reload (systemctl restart exim4) testen Sie den STARTTLS-Handshake von außerhalb des Servers. Exim loggt mit aktivierter log_selector-Erweiterung pro Verbindung die TLS-Version und den Cipher in /var/log/exim4/mainlog (Debian/Ubuntu) — das ist Ihr DSGVO-Art.-32-Audit-Trail.

Das Log-Format bei +tls_cipher zeigt das X= mit TLS-Version und Cipher-Familie (z.B. X=TLS1.3:ECDHE_RSA__AES_256_GCM:256), +tls_peerdn fügt den Distinguished Name des Peer-Zertifikats hinzu, +tls_certificate_verified zeigt mit CV=yes/no, ob die Validierung gegen die CA-Trust-Chain erfolgreich war. Für die meisten Audit-Berichte reichen diese drei Felder — bei Auffälligkeiten erweitern Sie mit +tls_sni für SNI-Logging und +tls_resumption für Session-Resumption-Tracking.

# 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:
# Protocol  : TLSv1.3
# Cipher    : TLS_AES_256_GCM_SHA384
# subject=CN = mx1.example.com
# issuer=C = US, O = Let's Encrypt, CN = R11

# Exim-TLS-Konfiguration im Speicher anzeigen
exim -bP tls_certificate tls_privatekey tls_require_ciphers tls_advertise_hosts

# TLS-Logs prüfen (log_selector +tls_cipher muss gesetzt sein)
grep -E "X=TLS|TLS=" /var/log/exim4/mainlog | tail -20

# Erwartetes Log-Format:
# 2026-05-11 10:23:45 1uXXXX-000123-AB <= sender@external.com
#   H=external-mx.com [203.0.113.7] X=TLS1.3:ECDHE_RSA__AES_256_GCM:256
#   CV=yes DN="CN=external-mx.com"

# Erweitert: testssl.sh für Cipher-Audit
./testssl.sh --starttls smtp mx1.example.com:25

Häufige SMTP-TLS-Probleme bei Exim

Die folgenden drei Exim-spezifischen Probleme treten in Self-Hosted-Setups regelmäßig auf — tls_require_ciphers zu restriktiv setzt legitime Cipher außer Kraft, fehlende DANE-Aktivierung im Outbound-Transport, und MTA-STS-Erwartungslücke (Exim unterstützt MTA-STS als Client nicht).

tls_require_ciphers zu restriktiv — moderne Sender werden abgewiesen

Symptom: Manche externe Mailserver scheitern beim TLS-Handshake — exim-mainlog zeigt "TLS error on connection (cipher mismatch)" oder "no shared cipher". Andere Sender funktionieren problemlos.

Ursache: Ein zu enges tls_require_ciphers — typisch nach einer manuellen Härtung mit ausschließlich TLS-1.3-Suites oder einer kuriosen CBC-/AEAD-Mischung. Exim verhandelt nur Cipher, die auf der Liste stehen — wenn der Sender keine davon kann, scheitert der Handshake.

Lösung: Die BSI-TR-02102-2-konforme Liste enthält bewusst sowohl TLS-1.2-ECDHE-AES-GCM als auch TLS-1.3-AEAD-Suiten — siehe Schritt 2. Wer eine eigene Liste pflegt, sollte sie regelmäßig (mind. einmal pro Jahr) gegen BSI TR-02102-2 prüfen — das BSI aktualisiert die Empfehlungen im Januar jährlich.

DANE-Validierung als Client nicht aktiviert — Outbound ungeschützt vor STRIPTLS

Symptom: Wolf-Agents Scanner berichtet "DANE-Outbound-Validierung nicht aktiv". Bei Empfängern mit aktivem DANE-Schutz prüft Ihr Exim das TLSA-Record beim Senden nicht — STRIPTLS-Schutz nur opportunistisch.

Ursache: In der remote_smtp-Transport-Section fehlt hosts_try_dane oder tls_dane_require_tls. Exim sendet dann opportunistisch ohne DANE-Validierung.

Lösung: In der Transport-Section setzen: hosts_try_dane = * und hosts_require_dane = * für Domains mit aktivem DANE. SUPPORT_DANE muss compile-time gesetzt sein (in Debian/Ubuntu Default). Validierung: exim -bV zeigt unterstützte Features, dann log-mainlog auf DANE-Einträge prüfen. Da MTA-STS in Exim als Client nicht verfügbar ist, ist DANE der einzige native Schutz gegen STRIPTLS-Outbound.

MTA-STS-Erwartungslücke: Exim erfüllt MTA-STS-Compliance als Sender NICHT

Symptom: Ein Compliance-Audit verlangt MTA-STS-Outbound-Validierung. Ihr Exim-Setup besteht den Audit nicht — Wolf-Agents bestätigt: Exim sendet ohne MTA-STS-Validierung.

Ursache: Die offizielle Exim-Spec dokumentiert explizit: "Exim has no support for MTA-STS as a client". Das ist Architektur-Entscheidung, kein Bug — und wird voraussichtlich auch in zukünftigen Versionen nicht implementiert.

Lösung: Zwei Workarounds, beide praxiserprobt: Erstens — Exim hinter einen Postfix-Smarthost mit installiertem postfix-mta-sts-resolver stellen. Postfix übernimmt die MTA-STS-Validierung beim Senden, Exim liefert nur an den lokalen Smarthost. Zweitens — DANE als gleichwertige Outbound-Sicherung aktivieren (siehe oben). BSI TR-03108 empfiehlt ohnehin die Kombination aus MTA-STS und DANE; mit DANE allein erfüllen Sie die Verschlüsselungs-Pflicht für Domains mit DNSSEC.

NIS2, BSI TR-03108 und DSGVO Art. 32: Exim mit Logs und DANE-Client

NIS2 Art. 21 Abs. 2 Buchstabe h fordert Kryptografie und Verschlüsselung — Exim mit tls_advertise_hosts=* und tls_certificate erfüllt das technisch. BSI TR-03108 verlangt sicheren E-Mail-Transport mit TLS plus Perfect Forward Secrecy — die Cipher-Liste mit ECDHE-AEAD-Suiten nach BSI TR-02102-2 setzt das korrekt um. DSGVO Art. 32 Abs. 1 Buchstabe a nennt Verschlüsselung als technische Maßnahme: log_selector = +tls_cipher +tls_peerdn +tls_certificate_verified dokumentiert pro Verbindung den Verschlüsselungsstatus in /var/log/exim4/mainlog. Bei Audits liefern Sie die Log-Auszüge als TOM-Nachweis. Wichtig: Exim unterstützt laut Spec MTA-STS als Client NICHT — als Outbound-Schutz vor STRIPTLS aktivieren Sie deshalb DANE im Outbound-Transport oder routen über einen Postfix-Smarthost mit postfix-mta-sts-resolver. Inbound-MTA-STS-Policy-Hosting (eingehende Erzwingung) ist für Exim hingegen voll geeignet — Setup-Anleitung siehe MTA-STS für Exim. Sicherheits-Hinweis: CVE-2025-26794 (SQL-Injection in SQLite-Hints + ETRN-Serialisierung, betrifft 4.98 vor 4.98.1, in 4.99.1 vollständig adressiert) und CVE-2025-30232 (Use-after-free mit Privilege-Escalation, betrifft 4.96–4.98.1) — Update auf Exim 4.99.1 dringend empfohlen. Der Wolf-Agents Email Security Scanner bewertet SMTP-TLS mit 5 von 165 Punkten und prüft pro Exim-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:

Microsoft 365 Google Workspace IONOS Strato All-Inkl Hetzner Postfix Generisch

Wie steht Ihre Domain bei SMTP-TLS?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.

E-Mail Security Check starten