Es ist ein typisches Szenario: Eine Domäne hat DANE aktiviert, und plötzlich bleiben E-Mails an einen bestimmten Partner in der Queue hängen. In den Protokollen taucht eine Meldung wie TLSA validation failed, no usable TLSA records oder bei Microsoft 365 der Status 4.7.323 tlsa-invalid auf. Das ist kein Zufall und auch kein Bug: DANE arbeitet wie vorgesehen und verweigert die Zustellung, weil etwas an der Zertifikatsbindung nicht stimmt.
Dieser Guide setzt die Grundlagen aus dem Beitrag Was ist DANE voraus und konzentriert sich auf die Praxis: die vier häufigsten Ursachen, eine Diagnose-Checkliste und die Schlüsselrollierung, die solche Fehler von vornherein vermeidet.
Warum ein DANE-Fehler die Zustellung stoppt
TL;DR: Schlägt die DANE-Validierung fehl, passt das vorgelegte Zertifikat nicht zum veröffentlichten TLSA-Record oder die Vertrauenskette über DNSSEC ist gestört. Fast immer steckt eine von vier Ursachen dahinter: ein DNSSEC- oder Signaturproblem, ein fehlender oder falsch platzierter TLSA-Record, ein nach einer Erneuerung nicht mehr passendes Zertifikat oder eine Mailserver-Fehlkonfiguration. Weil DANE eine Abweichung im Zweifel als Angriff wertet, bricht die Zustellung ab, statt unverschlüsselt fortzufahren.
Der Grundgedanke von DANE ist, dass eine Abweichung zwischen erwartetem und tatsächlichem Zertifikat ein Warnsignal ist. Genau deshalb fällt DANE bei einem Fehler nicht auf eine unverschlüsselte Zustellung zurück, sondern verweigert sie. Das ist sicherheitstechnisch richtig, macht aber jede Fehlkonfiguration auf Ihrer Seite sofort sichtbar, in Form nicht zugestellter E-Mails. Die gute Nachricht: Die Ursachen sind überschaubar und gut eingrenzbar.
Die vier häufigsten Ursachen im Überblick
Die allermeisten DANE-Fehler lassen sich einer dieser vier Kategorien zuordnen. Diese Tabelle hilft, vom Symptom schnell zur Ursache und zur Lösung zu kommen:
| Ursache | Typisches Symptom | Lösung |
|---|---|---|
| DNSSEC gestört oder Signatur abgelaufen | Record gilt als nicht validierbar, wird wie fehlend behandelt | DNSSEC-Kette und Signaturgültigkeit prüfen, abgelaufene Signaturen erneuern |
| TLSA-Record fehlt oder steht am falschen Namen | no usable TLSA records, record not found, 5.7.323 tlsa-invalid | Record unter _25._tcp des MX-Hostnamens veröffentlichen, überzähligen Record an der Domäne entfernen |
| Zertifikat erneuert, passt nicht mehr | TLSA validation failed, 4.7.323 tlsa-invalid | TLSA-Record auf das neue Zertifikat aktualisieren, übergangsweise beide Werte |
| Mailserver präsentiert falsches Zertifikat | Mismatch trotz vorhandenem Record | Konfiguration des Mailservers prüfen, korrektes Zertifikat ausliefern |
DNSSEC ist die Vertrauensbasis
Da DANE ohne gültiges DNSSEC nicht funktioniert, ist eine gestörte oder abgelaufene Signatur eine der heimtückischsten Ursachen. Der TLSA-Record kann technisch korrekt sein, wird aber von einem validierenden Resolver verworfen, sobald die Signaturkette nicht aufgeht. Für den sendenden Server sieht das so aus, als gäbe es keinen verwertbaren Record. Abgelaufene Signaturen entstehen oft unbemerkt, wenn eine automatische Neusignierung der Zone aussetzt.
Der Klassiker: das erneuerte Zertifikat
Steht der TLSA-Record am richtigen Namen, ist ein erneuertes Zertifikat die häufigste Ursache im laufenden Betrieb. Wird der Schlüssel getauscht, ohne den TLSA-Record rechtzeitig anzupassen, präsentiert der Mailserver nach der Erneuerung ein Zertifikat, das nicht mehr zum hinterlegten Fingerabdruck passt. Genau das meldet Exchange Online als 4.7.323 tlsa-invalid. Weil es sich um einen vorübergehenden Fehler handelt, verbleiben die Mails zunächst in der Queue und werden später erneut versucht, was etwas Zeit für die Korrektur lässt.
TLSA am falschen Namen: der Record an der eigenen Domäne
Die zweite Zeile der Tabelle verdient einen eigenen Blick, denn sie ist der Fall, der am häufigsten dahintersteckt, wenn eine Zustellung plötzlich abgewiesen wird, ohne dass jemand ein Zertifikat angefasst hat. Das Symptom ist eine Abweisung mit 550 5.7.323 tlsa-invalid, bei einem vorübergehenden Fehler mit 451 4.7.323, obwohl der zuständige Mailserver ein gültiges und unverändertes Zertifikat ausliefert.
Die Ursache steckt im Namen des Records: Er steht unter _25._tcp.<ihre-domain> statt unter _25._tcp.<mx-hostname>. Meist ist er ein Überbleibsel eines früher selbst betriebenen Mailservers und blieb nach dem Umzug zu einem Dienstleister in der Zone stehen. Solange die Zone nicht signiert war, hat ihn kein Sender ausgewertet. Mit der DNSSEC-Signierung wird er schlagartig wirksam: Sender, die die Empfängerdomäne als Basis nehmen, vergleichen den alten Fingerabdruck mit dem Zertifikat des heutigen MX, finden keine Übereinstimmung und stellen nicht mehr zu. Nach RFC 7672 ist die Basis für den TLSA-Namen der Hostname aus dem MX-Eintrag, und die Domäne selbst gilt nur dann, wenn sie überhaupt keinen MX-Eintrag hat.
Die Lösung ist unspektakulär: den Record an der Empfängerdomäne entfernen. Am MX-Hostnamen wird nichts angelegt und nichts geändert; steht dort bereits einer, bleibt er unverändert. Diese vier Befehle zeigen den Sachverhalt:
dig +short MX <ihre-domain> dig +short TLSA _25._tcp.<ihre-domain> dig +short TLSA _25._tcp.<mx-hostname> openssl s_client -starttls smtp -connect <mx-hostname>:25 </dev/null | openssl x509 -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256
Den Schluss zieht erst die dritte Abfrage. Liefert die zweite einen Record und bleibt die dritte leer, ist der Fehler gefunden: Weil am MX-Hostnamen kein Eintrag steht, ziehen Sender wie Exchange Online ersatzweise den Eintrag an der Empfängerdomäne heran und vergleichen ihn mit dem Zertifikat des heutigen MX. Liefert dagegen auch die dritte Abfrage einen Record, hat dieser Vorrang: Ein Sender wertet ihn aus und sieht den Scheitel der Domäne gar nicht erst an. Der Eintrag dort ist dann unsauber, aber folgenlos. So fährt etwa posteo.de störungsfrei, dessen MX-Hostname einen eigenen TLSA-Record führt. Der letzte Befehl gibt den SHA-256-Hash des öffentlichen Schlüssels aus, den ein Record mit den Parametern 3 1 1 enthalten muss. Beide Ausgaben sind unterschiedlich formatiert: dig +short liefert den Fingerabdruck in Großbuchstaben und in zwei durch ein Leerzeichen getrennte Gruppen aufgeteilt, openssl dgst -sha256 in Kleinbuchstaben am Stück und mit einem vorangestellten Präfix wie SHA2-256(stdin)=. Vergleichen Sie deshalb erst, nachdem Sie Leerzeichen entfernt und die Schreibweise angeglichen haben. Weicht der Wert dann immer noch vom veröffentlichten ab, passt die Bindung nicht zum ausgelieferten Zertifikat.
Die Let's-Encrypt-Rollover-Falle
Besonders oft tritt das Zertifikatsproblem bei kurzlebigen Zertifikaten auf, etwa von Let's Encrypt, die alle paar Wochen erneuert werden. Jede Erneuerung ist ein potenzieller DANE-Bruch, wenn der TLSA-Record nicht mitzieht. Es gibt zwei bewährte Wege, das zu vermeiden:
- Schlüssel beibehalten. Bindet der TLSA-Record an den öffentlichen Schlüssel und nicht an das gesamte Zertifikat, bleibt er gültig, solange der Schlüssel bei der Erneuerung beibehalten wird. Viele Zertifikatswerkzeuge bieten dafür eine Option, den vorhandenen Schlüssel wiederzuverwenden.
- Überlappend rollieren. Soll der Schlüssel wechseln, veröffentlichen Sie den neuen TLSA-Record vor der Umstellung und lassen alten und neuen Wert übergangsweise parallel stehen. Erst wenn das neue Zertifikat aktiv und verbreitet ist, entfernen Sie den alten Record.
Der Fehler, der in der Praxis zu hängenden Mails führt, ist fast immer derselbe: zuerst das Zertifikat tauschen und erst danach an den TLSA-Record denken. Bei DANE gilt die umgekehrte Reihenfolge.
Schritt für Schritt diagnostizieren
Wenn Mails bereits hängen, gehen Sie systematisch vor, von außen nach innen:
- DNSSEC prüfen. Sind beide beteiligten Zonen gültig signiert und ist die Vertrauenskette intakt, also die Zone der Empfängerdomäne für den MX-Eintrag und die Zone des MX-Hostnamens für den TLSA-Record? Ohne gültiges DNSSEC ist jede weitere Prüfung sinnlos.
- MX auflösen und TLSA-Record prüfen. Welcher Hostname steht im MX-Eintrag der Empfängerdomäne, und existiert ein Record unter
_25._tcpvor genau diesem Hostnamen? Steht zusätzlich einer unter_25._tcpvor der Domäne selbst, gehört er dort weg. - Zertifikat abgleichen. Passt das aktuell vom Mailserver ausgelieferte Zertifikat zum hinterlegten TLSA-Record? Nach einer Erneuerung ist hier der häufigste Bruchpunkt.
- Mailserver-Konfiguration prüfen. Liefert der Server für die betroffene Verbindung wirklich das erwartete Zertifikat aus, oder etwa ein anderes aus einer Standardkonfiguration?
Diese Reihenfolge spiegelt die Vertrauenskette von DANE wider und führt fast immer schnell zur Ursache.
DANE-Fehler vermeiden mit Conbool MailGuard
Die wiederkehrenden Schmerzpunkte bei DANE sind der Record am falschen Namen und die Schlüsselrollierung. Genau hier setzt Conbool MailGuard an. Eingehendes DANE bieten wir für eigenbetriebene Mailserver an: Conbool ermittelt den passenden TLSA-Record aus dem Zertifikat des MX, zeigt ihn mit dem vollständigen Namen zur Veröffentlichung an und zeigt bei jeder Prüfung, ob ein bereits veröffentlichter Record noch zum ausgelieferten Zertifikat passt und ob er DNSSEC-gesichert ist. Veröffentlicht und erneuert wird der Record im DNS des Zonenbetreibers. Ausgehend validiert der Dienst die DANE-Bindung der Empfänger und protokolliert das Ergebnis, was die Fehlersuche bei Problemen auf der Gegenseite erleichtert.
Den aktuellen Stand Ihrer Domäne, also das Zusammenspiel aus DNSSEC, TLSA-Record und Zertifikat, können Sie jederzeit mit dem kostenlosen Transportsicherheits-Check prüfen. Details zur verwalteten Lösung stehen auf der Seite zu DANE und TLSA.
Häufig gestellte Fragen
Warum schlägt die DANE-Validierung fehl?
Fast immer liegt es an einer von vier Ursachen: DNSSEC ist gestört oder eine Signatur ist abgelaufen, der TLSA-Record fehlt oder steht am falschen Namen, das Zertifikat wurde erneuert und passt nicht mehr zum TLSA-Record, oder ein Mailserver präsentiert das falsche Zertifikat. Da DANE eine fehlende Übereinstimmung im Zweifel als Angriff wertet, bricht die Zustellung ab, statt unverschlüsselt fortzufahren.
Was bedeutet die Exchange-Meldung 4.7.323 tlsa-invalid?
Der Status 4.7.323 ist ein vorübergehender Fehler von Exchange Online und bedeutet, dass das vorgelegte Zertifikat des Zielservers nicht zum veröffentlichten TLSA-Record passt. Häufige Auslöser sind ein nach einer Erneuerung getauschtes Zertifikat ohne aktualisierten TLSA-Record oder ein TLSA-Record, der auf das falsche Glied der Zertifikatskette zeigt. Als 4er-Fehler versucht der sendende Server die Zustellung später erneut, weshalb betroffene Mails zunächst in der Queue verbleiben.
Wie erneuere ich Zertifikate, ohne DANE zu brechen?
Der sichere Weg ist, den TLSA-Record vor der Umstellung zu aktualisieren und beide Werte übergangsweise parallel zu veröffentlichen, den für das alte und den für das neue Zertifikat. Erst wenn das neue Zertifikat aktiv ist und der alte TLSA-Record nicht mehr gebraucht wird, entfernen Sie ihn. Bei einer Bindung an den öffentlichen Schlüssel lässt sich der Schlüssel bei der Erneuerung beibehalten, dann bleibt der TLSA-Record sogar unverändert gültig.
Was tun, wenn der TLSA-Record nicht gefunden wird?
Prüfen Sie zuerst, ob der Record unter dem korrekten Namen steht, also _25._tcp vor dem Hostnamen aus dem MX-Eintrag der Domäne und nicht vor der Domäne selbst, und ob er für genau diesen Hostnamen gilt. Prüfen Sie anschließend, ob die DNS-Zone mit DNSSEC signiert und die Vertrauenskette intakt ist, denn ein nicht validierbarer Record wird wie ein fehlender behandelt. Erst wenn beides stimmt, kann ein sendender Server die Bindung nutzen.
Wie prüfe ich, ob DANE für meine Domäne funktioniert?
Prüfen Sie für jeden Mailserver Ihrer Domäne, ob ein gültiger, DNSSEC-signierter TLSA-Record existiert und ob das tatsächlich vorgelegte Zertifikat dazu passt. Ein Transportsicherheits-Check stellt diese Kette an einer Stelle dar und zeigt, ob DNSSEC, TLSA-Record und Zertifikat zusammenpassen. So erkennen Sie ein Problem, bevor es zu liegengebliebenen E-Mails führt.
Fazit
DANE-Fehler wirken im ersten Moment bedrohlich, weil sie echte E-Mails stoppen. In der Praxis sind sie aber gut eingrenzbar: DNSSEC, TLSA-Record, Zertifikat und Mailserver-Konfiguration sind die vier Stellen, an denen es klemmt, und die Diagnose folgt immer derselben Vertrauenskette, die mit dem MX-Eintrag beginnt. Den größten Teil der Fehler vermeidet, wer die Schlüsselrollierung im Griff hat und den TLSA-Record vor dem Zertifikat anfasst, nicht danach.
Prüfen Sie Ihre Domäne mit dem Transportsicherheits-Check und sehen Sie, wie Conbool MailGuard die Bindung aus TLSA-Record und Zertifikat prüft.
Weiterführende Artikel:
