DANE TLSA für Postfix konfigurieren
Postfix unterstützt DANE seit Version 2.11 (Originalzitat aus postfix.org/TLS_README.html). Diese Anleitung zeigt DNSSEC-Voraussetzung am Apex, TLSA-Record-Generation mit hash-slinger oder posttls-finger und die main.cf-Konfiguration mit smtp_dns_support_level + smtp_tls_security_level für inbound + outbound DANE.
DANE TLSA für Postfix-Mailserver
Postfix unterstützt DANE seit Version 2.11. Direktzitat aus der offiziellen Postfix-Dokumentation (postfix.org/TLS_README.html, Abruf 2026-05-18): „RFC 7672 (DANE) TLS authentication is available with Postfix 2.11 and later.“ Die Konfiguration erfolgt über zwei main.cf-Parameter: smtp_dns_support_level = dnssec aktiviert DNSSEC-Validierung in der Postfix-Resolver-Schicht, smtp_tls_security_level = dane bzw. dane-only aktiviert die TLSA-Record-Validierung beim ausgehenden SMTP-Verbindungsaufbau.
Voraussetzungen für DANE-Funktionsfähigkeit (RFC 7672 § 3): (a) DNSSEC am eigenen Apex aktiv und korrekt validiert (Chain of Trust bis zur Root-Zone), (b) DNSSEC für den TLSA-Record selbst (sonst ignoriert der sendende Mailserver den Record), (c) das eigene TLS-Zertifikat passt zum TLSA-Record (Usage 3 = Domain-issued, am häufigsten für SMTP). DANE setzt DNSSEC zwingend voraus — ohne aktive DNSSEC-Kette ist DANE wirkungslos, der sendende Mailserver ignoriert die TLSA-Records.
dane vs. dane-only (Direktzitat aus Postfix-Doku): „dane level is a stronger form of opportunistic TLS“ — DANE wird verwendet, wenn TLSA-Records verfügbar sind, sonst Fallback auf opportunistisches TLS, Mail wird auch ohne DANE-Authentifizierung zugestellt. „dane-only level is a form of secure-channel TLS based on the DANE PKI“ — verlangt gültige TLSA-Records, ohne brauchbare TLSA wird die Zustellung aufgeschoben (tempfail), höchste Sicherheitsstufe für DANE-fähige Ziele. Hardening-Pfad: MX → SPF → DKIM → DMARC → MTA-STS → DNSSEC + DANE + CAA (dieser Guide). Bedrohungs-Cluster: DNS-Hijacking-Spoofing und SubdoMailing.
Postfix-Version + DNSSEC-Voraussetzung prüfen
DANE-Unterstützung gibt es ab Postfix 2.11. Vor der DANE-Konfiguration: Version prüfen und DNSSEC am eigenen Apex sicherstellen — sonst sind alle TLSA-Records wirkungslos.
# Postfix-Version prüfen
postconf -d mail_version
# Erwartet: mail_version = 3.x.x (oder 2.11+)
# DANE-Unterstützung ist verfügbar ab Postfix 2.11 und später.
# Original-Zitat aus Postfix-Doku (postfix.org/TLS_README.html, Abruf 2026-05-18):
# "RFC 7672 (DANE) TLS authentication is available with Postfix 2.11 and later."Postfix verlässt sich auf den lokalen DNS-Resolver für DNSSEC-Validierung — der Resolver MUSS das AD-Flag (Authenticated Data) setzen für valide DNSSEC-Antworten. Auf modernen Debian/Ubuntu-Systemen mit systemd-resolved oder unbound ist das Standard-konfigurierbar. Wenn DNSSEC-Validierung beim Resolver nicht aktiv ist, akzeptiert Postfix die TLSA-Records nicht (RFC 7672 § 3 Pflicht).
Postfix liefert posttls-finger als integriertes Diagnose-Tool mit — typische Aufruf-Syntax posttls-finger -t30 -T180 -L verbose mx1.ihre-domain.de zeigt im verbose-Modus die TLSA-Match-Zeile „matched TLSA record“ oder den Mismatch-Grund. Für die TLSA-Record-Generation aus einem Zertifikat ist hash-slinger (Paket hash-slinger in Debian/Ubuntu/Fedora-Repos, Upstream auf GitHub) das Standard-Werkzeug — tlsa --create --selector 1 --mtype 1 --port 25 --certificate /etc/letsencrypt/live/mail.ihre-domain.de/fullchain.pem mail.ihre-domain.de erzeugt den passenden TLSA-Record-Eintrag im Zone-File-Format. Pre-Renewal-Hook-Pattern: Beim Let's-Encrypt-Renewal (alle 60-90 Tage) kann ein Pre-Renewal-Hook den zukünftigen TLSA-Record als zweiten Record neben dem aktuellen publizieren (Pre-Publishing) — dieser Race-Condition-Schutz vermeidet DANE-Bounces in den Minuten zwischen Cert-Wechsel und TLSA-Update. Direkt-Zitat aus postfix.org/TLS_README.html: „RFC 7672 (DANE) TLS authentication is available with Postfix 2.11 and later.“ (Abruf 2026-05-18 — R3-Verifikation-Welle-2-Korrektur einer R3-Quality-Wortreihenfolgen-Drift).
TLSA-Record am MX-Host generieren
TLSA-Records werden pro MX-Host und Port erzeugt. Für SMTP: _25._tcp.<mx-host> mit Usage 3 (DANE-EE, Domain-issued, RFC 7672 empfohlen), Selector 1 (SubjectPublicKeyInfo) und Matching-Type 1 (SHA-256-Hash).
# Variante 1: hash-slinger (Python-Tool)
# Installation auf Debian/Ubuntu:
apt-get install hash-slinger
# TLSA-Record für eigenen MX-Host generieren:
tlsa --create --usage 3 --selector 1 --mtype 1 \
--port 25 --protocol tcp \
mx1.ihre-domain.de
# Ausgabe (Beispielformat):
# _25._tcp.mx1.ihre-domain.de. IN TLSA 3 1 1 53eede6fbcd34c0eba3...
# Variante 2: posttls-finger (Postfix-eigenes Tool)
posttls-finger -t30 -T180 -c -L verbose mx1.ihre-domain.de
# Liefert SHA-256-Hash zur manuellen TLSA-Konstruktion.
# Variante 3: openssl + xxd (manuell für Usage 3, Selector 1, Matching 1)
openssl x509 -in /etc/letsencrypt/live/mx1.ihre-domain.de/fullchain.pem \
-pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256 |
awk '{print $2}'main.cf für DANE konfigurieren
Die zwei zentralen Parameter in /etc/postfix/main.cf aktivieren DANE. Wichtig: Bei Cert-Renewal (z.B. Let's Encrypt) muss der TLSA-Record erneuert werden — oder Sie nutzen Selector 1 (Public-Key, der bei Cert-Renewal stabil bleibt, wenn der private Key beibehalten wird).
# /etc/postfix/main.cf — DANE-Konfiguration (Postfix 2.11+)
# Outbound-DANE-Authentifizierung (RFC 7672):
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
# Alternativ: smtp_tls_security_level = dane-only
# "dane" (opportunistisch):
# - Nutzt DANE wenn TLSA-Records verfügbar
# - Fallback auf opportunistisches TLS sonst
# "dane-only" (obligatorisch):
# - Verlangt gültige TLSA-Records
# - Bei fehlenden TLSA: tempfail, kein Versand
# Inbound-DANE (eigener MX wird per TLSA von anderen authentifiziert):
# Standard-smtpd-TLS-Konfiguration reicht — Postfix muss ein gültiges
# Cert vorweisen, das per TLSA-Record am _25._tcp. verankert ist.
smtpd_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.ihre-domain.de/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.ihre-domain.de/privkey.pem
# Postfix neu laden:
# postfix reload Bei Let's-Encrypt-Renewal alle 60-90 Tage: TLSA-Record mit Selector 1 (Public-Key, stabil wenn privater Key gleich bleibt) oder mit Rollover-Pre-Publishing (zweiter TLSA-Record für neues Cert, vor Renewal-Datum publizieren). Bei DigiCert/Sectigo-Cert-Renewals analog. Postfix-Pre-Renew-Hook kann TLSA-Record automatisch im DNS-Provider updaten (Cloudflare API, deSEC API, etc.). RFC-Grundlage: RFC 7671 § 8.1 „Key Rollover with Fixed TLSA Parameters“ empfiehlt diese Current+Next-Pre-Publishing-Strategie zeichengenau — vollständiges Direktzitat und Automatisierungs-Patterns im Kapitel-Index-Block „TLSA-Rollover-Strategie nach RFC 7671 § 8.1“.
DANE-Verifikation per posttls-finger
Nach Aktivierung prüfen Sie die DANE-Funktion mit dig (DNSSEC + TLSA), posttls-finger (Postfix-eigenes Tool) und Postfix-Log-Search.
# DNSSEC am eigenen Apex prüfen
dig +dnssec MX ihre-domain.de | grep -E "RRSIG|ad;"
# TLSA-Record verifizieren
dig TLSA _25._tcp.mx1.ihre-domain.de +short
# DANE-Logs in Postfix-Log-File suchen
grep "Verified TLS connection.*dane" /var/log/mail.log
# Mit posttls-finger End-zu-End:
posttls-finger -t30 -T180 -L verbose mx1.ihre-domain.de
# Erwartete Zeile: "matched TLSA record"
# Online: DANE SMTP Validator
# https://dane.sys4.de/smtp/ihre-domain.deValidieren Sie zusätzlich mit dem Wolf-Agents Email Security Check — dieser erkennt Postfix automatisch (Banner-Detection für „ESMTP Postfix“), prüft DNSSEC am Apex, validiert TLSA-Records am MX-Host und scannt CAA + SMTP-TLS-Konfiguration. Der DANE SMTP Validator (dane.sys4.de/smtp) bietet ergänzend einen End-zu-End-Test der Mailserver-DANE-Konfiguration.
Häufige Fehler bei Postfix DANE
DNSSEC am Apex fehlt
Problem: TLSA-Records gesetzt, DANE in main.cf aktiv, aber Mailserver nutzt DANE nicht. Ursache: DNSSEC am eigenen Apex nicht aktiv — sendende Mailserver ignorieren TLSA-Records ohne DNSSEC (RFC 7672 § 3). Lösung: Vor DANE-Aktivierung DNSSEC am DNS-Provider aktivieren und DS-Record beim Registrar eintragen.
TLSA-Record veraltet nach Cert-Renewal
Problem: Let's-Encrypt-Renewal → TLSA-Record stimmt nicht mehr → DANE-Fehler → ausgehender Mail-Bounce. Ursache: TLSA mit Usage 3 + Selector 0 (Full Cert) ist Renewal-instabil. Lösung: Selector 1 (SubjectPublicKeyInfo) nutzen, da Public-Key bei stabilem privatem Key über Renewals hinweg konstant bleibt — oder Pre-Renewal-Hook nutzen, der den TLSA-Record vor dem Renewal aktualisiert.
dane-only ohne Plan-B
Problem: smtp_tls_security_level = dane-only setzt strikte DANE-Pflicht — bei TLSA-Fehler bei Empfänger-MX (z.B. abgelaufene RRSIG) wird Mail nicht zugestellt. Ursache: dane-only ist obligatorisch, kein Fallback. Lösung: Standard smtp_tls_security_level = dane (opportunistisch) für Mail-Routing; dane-only nur für gezielt definierte secure-channel-Ziele.
Compliance: NIS2, BSI TR-03108 und DSGVO mit Postfix DANE
Eine Postfix-Konfiguration mit aktiviertem DANE (smtp_dns_support_level=dnssec + smtp_tls_security_level=dane) ist der prüfbare Nachweis für NIS2 Art. 21 Abs. 2 lit. h (Kryptografie und Verschlüsselung) auf DNS- und Transport-Schicht. Ergänzend lit. e (Schwachstellen-Management) durch Postfix-Versions-Hygiene (DANE ab 2.11, aktuelle 3.x-Releases empfohlen). DSGVO Art. 32 lit. b (Verfügbarkeit + Integrität) durch downgrade-resistente Verschlüsselung.
Postfix DANE-Compliance-Stack: NIS2 lit. h (DNSSEC + DANE TLSA + CAA) + NIS2 lit. e (Postfix-Versions-Hygiene + Patch-Disziplin) + BSI TR-03108 (E-Mail-Transport mit DANE) + DSGVO Art. 32 lit. b (Verfügbarkeit + Integrität). Wolf-Agents-USP: Der Email Security Check erkennt Postfix automatisch (Banner-Detection für „ESMTP Postfix“), validiert DNSSEC am Apex, prüft TLSA-Records am MX-Host (Usage 3 Selector 1 Matching 1 empfohlen) und scannt CAA-Konfiguration. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing.
DNS-Sicherheits-Anleitung für weitere Provider:
Wie steht Ihre Domain bei DNS-Sicherheit · Postfix?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.