DANE/TLSA: die Komplettanleitung zur DNS-basierten Zertifikatauthentifizierung für E-Mail

Von CaptainDNS
Veröffentlicht am 21. Februar 2026

Aktualisiert am 9. Juli 2026

DANE/TLSA: TLS-Zertifikate von E-Mail-Servern per DNS und DNSSEC authentifizieren

TL;DR

DANE bindet TLS-Zertifikate über DNSSEC-signierte TLSA-DNS-Einträge an Domainnamen und eliminiert so die Abhängigkeit von Zertifizierungsstellen
DANE-EE mit SPKI und SHA-256 (3 1 1) ist der Goldstandard zur Absicherung von SMTP
DNSSEC ist eine zwingende Voraussetzung: ohne signierte Zone werden TLSA-Einträge ignoriert
DANE und MTA-STS ergänzen sich: DANE prüft das Zertifikat per DNS, MTA-STS erzwingt TLS per HTTPS
TLS-RPT (RFC 8460) ermöglicht die Überwachung von DANE-Fehlern im Produktivbetrieb und hilft, Rotationsprobleme frühzeitig zu erkennen

2026 laufen über 95 % der bei Gmail eingehenden E-Mails über TLS (Google Transparency Report). Und doch: Wenn ein SMTP-Server eine E-Mail versendet, woher weiß er, dass der Zielserver der richtige ist? Standardmäßig weiß er es nicht. STARTTLS verschlüsselt die Verbindung opportunistisch, prüft aber weder die Identität des Servers noch die Echtheit des Zertifikats. Ein Angreifer im Netzwerk kann die Verbindung abfangen, ein gefälschtes Zertifikat vorlegen und Ihre Nachrichten mitlesen.

DANE (DNS-based Authentication of Named Entities) löst dieses Problem, indem die erwarteten Zertifikatsinformationen direkt im DNS veröffentlicht werden. Der sendende Server fragt den TLSA-Eintrag ab, prüft, ob das vorgelegte Zertifikat übereinstimmt, und verweigert die Verbindung bei Abweichungen. Der entscheidende Punkt: DNSSEC signiert diese Information und garantiert, dass sie nicht gefälscht wurde.

Dieser Leitfaden behandelt die Funktionsweise von DANE, den Aufbau eines TLSA-Eintrags, die empfohlenen Einsatzszenarien für E-Mail, das schrittweise Deployment, die Ergänzung durch MTA-STS und das Monitoring via TLS-RPT. Er richtet sich an E-Mail-Administratoren, Infrastruktur-Ingenieure und DevOps, die Mailserver betreiben.

Wie funktioniert DANE?

Das Problem des opportunistischen TLS

SMTP wurde 1982 ganz ohne Verschlüsselung konzipiert. STARTTLS kam erst 2002 hinzu (RFC 3207), damit Server eine TLS-Verbindung aushandeln können. Aber diese Aushandlung ist opportunistisch: Wenn der Zielserver kein TLS unterstützt, wird die Nachricht im Klartext gesendet. Schlimmer noch: Ein Angreifer kann den STARTTLS-Befehl aus der SMTP-Antwort entfernen (Downgrade-Angriff) und den Versand ohne Verschlüsselung erzwingen.

Selbst wenn TLS ausgehandelt wird, prüft der sendende Server das Zertifikat standardmäßig nicht. Er akzeptiert jedes Zertifikat, auch ein selbstsigniertes eines Angreifers. Die Verschlüsselung existiert, aber die Authentifizierung fehlt.

DANE: das Zertifikat im DNS

DANE dreht die Logik um. Anstatt einer externen Zertifizierungsstelle (CA) zu vertrauen, veröffentlicht der Domain-Inhaber im DNS den Fingerprint des Zertifikats, das sein Server vorlegen muss. Der sendende Server:

Löst den MX der Ziel-Domain auf
Sucht den TLSA-Eintrag zum MX-Server
Prüft die DNSSEC-Signatur der Antwort
Baut die TLS-Verbindung auf und vergleicht das vorgelegte Zertifikat mit dem TLSA-Fingerprint
Verweigert die Verbindung, wenn das Zertifikat nicht übereinstimmt

Die DNSSEC-Vertrauenskette

DANE funktioniert nur, wenn die DNS-Zone per DNSSEC signiert ist. Ohne DNSSEC könnte ein Angreifer den TLSA-Eintrag fälschen und seinen eigenen Zertifikats-Fingerprint einschleusen. Laut APNIC validieren 2026 allerdings weniger als 40 % der Domains DNSSEC, was die Verbreitung von DANE weiterhin ausbremst. Die Vertrauenskette reicht von der DNS-Root bis zum TLSA-Eintrag:

. (Root) → com. → captaindns.com. → _25._tcp.mail.captaindns.com. TLSA

Jedes Glied wird von der übergeordneten Zone signiert. Wenn ein einziges Glied bricht (unsignierte Zone, abgelaufene Signatur), schlägt die DNSSEC-Validierung fehl und der TLSA-Eintrag wird ignoriert.

DANE-Prüfablauf: vom DNS zum TLS-Zertifikat über die DNSSEC-Validierung

Aufbau eines TLSA-Eintrags

TLSA ist ein dedizierter DNS-Eintragstyp (RRTYPE 52, definiert in RFC 6698) mit eigenem binären Wire-Format. Im Gegensatz zu SPF, DKIM oder DMARC, die TXT-Einträge verwenden, ist TLSA ein nativer Typ: DNS-Clients fragen gezielt den Typ TLSA ab (QTYPE=52). TLSA-Daten in einem TXT-Eintrag zu veröffentlichen, würde nicht funktionieren.

Ein TLSA-Eintrag besteht aus vier Feldern:

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

Der Name folgt der Konvention _port._protokoll.hostname. Für einen SMTP-Server auf Port 25 ist das _25._tcp.mail.captaindns.com.

Usage (Feld 1): Was wird geprüft?

Wert	Name	Beschreibung
0	PKIX-TA	Prüft das CA-Zertifikat + die klassische CA-Kette
1	PKIX-EE	Prüft das Server-Zertifikat + die klassische CA-Kette
2	DANE-TA	Prüft das CA-Zertifikat, ohne die klassische CA-Kette zu verlangen
3	DANE-EE	Prüft das Server-Zertifikat direkt, ohne CA

Selector (Feld 2): Welcher Teil des Zertifikats?

Wert	Name	Beschreibung
0	Cert	Vollständiges Zertifikat (DER)
1	SPKI	Nur der öffentliche Schlüssel (SubjectPublicKeyInfo)

SPKI (1) wird empfohlen: Der öffentliche Schlüssel ändert sich nicht, wenn Sie das Zertifikat mit demselben Schlüsselpaar erneuern. Das vereinfacht die Rotation.

Matching type (Feld 3): Datenformat

Wert	Name	Beschreibung
0	Full	Vollständige Rohdaten
1	SHA-256	SHA-256-Hash (32 Bytes, 64 Hex-Zeichen)
2	SHA-512	SHA-512-Hash (64 Bytes, 128 Hex-Zeichen)

SHA-256 (1) ist der Standard: kompakt, kollisionsresistent, überall unterstützt.

Welchen TLSA-Usage wählen?

DANE-EE (Usage 3): die empfohlene Wahl für SMTP

RFC 7672 (Abschnitt 3.1) empfiehlt DANE-EE für E-Mail. Die Kombination 3 1 1 (DANE-EE + SPKI + SHA-256) ist der Goldstandard:

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 a0b1c2d3e4f5...

Bei DANE-EE läuft das Vertrauen vollständig über DNSSEC statt über Zertifizierungsstellen. Das Zertifikat dient lediglich als Container für den öffentlichen Schlüssel: RFC 7671 (Abschnitt 5.1) legt fest, dass weder die CA-Kette, noch der Hostname im Zertifikat, noch das Ablaufdatum geprüft werden. Das ist eine bewusste Design-Entscheidung, kein Mangel. Das klassische CA-Modell ist für SMTP grundsätzlich ungeeignet: Unter den 150+ anerkannten Zertifizierungsstellen kann jede ein Zertifikat für jede Domain ausstellen. DANE-EE reduziert die Vertrauensfläche auf den alleinigen Inhaber der DNS-Zone (RFC 7672, Abschnitt 1.3.2).

