DANE-Fehler beheben: Warum E-Mails hängen bleiben (TLSA validation failed)
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 | Record unter _25._tcp des Mailserver-Hostnamens korrekt veröffentlichen |
| 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
Die mit Abstand häufigste Ursache im laufenden Betrieb ist ein erneuertes Zertifikat. 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.
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. Ist die Zone des Mailservers gültig signiert und die Vertrauenskette intakt? Ohne gültiges DNSSEC ist jede weitere Prüfung sinnlos.
- TLSA-Record prüfen. Existiert ein Record unter dem korrekten Namen, also
_25._tcp vor dem Mailserver-Hostnamen, und gilt er für genau diesen Host? - 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
Der wiederkehrende Schmerzpunkt bei DANE ist die Schlüsselrollierung. Genau hier setzt Conbool MailGuard an: Eingehend werden die TLSA-Records veröffentlicht und bei jedem Zertifikatswechsel überlappend und damit bruchfrei rolliert, sodass nie ein Fenster entsteht, in dem Record und Zertifikat auseinanderlaufen. Ausgehend prüft der Dienst die DANE-Bindung der Empfängerdomänen 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, üblicherweise _25._tcp vor dem Hostnamen des Mailservers, 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. 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 Schlüsselrollierung bruchfrei übernimmt.
Weiterführende Artikel:
