DANE/TLSA-Eintrag-Prüfer

Fragt die TLSA-Einträge der Mailserver (MX-Hosts) einer Domain bei mehreren öffentlichen DNS-Resolvern ab und prüft, ob DANE-Zertifikatspinning konfiguriert ist.

Zuletzt aktualisiert: 2026-09-20

Zertifikatsprüfung mittels DANE (TLSA-Einträgen) diagnostizieren

DANE ist jene Vereinbarung, bei der das von einem Postserver vorgelegte Zertifikat **gegen einen im DNS hinterlegten TLSA-Eintrag geprüft wird.** Dieses Werkzeug fragt die von den MX-Rechnern einer Domäne veröffentlichten TLSA-Einträge bei mehreren öffentlichen Auflösern ab und meldet, ob sie eingerichtet sind.

**Die Voraussetzung, die hier niemals fehlen darf, lautet: DANE steht allein auf DNSSEC.** Was verbürgt, dass ein TLSA-Eintrag nicht verändert wurde, ist DNSSEC selbst, weshalb **TLSA-Einträge auf einer Domäne ohne eingeschaltetes DNSSEC überhaupt keinen Schutz bedeuten.** Das ist der wesentliche Unterschied zu MTA-STS: Während MTA-STS sein Vertrauen auf Webzertifikate setzt, **setzt DANE es auf DNSSEC.** Der zweite Punkt, der im Betrieb Umsicht verlangt, ist die Erneuerung von Zertifikaten, denn **wer das Zertifikat eines Servers austauscht, ohne zugleich den TLSA-Eintrag zu aktualisieren, lässt die Prüfung scheitern und bringt die Post zum Erliegen.** Die nötige Reihenfolge lautet: zuerst den neuen Fingerabdruck hinzufügen, umschalten und erst danach den alten entfernen.

So gehen Sie vor

Geben Sie die Domäne ein Nennen Sie allein die Domäne, in der Form `example.com`.
Sehen Sie das Ergebnis je MX-Rechner an **TLSA-Einträge liegen bei jedem MX-Rechner unter `_25._tcp.rechnername`.**
Bestätigen Sie, ob DNSSEC vorhanden ist **Ohne DNSSEC gewährt ein TLSA-Eintrag keinerlei Schutz.**
Planen Sie den Ablauf der Zertifikatserneuerung **Lassen Sie alten und neuen Fingerabdruck eine Weile nebeneinander bestehen, ehe Sie umschalten.**

Tipps für die Nutzung

TLSA-Einträge liegen nicht unter dem gewöhnlichen Domainnamen, sondern unter einem speziellen Namen, `_25._tcp.{MX-Host}`. Deshalb findet eine Abfrage von TLSA direkt auf der Domain nie etwas.
„DANE nicht konfiguriert" ist kein Fehler. DANE ist eine zusätzliche Schutzebene für die E-Mail-Verschlüsselung, und die meisten Mailserver nutzen sie noch nicht.
DANE ist nur vertrauenswürdig, wenn der TLSA-Eintrag der Domain selbst durch die DNSSEC-Signaturkette geschützt ist. Auch wenn ein TLSA-Eintrag gefunden wird, sollten Sie zusätzlich das Schwestertool „DNSSEC-Prüfer" nutzen, um zu bestätigen, dass DNSSEC für die Domain aktiviert ist.
Hat eine Domain mehrere MX-Hosts, prüft dieses Tool bis zu 3 Hosts, beginnend mit der niedrigsten Präferenznummer (höchste Priorität).
Stimmen die Resolver nicht überein, wurde der Eintrag möglicherweise gerade aktualisiert und die Caches sind noch nicht synchron. Warten Sie etwas und prüfen Sie erneut.

Wofür Sie es nutzen können

Um die eigenen Postserver zu prüfen

Sie finden die Abweichung, bei der ein TLSA-Eintrag für gesetzt gehalten wurde, beim MX-Rechner aber fehlt.

Um vor einer Zertifikatserneuerung zu prüfen

**Die falsche Reihenfolge bringt die Post zum Erliegen, weshalb sich eine vorherige Prüfung reichlich lohnt.**

Um DANE gegen MTA-STS abzuwägen

**Wählen Sie danach, wem Sie lieber vertrauen — DNSSEC oder Webzertifikaten; beide lassen sich auch gemeinsam einführen.**

Um zu erfahren, wie weit ein Geschäftspartner ist

Sie sehen, ob er DANE überhaupt verwendet.

Begriffe zu DANE