Vorteile von DANE-EE:

Keine Abhängigkeit von CAs: das Vertrauen basiert auf DNSSEC, nicht auf 150+ Zertifizierungsstellen
Selbstsignierte Zertifikate akzeptiert: das Zertifikat ist ein Schlüssel-Container, keine Identitätsbescheinigung
Keine Ablaufprüfung: ein abgelaufenes Zertifikat bleibt gültig, solange TLSA und DNSSEC korrekt sind
Vereinfachte Rotation: mit SPKI ändert sich der Hash nicht, solange Sie denselben Schlüssel verwenden
Reduzierte Angriffsfläche: eine einzige Vertrauensquelle statt 150+

DANE-TA (Usage 2): Wann die CA verwenden?

DANE-TA (2 0 1 oder 2 1 1) ist nützlich, wenn Sie mehrere Server betreiben, die von derselben internen CA signiert sind. Anstatt einen TLSA pro Server zu veröffentlichen, veröffentlichen Sie den Fingerprint der CA, und alle von ihr signierten Zertifikate werden akzeptiert.

Nachteil: Wenn die CA kompromittiert wird, sind alle Server kompromittiert.

PKIX-EE und PKIX-TA (Usages 1 und 0): Sonderfälle

Diese Usages kombinieren die DANE-Prüfung mit der klassischen CA-Validierung. Sie werden für SMTP selten eingesetzt, da sie Komplexität hinzufügen, ohne einen klaren Vorteil gegenüber DANE-EE zu bieten.

Entscheidungsbaum zur Wahl des passenden TLSA-Usage für Ihre Infrastruktur

DANE für E-Mail: RFC 7672

Die im Oktober 2015 veröffentlichte RFC 7672 passt DANE gezielt an den SMTP-Kontext an. Sie legt fest, wie ein sendender Server die TLSA-Einträge der MX-Server auflösen und validieren muss. Einige Besonderheiten:

STARTTLS und Port 25

Für E-Mail wird DANE auf Port 25 mit STARTTLS angewendet (nicht auf Port 465 mit implizitem TLS). Der sendende Server initiiert eine klassische SMTP-Verbindung, sendet EHLO, empfängt die Antwort 250-STARTTLS und handelt dann TLS aus. In diesem Moment vergleicht er das vorgelegte Zertifikat mit dem TLSA-Eintrag.

TLSA-Benennung für MX-Server

Der Name des TLSA-Eintrags wird aus dem MX-Hostname abgeleitet, nicht aus der E-Mail-Domain:

# E-Mail an user@captaindns.com
# MX von captaindns.com → mail.captaindns.com
# TLSA → _25._tcp.mail.captaindns.com

Wenn die Domain mehrere MX-Server hat, benötigt jeder MX seinen eigenen TLSA-Eintrag. Umgekehrt: Wenn zwei E-Mail-Domains denselben MX-Server nutzen, teilen sie denselben TLSA-Eintrag - die Zuordnung erfolgt immer über den MX-Hostname, nicht über die Empfänger-Domain (RFC 7672, Abschnitt 2.2.1).

Auflösung: von der Domain zum Zertifikat

Der vollständige Ablauf für eine E-Mail an user@captaindns.com:

captaindns.com auflösen → MX → mail.captaindns.com (DNSSEC validieren)
_25._tcp.mail.captaindns.com auflösen → TLSA (DNSSEC validieren)
mail.captaindns.com auflösen → A/AAAA (DNSSEC validieren)
TCP-Verbindung → SMTP → STARTTLS → Zertifikat gegen TLSA prüfen
Wenn das Zertifikat übereinstimmt: zustellen. Andernfalls: ablehnen.

