Was ist DANE?

Das Problem: TLS bei E-Mail ist „besser als nichts”

Wenn ein Mailserver eine E-Mail zustellt, versucht er per STARTTLS eine verschlüsselte Verbindung aufzubauen. Klappt das, wird verschlüsselt zugestellt. Klappt es nicht, fällt der Server auf Klartext zurück — opportunistisches TLS.

Das Problem dabei: ein Angreifer auf dem Netzwerkpfad kann die STARTTLS-Ankündigung des Empfängers entfernen, und der Sender liefert klartextlich. Selbst wenn TLS verhandelt wird, kann ein Man-in-the-Middle ein gefälschtes Zertifikat präsentieren — die meisten Sendeserver validieren Zertifikate bei SMTP nicht streng (anders als Browser bei HTTPS).

MTA-STS löst das teilweise: es sagt Sendern, dass sie TLS verwenden müssen. Aber MTA-STS hat zwei Schwächen:

Trust on First Use (TOFU) — der erste Abruf der MTA-STS-Policy könnte schon manipuliert sein
Kein Cert-Pinning — MTA-STS prüft nur, dass irgendein gültiges Cert verwendet wird, nicht welches

DANE schließt beide Lücken.

DANE (DNS-based Authentication of Named Entities, definiert in RFC 6698 und RFC 7672 für SMTP) erlaubt Domain-Inhabern, das exakte TLS-Zertifikat ihres Mailservers im DNS zu hinterlegen — abgesichert durch DNSSEC. Sendende Server prüfen vor der TLS-Handshake, welches Zertifikat erwartet wird, und lehnen alles andere ab.

Vereinfacht: MTA-STS sagt „nutze TLS”, DANE sagt „nutze genau dieses TLS-Zertifikat”.

DANE setzt zwingend DNSSEC voraus — ohne signierte DNS-Antworten könnte ein Angreifer den TLSA-Record selbst manipulieren, und das ganze Schutzkonzept wäre wertlos.

Wie funktioniert es?

DANE nutzt einen neuen DNS-Record-Typ: TLSA. Der Record steht unter einem speziellen Namen, der Port und Protokoll in den DNS-Pfad einbettet:

_25._tcp.mail.deinedomain.de.  IN  TLSA  3 1 1 a4f3...e1b2

Übersetzt: „Für TCP-Port 25 zum Host mail.deinedomain.de gilt dieser Cert-Hash.”

Aufbau eines TLSA-Records

Ein TLSA-Record hat vier Felder:

Feld	Werte	Bedeutung
Usage	0-3	Wie das Zertifikat zum Trust gehört
Selector	0 oder 1	Was wird gehasht: das ganze Cert (0) oder nur der Public Key (1)
Matching Type	0-2	Hash-Funktion: kein Hash (0), SHA-256 (1), SHA-512 (2)
Certificate Association Data	hex string	Der Hash selbst

Die Usage-Werte im Detail

Die wichtigste Entscheidung beim TLSA-Setup:

Usage	Name	Bedeutung
0	PKIX-TA	CA-Constraint, prüft Trust-Anchor zusätzlich zur PKIX-Validation
1	PKIX-EE	End-Entity, das exakte Cert plus PKIX-Validation
2	DANE-TA	Trust-Anchor, eigene CA, ohne externe PKIX
3	DANE-EE	End-Entity, exaktes Cert, ohne PKIX (häufigster Wert)

In der Praxis ist 3 1 1 der Standard für SMTP: DANE-EE, SubjectPublicKeyInfo, SHA-256. Vorteil: bei Cert-Erneuerung mit gleichem Schlüssel bleibt der Hash stabil.

Beispielrecord

_25._tcp.mail.deinedomain.de.  IN  TLSA  3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Sender liest: „Wenn du Port 25 zu mail.deinedomain.de öffnest und TLS startest, muss der angebotene Public-Key-Hash genau diesen Wert haben.”

DANE vs. MTA-STS

Beide adressieren Transportsicherheit bei eingehender E-Mail, aber unterschiedlich:

Eigenschaft	DANE	MTA-STS
Voraussetzung	DNSSEC zwingend	Keine
Verteilung	DNS (TLSA-Record)	DNS-TXT + HTTPS-Datei
Cert-Bindung	Exaktes Cert / Public Key	Beliebiges gültiges PKIX-Cert
TOFU-Lücke	Nein	Ja (erster Abruf)
Downgrade-Schutz	Sofort	Nach erstem Abruf
Adoption global	~10% (wachsend)	~30-40%
Adoption DACH .de	überdurchschnittlich	hoch
Cert-Rotation-Aufwand	Hoch (TLSA muss synchron)	Niedrig

