DANE TLSA Checker

Was prüft dieser DANE TLSA-Inspektor?

Du hast DANE konfiguriert, aber funktioniert es wirklich? Unser Tool führt in Sekunden eine vollständige Analyse durch:

1. MX-Auflösung: Identifiziert die Mailserver deiner Domain
2. TLSA-Suche: Fragt _25._tcp.hostname nach TLSA Records ab
3. DNSSEC-Prüfung: Kontrolliert, ob die Signaturkette lückenlos ist
4. Syntaxvalidierung: Prüft die Konformität mit RFC 6698 und RFC 7672
5. Zertifikatsabgleich: Vergleicht die TLSA-Daten mit dem aktuellen Serverzertifikat

Gib oben deine Domain ein und erhalte in Sekunden ein vollständiges Ergebnis.

DANE TLSA Records verstehen

Ein häufiger Fehler: der TLSA Record wird am falschen DNS-Ort veröffentlicht. Hier lernst du die korrekte Platzierung.

DNS-Ort

TLSA Records werden an einem spezifischen Ort basierend auf dem Mailserver veröffentlicht:

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 2bb183af2e2b295b...

Wichtig: Der Hostname muss der des MX-Servers sein, nicht der Domain. Wenn captaindns.com den MX mail.captaindns.com hat, gehört der TLSA zu _25._tcp.mail.captaindns.com.

Aufbau des Records

Empfohlene Konfiguration für SMTP

Die Kombination 3 1 1 gilt als Best Practice gemäß RFC 7672 und wird von über 90 % der DANE-fähigen Mailserver verwendet:

3 1 1 <sha256-hash>

• Usage 3 (DANE-EE): Keine PKIX-Validierung nötig, maximale Kontrolle
• Selector 1 (SPKI): Übersteht Erneuerungen mit demselben Schlüssel
• Matching Type 1 (SHA-256): 64 Hex-Zeichen, kompakt und sicher

Die Rolle von DNSSEC

DANE funktioniert nicht ohne DNSSEC. Ohne signierte DNS-Antworten kann kein MTA deinen TLSA Records vertrauen.

Vertrauenskette

DNS-Root (.) → TLD (.com) → Domain (captaindns.com) → TLSA Record
   DNSSEC        DNSSEC          DNSSEC                 Signiert

Jede Ebene der DNS-Hierarchie muss signiert sein. Fehlt ein einziges Glied, gelten alle TLSA Records als nicht authentifiziert und werden stillschweigend ignoriert.

Was unser Tool prüft

Häufig erkannte Probleme

Unser Checker erkennt diese vier häufigsten DANE-Fehler automatisch. Hier erfährst du, was sie bedeuten und wie du sie behebst.

Keine TLSA Records gefunden

Ursache: Die Domain hat DANE nicht konfiguriert. Auswirkung: Kein DANE-Schutz für eingehende E-Mails. Sendende MTAs verwenden nur opportunistisches TLS. Lösung: Generiere einen DANE TLSA Record und veröffentliche ihn im DNS.

DNSSEC fehlt

Ursache: Die Domain ist nicht DNSSEC-signiert. Auswirkung: TLSA Records werden ignoriert, auch wenn sie syntaktisch korrekt sind. Lösung: Aktiviere DNSSEC bei deinem Registrar. Dann signiere die Zone bei deinem DNS-Hoster. Erst danach werden TLSA Records wirksam.

Zertifikats-Hash desynchronisiert

Ursache: Das TLS-Zertifikat wurde erneuert, ohne den TLSA Record zu aktualisieren. Auswirkung: DANE-fähige MTAs verweigern die Verbindung oder fallen auf opportunistisches TLS zurück. Behörden und Banken, die DANE erzwingen, können keine E-Mails mehr zustellen. Lösung: Aktualisiere den TLSA-Hash sofort. Langfristig: verwende DANE-TA (Usage 2) oder SPKI-Selector (1) mit Schlüsselwiederverwendung (--reuse-key).

TLSA am falschen Ort

Ursache: Record für die Domain statt für den MX-Server veröffentlicht. Auswirkung: Sendende Server finden den Record nicht, als wäre DANE nicht konfiguriert. Lösung: Veröffentliche unter _25._tcp.<mx-hostname>, nicht unter _25._tcp.<domain>. Prüfe den MX deiner Domain im Ergebnis oben.

Strategie zur Zertifikatsrotation mit DANE

Die Zertifikatsrotation ist die häufigste Ursache für DANE-Ausfälle. Wähle eine der drei Strategien, bevor du DANE deployst.