DNSSEC auf der E-Mail-Domain und dem MX-Hostname: Für vollständigen Schutz müssen beide Zonen signiert sein. Die MX-Ziel-Domain (mail.captaindns.com) muss DNSSEC haben, damit TLSA-Einträge validiert werden. Die E-Mail-Domain (captaindns.com) sollte ebenfalls signiert sein: Ohne DNSSEC auf der E-Mail-Zone kann ein Angreifer die MX-Einträge auf einen bösartigen Server umleiten (MX-Redirect-Angriff). DANE schützt dann gegen passives Mitlesen, aber nicht gegen aktive MX-Umleitungsangriffe (RFC 7672, Abschnitt 2.2.1).

DANE in 6 Schritten deployen

1. DNSSEC für Ihre Zone aktivieren

Das ist die zwingende Voraussetzung. Kontaktieren Sie Ihren Registrar oder DNS-Hoster, um DNSSEC zu aktivieren. Prüfen Sie, ob die Vertrauenskette vollständig ist, mit einem Tool wie dig +dnssec oder dem CaptainDNS DNSSEC-Checker. Wenn Sie bei null anfangen, beschreibt unsere Schritt-für-Schritt-Anleitung zu DNSSEC nach Registrar das Vorgehen für Cloudflare, OVHcloud, GoDaddy und weitere Anbieter.

2. TLSA-Eintrag generieren

Generieren Sie Ihren Eintrag mit einem dedizierten Tool (siehe CTA am Ende des Artikels). Stellen Sie Ihr PEM-Zertifikat bereit oder lassen Sie das Tool es per STARTTLS abrufen. Wählen Sie die Kombination 3 1 1 (DANE-EE, SPKI, SHA-256).

3. Im DNS veröffentlichen

Fügen Sie den Eintrag in Ihre Zone ein:

_25._tcp.mail.captaindns.com. 3600 IN TLSA 3 1 1 a0b1c2d3e4f5678901234567890abcdef0123456789abcdef0123456789abcdef

4. Konfiguration prüfen

Nach der Propagation (TTL beachten) validieren Sie, dass alles korrekt ist: TLSA-Eintrag aufgelöst, DNSSEC gültig, Zertifikat passend. Der Inspektor am Ende des Artikels ermöglicht diese Prüfung in wenigen Sekunden.

5. TLS-RPT aktivieren

Veröffentlichen Sie einen TLS-RPT-Eintrag, um Fehlerberichte zu empfangen:

_smtp._tls.captaindns.com. 300 IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@captaindns.com"

6. Zertifikatsrotation planen

Das ist der kritische Punkt. Die meisten DANE-Störungen im Produktivbetrieb gehen auf eine Zertifikatserneuerung ohne Aktualisierung des TLSA-Eintrags zurück. Wenn Sie Ihr Zertifikat erneuern:

Mit demselben Schlüssel (Selector SPKI): Der Hash ändert sich nicht, im DNS ist nichts zu tun
Mit einem neuen Schlüssel: Veröffentlichen Sie den neuen TLSA vor dem Deployment des neuen Zertifikats. Behalten Sie beide Einträge mindestens für die doppelte TLSA-TTL bei (Beispiel: TTL von 3600 s = mindestens 2 Stunden warten)
Automatisieren Sie: Bauen Sie die TLSA-Prüfung in Ihre Erneuerungs-Pipeline ein (Certbot-Hook, CI/CD) und verankern Sie sie in einem Zertifikats-Lebenszyklus-Management, das Ablaufdaten überwacht und Erneuerungen anstößt

DANE und MTA-STS: Ergänzung, kein Wettbewerb

DANE und MTA-STS schützen beide vor Angriffen auf den SMTP-Transport, aber mit unterschiedlichen Mechanismen. Unser vollständiger MTA-STS-Leitfaden behandelt den zweiten Aspekt im Detail.