Sind sie Konkurrenten? Nein. Beste Praxis ist beides parallel — DANE für DNSSEC-fähige Sender, MTA-STS für den Rest. Sender, die beides validieren können (z.B. moderne Sendeserver), bevorzugen typischerweise DANE.

Wer unterstützt DANE als Sender?

Inbound-DANE-Validation ist bei großen E-Mail-Anbietern unterschiedlich verbreitet:

Microsoft 365 — Inbound-DANE wird seit 2024/2025 ausgerollt, Verfügbarkeit pro Tenant variiert. Outbound bereits etabliert.
Google Workspace — Outbound ja, Inbound bisher nicht
Posteo, Mailbox.org, Riseup — DANE-EE etabliert
Open-Source-Sendeserver — Postfix (≥ 2.11), Exim, Halon: alle DANE-fähig

Im DACH-Raum ist DANE bei datenschutzbewussten Providern und Behörden (BSI-Empfehlung) deutlich häufiger als im internationalen Schnitt.

Einrichtung — Schritt für Schritt

Schritt 1: DNSSEC aktivieren

Ohne DNSSEC kein DANE. Wenn deine Zone noch nicht signiert ist, richte zuerst DNSSEC ein. Validiere mit dig oder dnsviz.net, dass das AD-Bit auf deine Zone gesetzt wird.

Schritt 2: Mailserver-Cert prüfen

DANE funktioniert am besten mit:

Stabilen Public Keys — bei Cert-Erneuerung denselben Private Key behalten (Selector 1, Matching Type 1 hashed nur den Public Key)
Lange Cert-Laufzeit oder automatischer TLSA-Rotation
Long-living Intermediates — bei DANE-TA (Usage 2) reicht es, das Intermediate-Cert zu pinnen

Bei Let’s Encrypt mit ACME: Schlüssel-Reuse aktivieren (--reuse-key bei certbot), sonst musst du TLSA bei jedem Renewal neu schreiben.

Schritt 3: TLSA-Hash berechnen

Vom Live-Cert deines Mailservers den Public-Key-Hash extrahieren:

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

Das liefert den 64-stelligen Hex-String, der ins TLSA-Feld kommt.

Schritt 4: TLSA-Record veröffentlichen

Pro MX-Host und Port (typisch 25 für SMTP) einen TLSA-Record:

_25._tcp.mail.deinedomain.de.  IN  TLSA  3 1 1 <hash>

Wenn du mehrere MX-Hosts hast, brauchst du pro Host einen eigenen TLSA-Record — Wildcards funktionieren nicht.

Schritt 5: Testen

# Cert-Pin abfragen
dig TLSA _25._tcp.mail.deinedomain.de +dnssec

# Live-Validation testen
posttls-finger -L verbose -P /etc/ssl/certs mail.deinedomain.de

Sender wie Microsoft, Posteo oder selbst gehostete Postfix-Instanzen senden dann TLS-RPT-Berichte, in denen dane als Policy-Typ auftaucht — vorausgesetzt, du hast TLS-RPT eingerichtet.

Schritt 6: TLSA-Rotation planen

Vor jeder Cert-Erneuerung:

Neuen Hash zusätzlich zum alten publizieren (mehrere TLSA-Records koexistieren)
Cert-Renewal durchführen
Mehrere Tage warten, damit DNS-Caches sich anpassen
Alten Hash entfernen

Wenn du das überspringst, lehnen DANE-fähige Sender deine Mail während der Rollout-Phase ab.

Häufige Fallstricke

Keine DNSSEC-Signatur — TLSA-Records ohne DNSSEC-Schutz werden von DANE-Validatoren ignoriert. Erst DNSSEC, dann DANE.
Cert-Erneuerung ohne TLSA-Update — typischer Self-Inflicted-DoS. Bei Let’s Encrypt mit --reuse-key arbeiten oder Automation aufsetzen, die TLSA bei jedem Renewal aktualisiert.
TLSA für alle MX-Hosts vergessen — wenn du mx1 und mx2 hast und nur für mx1 einen TLSA setzt, lehnen DANE-Sender alle E-Mails an mx2 ab.
DANE bei Cloud-Provider — bei Microsoft 365 und Google Workspace publiziert der Provider die TLSA-Records (oder eben nicht). Du als Tenant kannst nichts setzen.
Falsche Usage-Wahl — DANE-EE (3) ist für die meisten SMTP-Setups richtig. PKIX-EE (1) verlangt zusätzlich PKIX-Validation, was bei selbst-signierten Certs scheitert.
Hash auf das ganze Cert — bei Selector=0, Matching Type=1 musst du bei jeder Cert-Erneuerung den Hash neu berechnen, auch wenn der Schlüssel gleich bleibt. Selector=1 ist robuster.

