DANE und DNSSEC einrichten für Mailcow

DANE für Mailcow: DNSSEC signieren, TLSA aus dem MX-Zertifikat erzeugen (3 1 1), unter _25._tcp veröffentlichen — und bei jeder Zertifikatserneuerung mitziehen.

Stand: Juli 2026

Zusammenfassung: Nach dieser Anleitung ist die Zone deines Mailcow-Servers DNSSEC-signiert und veröffentlicht einen TLSA-Eintrag, der dein MX-Zertifikat festnagelt — der stärkste Transportschutz, den du selbst hosten kannst.

⚠️ Empfangsrisiko: Ein falscher TLSA-Eintrag oder eine kaputte DNSSEC-Kette führt dazu, dass DANE-prüfende Server die Zustellung an deine Domain hart ablehnen. Aktiviere zuerst DNSSEC, prüfe jeden Schritt und plane die Zertifikatserneuerung ein, bevor du TLSA veröffentlichst.

Selbst gehostet zu sein ist hier ein Vorteil: DANE ist der eine Sicherheitsmechanismus, den du auf eigener Infrastruktur voll ausschöpfen kannst — anders als bei den meisten Shared-Hostern.

Voraussetzungen

Was ist DANE mit DNSSEC?

DANE (DNS-based Authentication of Named Entities) hinterlegt im DNS einen TLSA-Eintrag, der das Zertifikat deines Mailservers festnagelt. Ein sendender Server prüft vor der Zustellung, ob das präsentierte TLS-Zertifikat zum TLSA-Eintrag passt — resistent gegen Downgrade- und MITM-Angriffe. Damit das vertrauenswürdig ist, muss die Zone DNSSEC-signiert sein; TLSA ohne DNSSEC ist wertlos.

DANE + DNSSEC sichern den Transportweg. Die Absenderidentität sichern SPF, DKIM und DMARC.

Schritt-für-Schritt-Anleitung

1. PTR und Grundlagen prüfen

DANE steht und fällt mit sauberen Grundlagen: Der PTR-Record deiner Server-IP muss dem MAILCOW_HOSTNAME entsprechen — für IPv4 und IPv6. Diese setzt du beim IP-Provider (Hetzner, Netcup …).

dig -x 203.0.113.25 +short    # muss mail.beispiel.de. liefern

2. DNSSEC für die Zone aktivieren

Aktiviere DNSSEC bei deinem DNS-Anbieter. Bei vielen Anbietern ist das ein Schalter in den DNS-Einstellungen; anschließend hinterlegst du den DS-Record bei der Registrierungsstelle der Domain. Prüfe die Kette danach z. B. mit einem DNSSEC-Analyzer. Ohne DNSSEC keinen TLSA-Eintrag veröffentlichen — das bringt keinen Schutz und kann bei manchen Resolvern zu Zustellproblemen führen.

3. TLSA-Eintrag aus dem MX-Zertifikat erzeugen

Der empfohlene und in der Praxis verbreitete TLSA-Typ ist 3 1 1 (Zertifikatverwendung 3 = direkte Zertifikatszuordnung, Auswahl 1 = öffentlicher Schlüssel, Übereinstimmender Typ 1 = SHA-256). So sieht ein echter Eintrag aus (Live-Beispiel eines DANE-Betreibers):

_25._tcp.mail.beispiel.de.  IN TLSA  3 1 1 <sha256-hash-des-public-keys>

Den Hash erzeugst du direkt aus dem Zertifikat deines Mailservers:

openssl x509 -in /path/to/cert.pem -noout -pubkey \
  | openssl pkey -pubin -outform DER \
  | openssl dgst -sha256 -binary \
  | xxd -p -c 256

Das Ergebnis ist der 3 1 1-Hash. Veröffentliche den TLSA-Record für jeden deiner MX-Hostnamen unter _25._tcp.<mx-hostname>.

4. Der kritische Punkt: Zertifikatserneuerung

Hier scheitern die meisten Selbsthoster. Mailcow erneuert das Let's-Encrypt-Zertifikat automatisch — und bei 3 1 1 auf den öffentlichen Schlüssel bleibt der Hash nur stabil, wenn der Schlüssel gleich bleibt. Standardmäßig erzeugt Let's Encrypt bei jeder Erneuerung ein neues Schlüsselpaar → der TLSA-Hash passt nicht mehr → Zustellungen von DANE-prüfenden Sendern (z. B. Microsoft 365, viele deutsche Provider) schlagen fehl.

Zwei saubere Lösungen:

Automatisiere das. Ein manuell gepflegter TLSA-Eintrag ist eine tickende Zustellbombe.

5. Warten und prüfen

DNS-Änderungen brauchen Zeit; DNSSEC-Signierung teils länger.

Ergebnis prüfen

Prüfe deine Konfiguration mit dem kostenlosen Kuveris-Scanner — er zeigt DNSSEC-Status, TLSA/DANE, PTR und das Zusammenspiel mit SPF, DKIM und DMARC.

Häufige Fehler

TLSA ohne DNSSEC. Ohne signierte Zone ist der TLSA-Eintrag wertlos und potenziell schädlich. DNSSEC zuerst.

Zertifikatserneuerung bricht DANE. Der häufigste Selbsthoster-Fehler: Nach der Let's-Encrypt-Erneuerung passt der 3 1 1-Hash nicht mehr. Rollover automatisieren oder Schlüssel beibehalten.

Nur einen MX-Host abgedeckt. Jeder MX-Hostname braucht seinen eigenen _25._tcp.<host>-TLSA-Eintrag.

PTR fehlt oder falsch. Reverse DNS muss zum MAILCOW_HOSTNAME passen — für IPv4 und IPv6.

Weiterführende Links

Verwandter Befund: Was bedeutet dieses Ergebnis?