Kriterium	DANE	MTA-STS
Authentifizierungskanal	DNSSEC (signiertes DNS)	HTTPS (klassische CA)
Voraussetzung	DNSSEC auf der Zone aktiv	HTTPS-Server + gültiges Zertifikat
Selbstsignierte Zertifikate	Akzeptiert (DANE-EE)	Abgelehnt
Resistenz gegen CA-Kompromittierung	Ja	Nein
Nativer Testmodus	Nein	Ja (`mode: testing`)
Deployment-Aufwand	Mittel (DNSSEC erforderlich)	Gering (Textdatei + DNS-TXT)

Die ideale Strategie: beides

DANE und MTA-STS gleichzeitig zu deployen deckt beide Fälle ab:

Server, die DANE unterstützen, nutzen die TLSA-Prüfung
Server, die nur MTA-STS unterstützen, nutzen die HTTPS-Richtlinie
Server, die beides unterstützen, haben doppelten Schutz

DANE mit TLS-RPT überwachen

TLS-RPT (RFC 8460) ist der unverzichtbare Begleiter von DANE im Produktivbetrieb. Ohne TLS-RPT bleibt eine Zertifikatserneuerung, die die TLSA-Übereinstimmung bricht, tagelang unbemerkt.

Die täglichen JSON-Berichte enthalten die DANE-spezifischen Fehlercodes:

Fehlercode	Bedeutung	Gegenmaßnahme
`dane-required`	Kein gültiger TLSA gefunden	Veröffentlichung und DNS-Propagation prüfen
`tlsa-invalid`	TLSA-Eintrag fehlerhaft aufgebaut	Mit korrektem Format neu erzeugen (Usage, Selector, Matching Type)
`dnssec-invalid`	DNSSEC-Validierung fehlgeschlagen	RRSIG-Signaturen und DS-Kette prüfen
`dane-policy-failure`	Zertifikat != TLSA-Fingerprint	TLSA aktualisieren oder auf das vorherige Zertifikat zurückgehen

Lesen Sie unseren vollständigen TLS-RPT-Leitfaden für die Einrichtung und die Auswertung der Berichte.

Empfohlener Aktionsplan

Schritt	Aktion	Validierungskriterium
1	DNSSEC prüfen	Vollständige Vertrauenskette (DS bei der TLD, gültige RRSIG)
2	Usage `3 1 1` wählen	DANE-EE + SPKI + SHA-256
3	TLSA generieren und veröffentlichen	Eintrag wird aufgelöst und passt zum aktuellen Zertifikat
4	Mit dem Inspektor validieren	TLSA + DNSSEC + Zertifikatsübereinstimmung bestätigt
5	TLS-RPT aktivieren	Berichte gehen 24-48 h nach der Veröffentlichung ein
6	Rotation dokumentieren	Schriftliche Prozedur für Zertifikatserneuerung + TLSA-Aktualisierung

Prüfen Sie jetzt Ihre DANE-Konfiguration: Nutzen Sie unseren DANE/TLSA-Inspektor, um die DANE-Konfiguration Ihrer Domain in wenigen Sekunden zu analysieren. Sie müssen einen Eintrag erstellen? Der DANE/TLSA-Generator erzeugt einen publikationsfertigen TLSA-Eintrag. Sie können die reine Syntax eines bestehenden Eintrags zusätzlich mit dem DANE/TLSA-Syntax-Validator vor der Veröffentlichung prüfen.

FAQ

Was ist DANE und wie funktioniert es?

DANE (DNS-based Authentication of Named Entities) ist ein Internetstandard (RFC 6698), der es ermöglicht, die erwarteten TLS-Zertifikatsinformationen eines Servers im DNS zu veröffentlichen. Der sendende Server fragt den TLSA-Eintrag ab, prüft die DNSSEC-Signatur und vergleicht dann das vom Server vorgelegte Zertifikat mit dem veröffentlichten Fingerprint. Wenn das Zertifikat nicht übereinstimmt, wird die Verbindung verweigert.

Was ist der Unterschied zwischen DANE und MTA-STS?

DANE nutzt DNSSEC und TLSA-Einträge zur Authentifizierung von Zertifikaten. MTA-STS nutzt HTTPS und Zertifizierungsstellen. DANE bietet höhere Sicherheit (keine Abhängigkeit von CAs), erfordert aber DNSSEC. MTA-STS ist einfacher zu deployen. Beide Mechanismen ergänzen sich und können auf derselben Domain koexistieren.