Strategie 1: DANE-TA (empfohlen für Let's Encrypt)

Pinne das CA-Zertifikat statt des Serverzertifikats:

2 0 1 <sha256-des-ca-zertifikats>

Vorteil: Der TLSA bleibt gültig, solange dieselbe CA deine Zertifikate signiert. Nachteil: Weniger strikt als direktes Pinning.

Strategie 2: DANE-EE mit Schlüsselwiederverwendung

Behalte denselben privaten Schlüssel zwischen den Erneuerungen:

3 1 1 <sha256-des-public-key>

Vorteil: Starkes Pinning + übersteht Erneuerungen. Nachteil: Erfordert die Konfiguration der Schlüsselwiederverwendung (z. B. --reuse-key in Certbot).

Strategie 3: Doppelter Record (Rollover)

Veröffentliche beide TLSA vor der Rotation:

_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <hash-aktuelles-zertifikat>
_25._tcp.mail.captaindns.com.  IN  TLSA  3 1 1 <hash-zukünftiges-zertifikat>

Nach der Rotation den alten entfernen. Plane mindestens 2× TTL Wartezeit zwischen Veröffentlichung und Rotation.

DANE und SMTP: Schutz von E-Mails während der Übertragung

DANE verwandelt opportunistisches TLS in authentifiziertes TLS. Der Unterschied: kein MTA kann sich mehr als dein Mailserver ausgeben.

Wie DANE für SMTP funktioniert

1. Der sendende Server löst den MX von captaindns.com auf
2. Er sucht die TLSA Records unter _25._tcp.<mx-hostname>
3. Er prüft, ob die TLSA-Antwort DNSSEC-signiert ist
4. Er verbindet sich per STARTTLS und vergleicht das Zertifikat mit den TLSA-Daten
5. Übereinstimmung → sichere, authentifizierte Verbindung
6. Keine Übereinstimmung → Zustellung verweigert (kein Fallback auf Klartext)

Unterschied zu opportunistischem TLS

Prüfe jetzt deine Domain mit dem Checker oben, um zu sehen, ob dein DANE-Setup aktiv schützt.

FAQ - Häufig gestellte Fragen

F: Was prüft der DANE TLSA Checker?

A: Unser Checker führt einen DNS-Lookup der TLSA Records deiner Domain durch, validiert die Syntax, prüft den DNSSEC-Signaturstatus, kontrolliert die Übereinstimmung mit dem Mailserver-Zertifikat und meldet Konfigurationsprobleme.

F: Warum schlägt mein DANE TLSA Check fehl?

A: Häufige Ursachen: DNSSEC fehlt auf der Domain, TLSA Records nicht am richtigen Ort veröffentlicht (_25._tcp.mail.captaindns.com), Zertifikats-Hash nach Erneuerung desynchronisiert oder falsche Usage/Selector/Matching Type-Kombination.

F: Wie lautet der richtige DNS-Name für SMTP-TLSA Records?

A: SMTP-TLSA Records müssen unter _port._protokoll.hostname veröffentlicht werden, typischerweise _25._tcp.mail.captaindns.com. Der Hostname muss der des MX-Zielservers sein, nicht der Domain selbst.

F: Wie schützt DANE E-Mails während der Übertragung?

A: DANE verhindert Man-in-the-Middle-Angriffe auf SMTP-Verbindungen, indem der sendende Server das TLS-Zertifikat über DNS/DNSSEC verifizieren kann, anstatt sich ausschließlich auf Zertifizierungsstellen zu verlassen.

F: Wie oft sollte ich meine DANE TLSA Records prüfen?

A: Prüfe nach jeder TLS-Zertifikatserneuerung, nach jeder DNS-Änderung und monatlich. Das Ablaufen des Zertifikats ist die häufigste Ursache für DANE-Fehler.

F: Funktioniert DANE mit Let's Encrypt-Zertifikaten?

A: Ja, aber plane die 90-Tage-Erneuerungen ein. DANE-TA (Usage 2) mit dem CA-Zertifikat von Let's Encrypt ist einfacher. DANE-EE (Usage 3) mit Schlüsselwiederverwendung (--reuse-key in Certbot) funktioniert ebenfalls.

Ergänzende Tools

Nützliche Ressourcen

• RFC 6698 - DANE TLSA (Originalspezifikation)
• RFC 7671 - Updates to DANE (betriebliche Aktualisierungen)
• RFC 7672 - SMTP Security via DANE (DANE für SMTP)
• Microsoft - DANE with DNSSEC (Exchange Online-Anleitung)
• Let's Encrypt - Using DANE (DANE-Tipps mit LE)