DANE für ausgehende Mail

Dieser Artikel fokussiert auf inbound DANE — andere Sender prüfen TLSA, wenn sie an dich zustellen. Outbound DANE ist die Spiegelseite: dein Sendeserver prüft TLSA-Records des Empfängers, bevor er sich zu dessen MX verbindet.

Outbound DANE ist eine reine Sender-Konfiguration:

Postfix: smtp_dns_support_level = dnssec und smtp_tls_security_level = dane
Exim: dane = * in der Smtp-Transport-Definition
Microsoft 365: standardmäßig aktiv

Outbound DANE ist transparent für Empfänger und schützt dein Outgoing-Mail vor MITM auf gegnerischer Seite. Die Einrichtung braucht keinen eigenen TLSA-Record bei dir — nur DNSSEC-fähige Resolution beim Sendeserver.

Wer sollte DANE nutzen?

DANE ist sinnvoll, wenn folgendes zutrifft:

Du betreibst eigene MX — kein Cloud-only-Mail (M365 ohne eigene Cert-Kontrolle)
DNSSEC ist aktiv — Pflicht
Cert-Management ist automatisiert — sonst werden TLSA-Mismatches zur DoS-Quelle
Du willst maximale Transportsicherheit — Compliance-Sektoren, datenschutzkritische Branchen

Für reine Cloud-Mail-Tenants (M365, Google Workspace) ist DANE-Outbound automatisch aktiv, aber bei Inbound musst du auf den Provider warten. Bis Microsoft seinen Inbound-DANE-Rollout abschließt, ist die Empfehlung an M365-Tenants: MTA-STS einrichten, DNSSEC aktivieren, DANE folgt automatisch durch Microsoft.

Fazit

DANE ist die strengste Form von Transportsicherheit für SMTP. Es schließt die TOFU-Lücke von MTA-STS und bindet die TLS-Verbindung an genau das Zertifikat, das du im DNS publiziert hast. Voraussetzung ist DNSSEC — und damit auch ein Registrar, der DNSSEC für deine Konstellation unterstützt.

Aufwand vs. Nutzen: DANE ist sinnvoll für selbst betriebene MX mit stabiler Cert-Lifecycle-Automation. Für Cloud-Mail-Tenants läuft es zunehmend automatisch — du musst nur DNSSEC aktiv halten.

DMARCPulse prüft für jede überwachte Domain, ob DNSSEC aktiv ist und ob TLSA-Records auf den MX-Hosts veröffentlicht sind. Bei Cloud-MX (Microsoft 365, Google Workspace) bekommst du provider-spezifische Hinweise statt verwirrender TLSA-Setup-Anleitungen — wir wissen, dass du dort als Tenant nichts publizieren kannst. Bei selbst betriebenen MX bekommst du den genauen Record-Namen (_25._tcp.<host>), das empfohlene Format (3 1 1 <hash>) und den openssl-Befehl zum Hash-Berechnen. Plus: kontinuierliche Überwachung, ob deine TLSA-Records nach Cert-Rotationen noch zum Live-Cert passen.

Zusammenfassung

DANE bindet TLS-Zertifikate an DNS via TLSA-Record, abgesichert durch DNSSEC
Standard-Format für SMTP: _25._tcp.<mxhost> TLSA 3 1 1 <SHA-256 des Public Keys>
Schützt vor Downgrade-Angriffen und Cert-Spoofing — strenger als MTA-STS
DNSSEC zwingend Voraussetzung
Cert-Rotation muss TLSA-Updates mitführen, sonst Self-Inflicted-DoS
Bei Cloud-Mail-Tenants (M365, Google) publiziert der Provider — Tenants können nichts selbst setzen
DMARCPulse erkennt Cloud-MX automatisch und gibt provider-spezifische Hinweise statt generischer TLSA-Anleitung