TLSA-Eintrag: **Der Eintrag, der den Fingerabdruck eines Zertifikats oder öffentlichen Schlüssels ins DNS stellt.** Er liegt unter einem Namen wie `_25._tcp.mail.example.com`.
DNSSEC: **Die Voraussetzung von DANE.** Ohne es könnte der TLSA-Eintrag selbst verändert werden, und kein Schutz besteht.
Verwendungsfeld: Die erste Zahl eines TLSA-Eintrags, die angibt, ob er sich auf das Zertifikat selbst oder auf eine Zertifizierungsstelle bezieht.
DANE-EE: Das Vorgehen, den Fingerabdruck des Serverzertifikats selbst einzutragen. **Es erlaubt die Prüfung ohne Abhängigkeit von einer Stelle.**
Wechsel: Die Arbeit, Zertifikat und TLSA-Eintrag auszutauschen. **Fügen Sie zuerst den neuen Fingerabdruck hinzu und entfernen Sie den alten danach.**
Gelegentliches TLS: Das ältere, freiwillige Vorgehen, dort zu verschlüsseln, wo die Gegenseite es unterstützt. **DANE und MTA-STS erheben dies zur Pflicht.**

Häufig gestellte Fragen

„DANE nicht konfiguriert" ist für sich genommen nicht gefährlich – die überwiegende Mehrheit der Mailserver läuft nach wie vor ohne DANE. Dennoch lohnt es sich, die Aktivierung als Schutz vor STARTTLS-Man-in-the-Middle-Angriffen in Betracht zu ziehen, wenn die Möglichkeit besteht.

Beide zielen darauf ab, TLS-Verschlüsselung beim Mailtransport zu erzwingen, stützen ihr Vertrauen aber unterschiedlich: MTA-STS verlässt sich auf die Validierungskette einer Zertifizierungsstelle, DANE auf die DNSSEC-Signaturkette. Ist DNSSEC bereits aktiviert, ist DANE die naheliegende Wahl; andernfalls ist MTA-STS der praktischere Einstieg. Beide lassen sich auch kombinieren.

Usage legt das Validierungsmodell fest (ob weiterhin eine CA-Validierung nötig ist oder das Zertifikat selbst direkt gepinnt wird), Selector legt fest, ob das gesamte Zertifikat oder nur der öffentliche Schlüssel gehasht wird, und Matching Type legt den Hash-Algorithmus fest (z. B. SHA-256 oder SHA-512). Unterschiedliche Kombinationen passen zu unterschiedlichen Betriebsmustern.

Für vollständigen Schutz sollte jeder MX-Host, der als Zustellziel gewählt werden könnte, einen TLSA-Eintrag besitzen. Ist er nur bei einem Teil der Hosts vorhanden, bleibt E-Mail, die an einen Host ohne Eintrag zugestellt wird, ungeschützt.

Dieses Tool prüft nur einen oberflächlichen Zustand: ob ein TLSA-Eintrag veröffentlicht ist. Es prüft nicht, ob die Zertifikatszuordnungsdaten tatsächlich mit dem echten Serverzertifikat übereinstimmen. Für eine strenge Prüfung sollten Sie zusätzlich ein spezialisiertes Tool verwenden.

Übrigens – E-Mail-Verschlüsselung mit Zertifikaten statt nur „nicht abhören"

Die E-Mail-Verschlüsselung über SMTP (STARTTLS) hat seit Langem eine Schwachstelle. Die meisten Mailserver nutzen opportunistisches TLS – fällt die Gegenstelle nicht auf Verschlüsselung zurück, wird einfach im Klartext gesendet. Das öffnete Tür und Tor für „STRIPTLS-Angriffe", bei denen ein Man-in-the-Middle-Angreifer den STARTTLS-Befehl unbemerkt entfernt, sodass die Verbindung auf Klartext herabgestuft wird, ohne dass es einer der beiden Seiten auffällt.

DANE (DNS-based Authentication of Named Entities, RFC 6698) begegnet diesem Problem, indem TLSA-Einträge im DNS veröffentlicht werden. Indem das Zertifikat eines Mailservers (oder der Hash seines öffentlichen Schlüssels) im Voraus im DNS verankert wird, kann der sendende Server prüfen, ob der Host, mit dem er sich verbindet, tatsächlich das erwartete Zertifikat vorweist. Anders als bei der üblichen SSL/TLS-Zertifikatsprüfung verlässt sich DANE überhaupt nicht auf die Vertrauenskette einer Zertifizierungsstelle – vertraut wird ausschließlich der DNSSEC-Signaturkette.

Die Schwäche von DANE besteht darin, dass es nur funktioniert, wenn die Domain selbst mit DNSSEC signiert ist. Ohne DNSSEC lässt sich nicht ausschließen, dass der TLSA-Eintrag selbst auf dem Transportweg manipuliert wird, wodurch die Garantie von DANE bedeutungslos wird. Deshalb folgt die Verbreitung von DANE eng der von DNSSEC und hat sich bei einigen europäischen Registries (etwa .nl und .cz) bereits früher durchgesetzt.

Alle Wissenstexte ansehen