DANE TLSA & CAA für Mailcow konfigurieren
Mailcow ist ein Docker-basierter Mailserver-Stack auf Basis von Postfix + Dovecot + Rspamd. DANE wird über die Postfix-Container-Override-Datei data/conf/postfix/extra.cf konfiguriert. DNSSEC und CAA werden beim externen DNS-Provider Ihrer Zone gesetzt. Die offizielle Mailcow-Doku ist auf Englisch (docs.mailcow.email) — die deutschsprachige Anleitung hier orientiert sich am Original mit Übersetzungs-Hinweisen.
DANE TLSA für Mailcow-Stack
Mailcow (offizielle Mailcow-Doku: docs.mailcow.email, Originaldokumentation auf Englisch — die hier verwendeten Begriffe wurden ins Deutsche übertragen) ist ein Docker-basierter Mailserver-Stack mit Postfix als MTA. DANE wird über die Postfix-Container-Override-Datei data/conf/postfix/extra.cf konfiguriert — die Standard-Mailcow-Konfiguration lädt diese Datei zusätzlich zur eingebauten main.cf. So bleiben Mailcow-Updates kompatibel mit eigenen DANE-Anpassungen.
Mailcow-Doku zu DNS-Voraussetzungen (Original-Englisch, Übersetzung): Die Mailcow-DNS-Prerequisites beschreiben die Pflicht-Records für MX (mail.ihre-domain.de als MAILCOW_HOSTNAME), SPF (v=spf1 mx a -all), DKIM (TXT-Record im Format dkim._domainkey IN TXT "v=DKIM1; k=rsa; t=s; s=email; p=...") und DMARC (p=reject empfohlen). DANE TLSA, MTA-STS und CAA werden in der Mailcow-Standard-Doku nicht im Detail behandelt — die Aktivierung ist eine eigene Hardening-Stufe nach RFC 7672. Reverse-DNS (PTR) für IPv4 und IPv6 muss zum MAILCOW_HOSTNAME passen (FCrDNS-Pflicht).
Voraussetzungen für Mailcow-DANE: (a) DNSSEC am eigenen Apex aktiv (beim externen DNS-Provider — siehe Cloudflare DNS, Netcup oder Hetzner DNS), (b) lokaler DNS-Resolver mit DNSSEC-Validierung im Host-System (Mailcow-Container nutzt Host-Resolver), (c) gültiges TLS-Zertifikat (Mailcow integriert acme-mailcow für Let's Encrypt). Hardening-Pfad: MX → SPF → DKIM → DMARC → MTA-STS → DNSSEC + DANE + CAA (dieser Guide).
DNSSEC am externen DNS-Provider aktivieren
Mailcow ist Mailserver-Stack, nicht DNS-Hoster. DNSSEC wird beim DNS-Provider der eigenen Zone aktiviert — passend zum Self-Hosting-Setup empfehlen sich Cloudflare DNS (1-Click), Netcup (ECDSAP256SHA256), Hetzner DNS (Status konservativ prüfen) oder deSEC (Berlin, DNSSEC by default).
TLSA-Records am Mailcow-Hostname anlegen
TLSA-Records werden für den MAILCOW_HOSTNAME generiert (typisch mail.ihre-domain.de). Für SMTP: _25._tcp.<MAILCOW_HOSTNAME> mit Usage 3 (DANE-EE), Selector 1 (SubjectPublicKeyInfo) und Matching-Type 1 (SHA-256-Hash). Mailcow nutzt Let's Encrypt — bei Renewal bleibt der Public-Key typisch stabil (Mailcow-Default), TLSA mit Selector 1 ist daher Renewal-stabil.
# TLSA-Record am MAILCOW_HOSTNAME
# (typisch mail.ihre-domain.de — der Hostname in mailcow.conf)
# Variante 1: openssl + xxd auf Mailcow-Host
docker exec postfix-mailcow openssl x509 \
-in /etc/ssl/mail/cert.pem \
-pubkey -noout |
openssl pkey -pubin -outform DER |
openssl dgst -sha256 |
awk '{print $2}'
# Beispiel-Ausgabe: 53eede6fbcd34c0eba32...
# TLSA-Record am DNS-Provider eintragen:
# _25._tcp.mail.ihre-domain.de. IN TLSA 3 1 1 53eede6fbcd34c0eba32...
# Mailcow-Cert wird via Let's Encrypt erneuert (acme-mailcow Container) —
# TLSA-Record mit Selector 1 (Public-Key) bleibt stabil, wenn Private-Key
# konstant bleibt (Mailcow Let's-Encrypt-Default: Public-Key wird beibehalten).Postfix-Container DANE-Override konfigurieren
Mailcow lädt zusätzliche Postfix-Konfiguration aus data/conf/postfix/extra.cf (auf dem Mailcow-Host typisch /opt/mailcow-dockerized/data/conf/postfix/extra.cf). DANE-Parameter dort eintragen, dann den Postfix-Container neu starten.
# data/conf/postfix/extra.cf
# Mailcow Postfix-Container main.cf-Override für DANE
# (Datei wird via docker-compose-Volume in /opt/postfix/conf/extra.cf gemountet)
# Outbound-DANE (RFC 7672)
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
# Alternativ strict (kein Fallback):
# smtp_tls_security_level = dane-only
# Postfix-Container neu starten:
# cd /opt/mailcow-dockerized
# docker-compose restart postfix-mailcowMailcow erneuert TLS-Zertifikate automatisch über den acme-mailcow-Container (Let's Encrypt). Bei Renewal wird der Public-Key typisch beibehalten — TLSA mit Selector 1 bleibt damit stabil. Falls Sie den Key explizit rotieren (mailcow.conf SKIP_LETS_ENCRYPT=y + manuelles Cert), müssen Sie den TLSA-Record entsprechend aktualisieren. RFC-Grundlage: Wenn Sie aktiv rotieren, folgen Sie der Current+Next-Pre-Publishing-Strategie nach RFC 7671 § 8.1 „Key Rollover with Fixed TLSA Parameters“ — vollständiges Direktzitat („at least two Times to Live (TTLs) or longer before the new chain is deployed“) und Provider-Automatisierungs-Pattern im Kapitel-Index-Block.
Mailcow-Container nutzen standardmäßig den Host-System-Resolver via Docker-DNS — wenn der Host-Resolver DNSSEC nicht validiert, scheitert die DANE-Funktion lautlos. Best Practice: einen lokalen DNSSEC-validierenden Resolver (Unbound oder systemd-resolved mit DNSSEC-Validation) auf dem Mailcow-Host installieren und im docker-compose.override.yml als DNS-Server für die Postfix- und Resolver-Container explizit setzen. Beispiel-Override (auf dem Mailcow-Host typisch unter /opt/mailcow-dockerized/docker-compose.override.yml):
services:
postfix-mailcow:
dns:
- 127.0.0.53 # systemd-resolved auf dem Host
unbound-mailcow:
dns:
- 127.0.0.53Wichtige Mailcow-Begriffs-Übersetzung (Markierung): Mailcow-Originaldokumentation ist Englisch (docs.mailcow.email) — die hier verwendeten Begriffe „Postfix-Container-Override“, „extra.cf-Override“, „docker-compose.override.yml“ und „MAILCOW_HOSTNAME“ sind direkte Übersetzungen der englischen Original-Terminologie. Quelle: docs.mailcow.email/getstarted/prerequisite-dns (Abruf 2026-05-18 — Cross-Reference R3-Quality-Welle-2-Verifikation: „Make sure that the PTR record of your IP address matches the FQDN“).
DANE-Verifikation per posttls-finger im Container
Nach Konfiguration prüfen Sie DANE-Funktion mit dig (DNSSEC + TLSA) und posttls-finger im Postfix-Container. Bei erfolgreicher DANE-Authentifizierung loggt Postfix „matched TLSA record“.
# DNSSEC am eigenen Apex prüfen
dig +dnssec MX ihre-domain.de | grep -E "RRSIG|ad;"
# TLSA-Record verifizieren
dig TLSA _25._tcp.mail.ihre-domain.de +short
# DANE-Status im Mailcow Postfix-Container
docker exec postfix-mailcow posttls-finger -t30 -T180 -L verbose \
mail.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 Mailcow automatisch (Banner-Detection für „ESMTP Postfix mailcow“), validiert DNSSEC am Apex, prüft TLSA-Records am MAILCOW_HOSTNAME und scannt CAA + SMTP-TLS-Konfiguration. Externe DANE-Tests via dane.sys4.de/smtp.
Häufige Fehler bei Mailcow DANE
DANE-Config in main.cf statt extra.cf gesetzt
Problem: DANE-Parameter direkt in /opt/postfix/conf/main.cf im Container gesetzt — Mailcow-Update überschreibt die Datei. Ursache: Falsche Konfigurationsschicht. Lösung: Alle Postfix-Custom-Overrides in data/conf/postfix/extra.cf auf dem Host — diese Datei wird via docker-compose-Volume gemountet und ist Update-stabil.
Host-Resolver ohne DNSSEC-Validation
Problem: DNSSEC am Apex aktiv, TLSA-Records gesetzt, aber Mailcow nutzt DANE nicht. Ursache: Der lokale DNS-Resolver auf dem Mailcow-Host validiert DNSSEC nicht (kein AD-Flag in DNS-Antworten). Mailcow-Container nutzen den Host-Resolver. Lösung: Auf dem Mailcow-Host systemd-resolved oder unbound mit DNSSEC-Validation konfigurieren und im docker-compose.override.yml als DNS-Server für die Container setzen.
TLSA mit Selector 0 wird bei Renewal kaputt
Problem: TLSA mit Usage 3 + Selector 0 (Full Cert) — bei jeder Let's-Encrypt-Renewal-Aktion (alle 60-90 Tage) wird die DANE-Validation kaputt, bis der TLSA-Record manuell aktualisiert wird. Ursache: Cert ist Renewal-instabil, Public-Key bleibt stabil. Lösung: Selector 1 (SubjectPublicKeyInfo) verwenden — TLSA bleibt stabil, solange acme-mailcow den Private-Key beibehält (Default-Verhalten).
Compliance: NIS2, BSI TR-03108 und DSGVO mit Mailcow DANE
Ein Mailcow-Setup mit aktiviertem DANE (extra.cf 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 Mailcow-Update-Disziplin (Docker-Image-Updates über update.sh-Script). DSGVO Art. 32 lit. b durch downgrade-resistente Verschlüsselung.
Mailcow DANE-Compliance-Stack: NIS2 lit. h (DNSSEC + DANE TLSA + CAA) + NIS2 lit. e (Mailcow-Update-Disziplin via update.sh + Docker-Image-Patches) + 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 Mailcow automatisch (Banner-Detection für „ESMTP Postfix mailcow“), validiert DNSSEC am Apex, prüft TLSA-Records am MAILCOW_HOSTNAME und scannt CAA + SMTP-TLS-Konfiguration. Cross-Verweis: DNS-Hijacking-Spoofing und SubdoMailing.
DNS-Sicherheits-Anleitung für weitere Provider:
Wie steht Ihre Domain bei DNS-Sicherheit · Mailcow?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.