Zum Hauptinhalt springen

Neu

Testen Sie die Zustellbarkeit Ihrer E-Mails

Senden Sie eine Test-E-Mail und erhalten Sie in wenigen Sekunden eine vollständige Diagnose Ihrer SPF-, DKIM- und DMARC-Authentifizierung.

  • Echter Versandtest
  • Sofortige Diagnose
  • Ohne Registrierung

DANE TLSA Validator

Validiere deine TLSA Records vor der DNS-Veröffentlichung

Prüfe die Syntax deines DANE TLSA Records vor der Veröffentlichung. Unser Validator kontrolliert die Felder Certificate Usage, Selector und Matching Type, überprüft das Format der Hexadezimaldaten und erkennt ungültige Kombinationen.

Format: Usage Selector Matching-Type Daten (z. B. 3 1 1 gefolgt vom Hex-Hash).

RFC 6698-Konformität

Validiert deinen Record gemäß der DANE-Spezifikation. Erkennt Werte außerhalb des Bereichs, ungültige Kombinationen und fehlerhafte Syntax.

DNSSEC-Prüfung

Weist darauf hin, dass DANE DNSSEC benötigt, um zu funktionieren. Ohne DNSSEC-Signatur werden TLSA Records von den Servern ignoriert.

Sofortiges Feedback

Echtzeit-Validierung während der Eingabe. Kein Warten, keine Formularübermittlung. Sofortige Ergebnisse mit Diagnosecodes.

Detaillierte Diagnose

Klare Erklärungen für jedes erkannte Problem. Jeder Fehler enthält das betroffene Feld, den ungültigen Wert und die Korrekturanleitung.

E-Mail-TLS-Sicherheit

DANE schützt SMTP-Verbindungen vor MITM-Angriffen. Validiere deine TLSA Records, um die Sicherheit des E-Mail-Transports zu gewährleisten.

Was ist DANE TLSA und warum die Syntax validieren?

Ein einziger Tippfehler in deinem TLSA Record kann deine gesamte E-Mail-Sicherheit aushebeln. DANE (DNS-based Authentication of Named Entities) bindet TLS-Zertifikate über DNSSEC-signierte TLSA Records an DNS-Namen. Definiert in RFC 6698, erweitert durch RFC 7671. DANE eliminiert die Abhängigkeit von Zertifizierungsstellen bei der Mailserver-Identifikation.

Warum du die Syntax vor der Veröffentlichung prüfen musst:

  • Ungültige TLSA Records werden stillschweigend ignoriert, du erfährst es nicht
  • Ein falscher Usage-Wert schwächt die Sicherheit, statt sie zu stärken
  • Fehlerhafte Hexadezimaldaten machen den gesamten Record unbrauchbar
  • Falsche Feldkombinationen führen zu Zustellfehlern bei DANE-fähigen Absendern

Füge deinen Record oben in den Validator ein und prüfe ihn in Sekunden.


TLSA Record-Format erklärt

Jeder TLSA Record besteht aus vier Feldern. Verstehst du diese Felder, erkennst du Fehler sofort.

Grundstruktur

_25._tcp.mail.captaindns.com. IN TLSA 3 1 1 2bb183af...
FeldWerteBeschreibung
Certificate Usage0-3Art der Zertifikatseinschränkung
Selector0-1Zu matchender Teil des Zertifikats
Matching Type0-2Vergleichsmethode
Certificate DataHexZertifikatsdaten oder Hash

Certificate Usage (Feld 1)

WertNameBeschreibung
0PKIX-TACA-Einschränkung: Zertifikat muss von dieser CA signiert UND PKIX-validiert sein
1PKIX-EEZertifikatseinschränkung: exakter Match des Serverzertifikats + PKIX-Validierung
2DANE-TATrust Anchor: akzeptiert jedes von dieser CA signierte Zertifikat
3DANE-EEDomain-Zertifikat: exakter Match des Serverzertifikats, keine PKIX-Validierung

Empfehlung: Über 90 % der DANE-Deployments im SMTP-Bereich nutzen DANE-EE (3). Keine PKIX-Validierung nötig, maximale Kontrolle.

Selector (Feld 2)

WertNameBeschreibung
0CertVollständiges Zertifikat (DER)
1SPKINur öffentlicher Schlüssel (Subject Public Key Info)

Empfehlung: Wähle SPKI (1). Der Hash bleibt nach der Zertifikatserneuerung gültig, solange du denselben Schlüssel verwendest.

Matching Type (Feld 3)

WertNameHex-Länge
0FullVariabel (vollständiges Zertifikat)
1SHA-25664 Zeichen
2SHA-512128 Zeichen

Empfehlung: SHA-256 (1) bietet den besten Kompromiss aus Größe und Sicherheit. SHA-512 bringt keinen messbaren Sicherheitsvorteil, verdoppelt aber die Record-Größe.

Prüfe jetzt die Felder deines Records mit dem Validator oben.


Häufige Syntaxfehler

Diese Fehler erkennt unser Validator automatisch. Hier lernst du, sie selbst zu verstehen und zu beheben.

Usage-Wert außerhalb des Bereichs

# Falsch – Usage 4 existiert nicht
3 1 1 2bb183af... → Usage muss 0-3 sein

# Korrekt – DANE-EE (3)
3 1 1 2bb183af...

Ungültige Hex-Daten

# Falsch – Nicht-Hex-Zeichen (G, Z)
3 1 1 2bg183zf...

