DANE für SMTP einrichten: TLSA-Einträge und DNSSEC für deinen Mailserver

Was das bedeutet

Standardmäßig nutzen Server, die dir E-Mails zustellen, TLS (STARTTLS) nur „wenn möglich“, und sie prüfen dein Zertifikat nicht. Ein Angreifer im Netzwerk könnte STARTTLS entfernen oder ein gefälschtes Zertifikat vorlegen. DANE für SMTP (RFC 7672) schließt diese Lücke: Du veröffentlichst im DNS einen TLSA-Eintrag, der angibt, welches Zertifikat oder welchen Schlüssel dein Mailserver nutzt, und DNSSEC beweist, dass dieser Eintrag echt ist. Sendende Server mit DANE-Unterstützung stellen dann nur noch mit gültigem, passendem TLS zu.

Ein TLSA-Eintrag für einen Mailserver wird unter _25._tcp. gefolgt vom MX-Hostnamen veröffentlicht:

_25._tcp.mail.yourdomain.com. IN TLSA 3 1 1 8f1c...e4a2

Die drei Zahlen bedeuten: 3 = das eigene Zertifikat des Servers (DANE-EE), 1 = nur den öffentlichen Schlüssel vergleichen (nicht das ganze Zertifikat), 1 = SHA-256-Hash. 3 1 1 ist die übliche Wahl für SMTP.

DANE und MTA-STS lösen dasselbe Problem auf unterschiedliche Weise. MTA-STS nutzt HTTPS und funktioniert ohne DNSSEC; DANE braucht DNSSEC. Du kannst beide veröffentlichen und mit TLS-RPT (in der MTA-STS-Anleitung behandelt) Berichte für beide erhalten.

Warum das passiert

Du richtest DANE vielleicht ein, weil:

• ein Sicherheitsaudit, eine Behörden- oder Branchenvorgabe oder ein Test wie internet.nl es verlangt (häufig in den Niederlanden und in Deutschland);
• du eingehende E-Mails vor Downgrade-Angriffen schützen willst;
• ein DANE-Test meldet, dass dein TLSA-Eintrag nach einer Zertifikatserneuerung nicht mehr passt, wodurch Absender mit DANE dir nichts mehr zustellen.

So prüfst du es

1. DNSSEC: Die Zone deines MX-Hostnamens muss signiert sein. Achte mit dig auf das ad-Flag eines validierenden Resolvers:

   dig +dnssec MX yourdomain.com @1.1.1.1
   ;; flags: qr rd ra ad;

   Zeigt der MX auf den Host deines Anbieters (Google, Microsoft 365...), braucht dessen Zone DNSSEC und TLSA, nicht deine.
2. TLSA-Eintrag:

   dig +dnssec TLSA _25._tcp.mail.yourdomain.com

3. Mit dem aktiven Zertifikat vergleichen:

   openssl s_client -connect mail.yourdomain.com:25 -starttls smtp \
     -servername mail.yourdomain.com </dev/null 2>/dev/null \
     | openssl x509 -noout -pubkey \
     | openssl pkey -pubin -outform DER | openssl dgst -sha256

   Der Hash muss dem letzten Feld des TLSA-Eintrags entsprechen.
4. Postfix-Tool: posttls-finger -t30 -T180 -c -L verbose,summary yourdomain.com zeigt, ob die DANE-Validierung gelingt.
5. Nutze den Domain-Scanner, um vor dem Start deine MX-Hostnamen zu bestätigen.

So behebst du es

1. DNSSEC aktivieren

Schalte DNSSEC bei deinem DNS-Anbieter ein und trage dann den DS-Eintrag bei deinem Registrar ein (viele machen das automatisch). Prüfe mit Whois, welcher Registrar die Domain verwaltet. Ohne gültige DNSSEC-Kette werden TLSA-Einträge ignoriert.

2. Den Hash des Serverschlüssels ermitteln

Auf dem Mailserver, aus der verwendeten Zertifikatsdatei:

openssl x509 -in /etc/ssl/mail/fullchain.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER | openssl dgst -sha256

3. Den TLSA-Eintrag veröffentlichen

Host:  _25._tcp.mail      (for MX host mail.yourdomain.com)
Type:  TLSA
Usage: 3   Selector: 1   Matching type: 1
Value: <the SHA-256 hex hash>

Veröffentliche einen Eintrag pro MX-Hostname. Das Zertifikat sollte trotzdem ein normales, gültiges Zertifikat sein, dessen Name zum Host passt, damit Absender ohne DANE und MTA-STS weiter funktionieren.

4. Zertifikatserneuerungen planen

Genau hier brechen die meisten DANE-Einrichtungen. Bei 3 1 1 folgt der Hash dem Schlüssel, nicht dem Zertifikat, also:

• Erneuere Zertifikate und behalte dabei denselben privaten Schlüssel (zum Beispiel mit der Certbot-Option --reuse-key), oder
• Nutze ein Schema „aktuell + nächster“: Erzeuge den nächsten Schlüssel vorab, veröffentliche einen zweiten TLSA-Eintrag dafür, warte mindestens zwei TTLs, stelle dann den Server auf den neuen Schlüssel um und entferne den alten Eintrag später.

5. DANE beim Senden prüfen (optional)

Betreibst du Postfix und einen lokalen Resolver, der DNSSEC validiert, aktiviere DANE für ausgehende E-Mails in main.cf:

smtp_dns_support_level = dnssec
smtp_tls_security_level = dane

Zu den TLS-Grundlagen auf deinem eigenen Server siehe E-Mails ohne TLS gesendet.

Prüfe, ob es behoben ist

Warte, bis die DNS-Caches abgelaufen sind, führe dann dig +dnssec TLSA erneut aus (die Antwort sollte das ad-Flag haben), vergleiche den Hash mit dem aktiven Zertifikat und starte posttls-finger noch einmal. Schick von einem externen Postfach eine E-Mail an deine Domain und prüfe im Mail-Log, ob die Verbindung über TLS lief. Mach auch einen Delivmail-Test von deinem Server, um zu bestätigen, dass der Versand weiterhin funktioniert. Prüfe nach jeder Zertifikatserneuerung erneut.