Ist DNSSEC für DANE zwingend erforderlich?

Ja, DNSSEC ist eine zwingende Voraussetzung. Ohne signierte Zone sind TLSA-Einträge nicht vertrauenswürdig, da ein Angreifer sie fälschen könnte. RFC-7672-konforme Sendeserver ignorieren TLSA-Einträge, deren DNSSEC-Kette nicht gültig ist.

Welchen TLSA-Usage sollte man für E-Mail wählen?

RFC 7672 empfiehlt DANE-EE (Usage 3) mit SPKI (Selector 1) und SHA-256 (Matching Type 1), also die Kombination 3 1 1. Das ist der Goldstandard für SMTP: keine Abhängigkeit von CAs, vereinfachte Rotation mit SPKI und maximale Kompatibilität.

Funktioniert DANE mit Let's Encrypt?

Ja, DANE funktioniert mit Let's Encrypt. Mit DANE-EE und dem Selector SPKI (3 1 1) ändert sich der Hash nicht, solange Sie das Zertifikat mit demselben privaten Schlüssel erneuern. Let's Encrypt erneuert alle 90 Tage, aber wenn Sie den Schlüssel beibehalten, bleibt der TLSA gültig. Wenn Sie den Schlüssel neu generieren, veröffentlichen Sie den neuen TLSA vor dem Deployment des Zertifikats.

Welche E-Mail-Anbieter unterstützen DANE?

Zu den wichtigsten Anbietern, die DANE im Versand (ausgehende DANE-Prüfung) unterstützen, gehören Postfix, Gmail (teilweise Prüfung) und mehrere europäische ISPs. Microsoft hat DANE-Unterstützung für Exchange Online angekündigt. Beim Empfang ist jeder Server mit DNSSEC und veröffentlichtem TLSA kompatibel. Die Verbreitung ist in Europa (Deutschland, Niederlande) stärker als in den USA.

Wie überwacht man DANE-Fehler im Produktivbetrieb?

Aktivieren Sie TLS-RPT (RFC 8460), indem Sie einen DNS-Eintrag _smtp._tls mit einer Empfangsadresse veröffentlichen. Sendende Server schicken dann tägliche JSON-Berichte mit Details zu DANE-Fehlern: nicht übereinstimmendes Zertifikat, ungültiges DNSSEC, fehlender TLSA. Ohne TLS-RPT bleiben Fehler unbemerkt.

Glossar

DANE: DNS-based Authentication of Named Entities. In RFC 6698 definiertes Protokoll, das TLS-Zertifikatsinformationen im DNS veröffentlicht und Servern die Zertifikatsüberprüfung ohne Abhängigkeit von Zertifizierungsstellen ermöglicht.
TLSA: DNS-Eintragstyp, der von DANE verwendet wird, um Zertifikatszuordnungsdaten zu speichern (Usage, Selector, Matching Type und Zertifikats-Hash).
DNSSEC: DNS Security Extensions. Fügt DNS-Einträgen kryptographische Signaturen hinzu, die die Verifizierung ermöglichen, dass Antworten nicht manipuliert wurden. Zwingende Voraussetzung für DANE.
DANE-EE: DANE-Usage-Typ 3. Prüft das End-Entity-Zertifikat (Server-Zertifikat) direkt, ohne CA-Ketten-Validierung.
SPKI: SubjectPublicKeyInfo. Der öffentliche Schlüsselteil eines Zertifikats, verwendet als Selector 1 in TLSA-Einträgen. Bevorzugt, da er die Zertifikatserneuerung mit demselben Schlüsselpaar übersteht.
MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Erzwingt TLS-Verschlüsselung für den E-Mail-Empfang über eine HTTPS-Richtlinie.
TLS-RPT: SMTP TLS Reporting (RFC 8460). Mechanismus für den Empfang täglicher Berichte über TLS-Aushandlungserfolge und -fehler, einschließlich DANE-spezifischer Fehler.