# Korrekt – nur 0-9, a-f
3 1 1 2bb183af...

Falsche Hash-Länge

# Falsch – SHA-256 muss 64 Hex-Zeichen haben
3 1 1 2bb183

# Korrekt – vollständiger SHA-256-Hash (64 Zeichen)
3 1 1 2bb183af2e2b295b444c1fd4072f2b59a8c1c9abf7f3f1e9b0d4c7e8f1a2b3c4

Inkonsistente Usage/Selector-Kombination

# Achtung – DANE-EE (3) + Cert (0) ändert sich bei jeder Erneuerung
3 0 1 ...

# Empfohlen – DANE-EE (3) + SPKI (1) übersteht Erneuerungen
3 1 1 ...

DANE-Konfiguration für SMTP

Fünf Schritte, um DANE produktionsreif zu deployen. Überspringe keinen - jeder ist kritisch.

Schritt 1: DNSSEC aktivieren

DANE erfordert zwingend DNSSEC auf deiner Domain. Ohne DNSSEC werden TLSA Records von jedem MTA ignoriert, egal wie korrekt die Syntax ist.

Schritt 2: TLSA Record generieren

Nutze unseren DANE TLSA Generator, um einen Record mit den richtigen Parametern zu erstellen.

Schritt 3: Syntax validieren

Füge den Record in diesen Validator ein, um das Format vor der Veröffentlichung zu prüfen.

Schritt 4: Im DNS veröffentlichen

Füge den TLSA Record am richtigen DNS-Ort hinzu: _25._tcp.mail.captaindns.com.

Schritt 5: Deployment überprüfen

Nutze unseren DANE TLSA Checker, um zu bestätigen, dass der Record online und korrekt DNSSEC-signiert ist.


DANE vs. MTA-STS: zwei Ansätze für TLS-Sicherheit

Welcher Ansatz passt zu deiner Infrastruktur? Die Antwort: im Idealfall beide.

KriteriumDANEMTA-STS
MechanismusDNSSEC + TLSA RecordsHTTPS + Text-Policy
AbhängigkeitDNSSEC erforderlichHTTPS erforderlich
VertrauensniveauKryptografisch (DNSSEC)PKI (HTTPS)
Deployment-KomplexitätKomplex (DNSSEC)Einfacher
VerbreitungBehörden, InstitutionenBreiter

Beide ergänzen sich. MTA-STS funktioniert ohne DNSSEC. DANE bietet stärkere kryptografische Sicherheit. Deploye beide, wenn möglich: sie schützen vor unterschiedlichen Angriffsszenarien.


FAQ - Häufig gestellte Fragen

F: Was ist ein DANE TLSA Record?

A: Ein DANE TLSA Record ist ein DNS-Eintrag, der ein TLS-Zertifikat über DNSSEC mit einem Domainnamen verknüpft. Er ermöglicht die Zertifikatsverifizierung ohne ausschließliche Abhängigkeit von Zertifizierungsstellen und fügt SMTP-Verbindungen eine zusätzliche Sicherheitsebene hinzu.


F: Was prüft der DANE TLSA Validator?

A: Unser Validator analysiert die TLSA-Syntax: das Feld Certificate Usage (0-3), den Selector (0-1), den Matching Type (0-2) und das Format der Zertifikats-Assoziationsdaten. Er erkennt ungültige Kombinationen und fehlerhafte Hexadezimaldaten.


F: Welche Certificate Usage-Typen gibt es bei TLSA?

A: Es gibt vier Usage-Typen: PKIX-TA (0) CA-Einschränkung, PKIX-EE (1) Dienstzertifikats-Einschränkung, DANE-TA (2) Trust-Anchor-Assertion, DANE-EE (3) domainausgestelltes Zertifikat. DANE-EE (3) ist für SMTP am gebräuchlichsten.


F: Was ist der Unterschied zwischen DANE-TA und DANE-EE?

A: DANE-TA (Usage 2) pinnt eine Zertifizierungsstelle, was Zertifikatsrotation ohne DNS-Aktualisierung ermöglicht. DANE-EE (Usage 3) pinnt das spezifische Serverzertifikat, bietet stärkere Sicherheit, erfordert aber eine DNS-Aktualisierung bei der Erneuerung.


F: Benötigt DANE DNSSEC?

A: Ja, unbedingt. Ohne DNSSEC können TLSA Records nicht authentifiziert werden. Das DANE-Sicherheitsmodell basiert vollständig auf DNSSEC, um die Integrität der DNS-Antworten zu garantieren.


F: Kann ich DANE mit Microsoft 365 oder Google Workspace verwenden?

A: Microsoft 365 unterstützt DANE mit DNSSEC für eingehende E-Mails (Exchange Online). Google Workspace unterstützt DANE für den Empfang noch nicht. Beide Plattformen unterstützen die DANE-Validierung beim Versand an kompatible Empfänger.


Ergänzende Tools

ToolNutzen
DANE TLSA CheckerDeployte TLSA Records im DNS überprüfen
DANE TLSA GeneratorTLSA Record aus einem Zertifikat erstellen
MTA-STS-InspektorMTA-STS-Policy prüfen (alternative TLS-Sicherheit)
TLS-RPT-InspektorTLS-Fehler über Berichte überwachen
E-Mail-Domain-AuditVollständiges E-Mail-Authentifizierungs-Audit

Nützliche Ressourcen