DANE legt den Fingerabdruck des Zertifikats deines Mailservers im DNS ab, unter dem MX-Host, zu dem er gehört, und signiert ihn mit DNSSEC, damit ein sendender Server das Zertifikat prüfen kann, ohne einer öffentlichen Zertifizierungsstelle zu vertrauen. Es ist ein fertiger Standard, kein Entwurf: RFC 7672 ist seit Oktober 2015 Standards Track.
Die vier Mailbox-Anbieter, die darüber entscheiden, ob der Großteil deiner Post ankommt, veröffentlichen überhaupt keinen TLSA-Eintrag. Wir haben Gmail, Outlook.com, Yahoo und iCloud am 22. September 2026 geprüft und keinen gefunden. Das macht DANE nicht wertlos, aber es entscheidet, was du zuerst tun solltest, und die Antwort lautet MTA-STS.
DANE ist ein TLSA-Eintrag unter deinem MX-Host, und DNSSEC ist der Kern
Ein TLSA-Eintrag enthält einen Hash des Zertifikats oder des öffentlichen Schlüssels, den dein Mailserver vorzeigt, veröffentlicht unter _25._tcp. plus dem MX-Hostnamen. RFC 6698 definierte den Eintragstyp im August 2012; RFC 7672 definierte im Oktober 2015, wie SMTP ihn nutzt, und RFC 7671 ergänzte im selben Monat betriebliche Hinweise.
Der Vertrauensanker ist DNSSEC, und das ist kein Detail, das du aufschieben kannst. Ein sendender Server erfährt den Fingerabdruck deines Zertifikats über das DNS, also muss die Antwort im DNS authentifiziert sein. Ohne signierte Kette kann jeder, der die Abfrage manipulieren kann, den TLSA-Eintrag löschen, und der Sender fällt auf nicht authentifiziertes TLS zurück, also genau auf den Angriff, den DANE verhindern soll. Ein TLSA-Eintrag in einer unsignierten Zone ist Dekoration.
Deshalb ist DANE auch eine Eigenschaft deines MX-Hosts und nicht deiner Domain. Der Eintrag hängt an jedem Hostnamen deines MX-Satzes, eine Domain mit drei MX-Hosts braucht also drei Sätze von Einträgen, und jeder davon muss mit dem Zertifikat auf dieser Maschine Schritt halten.
Nur zwei der vier Zertifikatsverwendungen sind für SMTP zulässig
TLSA führt ein Verwendungsfeld mit vier Werten, und RFC 7672 Abschnitt 3.1.3 schließt die Hälfte davon für E-Mail aus.
| Verwendung | Name | Für SMTP zulässig |
|---|---|---|
| 0 | PKIX-TA | Nein |
| 1 | PKIX-EE | Nein |
| 2 | DANE-TA | Ja |
| 3 | DANE-EE | Ja |
Der Grund steht unmissverständlich im RFC: Von SMTP-Client-MTAs kann nicht erwartet werden, dass sie mit einem hinreichend vollständigen Satz vertrauenswürdiger öffentlicher CAs konfiguriert sind. Die Verwendungen 0 und 1 verlangen vom sendenden Server, zusätzlich gegen das öffentliche CA-System zu prüfen, und ein Mailserver ist kein Browser. Die Spezifikation sagt, die Behandlung dieser beiden durch den Client sei undefiniert und Clients dürften solche Einträge als unbrauchbar behandeln. Einen davon zu veröffentlichen ist also ein Münzwurf auf die Implementierung anderer.
In der Praxis läuft das Feld auf eine einzige Form hinaus. Posteo veröffentlicht fünf TLSA-Einträge pro MX-Host, alle mit Verwendung 3, Selektor 1 und Abgleichstyp 1: DANE-EE über den öffentlichen Schlüssel des Zertifikatsinhabers, gehasht mit SHA-256. Das ist 3 1 1, und das ist die Form zum Nachmachen. Selektor 1 ist wichtig, weil er den Schlüssel abdeckt und nicht das Zertifikat, sodass eine Erneuerung des Zertifikats mit demselben Schlüssel den Eintrag nicht bricht.
Keiner der vier großen Mailbox-Anbieter veröffentlicht TLSA
Wir haben am 22. September 2026 jeden MX-Host der unten stehenden Domains auf einen TLSA-Eintrag unter _25._tcp. abgefragt, sowohl über Google Public DNS als auch über Cloudflare DNS. Beide Endpunkte stimmten in jeder Zeile überein.
| Domain | TLSA auf ihren MX-Hosts |
|---|---|
| gmail.com | Keiner |
| outlook.com | Keiner |
| yahoo.com | Keiner |
| icloud.com | Keiner |
| t-online.de | Keiner |
| posteo.de | 5 Einträge pro Host, alle 3 1 1 |
| mailbox.org | 1 bis 2 Einträge pro Host |
| gmx.net | 2 Einträge pro Host |
| web.de | 1 Eintrag pro Host |
| freenet.de | 2 Einträge pro Host |
| protonmail.ch | 2 Einträge pro Host |
| nic.cz | 1 Eintrag pro Host |
| rijksoverheid.nl | 2 Einträge pro Host |
Das Muster ist eher regional als technisch. Deutsche und Schweizer Mailbox-Anbieter, die tschechische Domain-Registry und die niederländische Regierung veröffentlichen TLSA und signieren ihre Zonen. Die vier Anbieter, deren Filterentscheidungen den meisten Sendern tatsächlich wichtig sind, tun das nicht, und t-online.de ist die deutsche Ausnahme, die zeigt, dass die Aufteilung eine Entscheidung jedes Betreibers ist und keine nationale Regel.
Exchange Online veröffentlicht TLSA auf den neueren MX-Hosts, nicht auf den älteren
Microsoft ist der einzige große Betreiber, der sich bewegt. Mandanten, deren MX auf den neueren Hostnamen mx.microsoft zeigt, führen vier TLSA-Einträge, gemischt aus Verwendung 2 und Verwendung 3, in einer DNSSEC-signierten Zone. Wir haben das bei kpn.com und sidn.nl gesehen, die beide auf Hosts unter mx.microsoft auflösen.
Der ältere Exchange-Online-Hostname unter mail.protection.outlook.com führt nichts, und der Consumer-Hostname hinter outlook.com ebenso wenig. Ob Microsoft DANE unterstützt, hat damit keine einzelne Antwort: Es hängt davon ab, welchen MX-Hostnamen dein Mandant bekommen hat, und das prüfst du besser an deiner eigenen Domain, statt es aus einer Ankündigung zu lesen.
Ein Host antwortete mit SERVFAIL, und das ist nicht dasselbe wie kein Eintrag
Die Abfrage von microsoft-com.mail.protection.outlook.com lieferte SERVFAIL von Google Public DNS und NXDOMAIN von Cloudflare DNS. Das sind unterschiedliche Aussagen, und nur eine davon ist eine Antwort.
Nur NOERROR und NXDOMAIN sagen dir etwas über die Zone. Ein SERVFAIL sagt dir, dass die Abfrage fehlgeschlagen ist, und das ist eine Tatsache über den Resolver und den Weg, nicht darüber, ob ein Eintrag existiert. Ein Prüfwerkzeug, das bei einem SERVFAIL kein DANE meldet, behauptet etwas, das es nicht gemessen hat, und wer das liest, handelt so, als hätte der Betreiber sich gegen eine Veröffentlichung entschieden.
Deshalb wurde jede Zeile der obigen Tabelle zweimal gelesen, über zwei unabhängige Resolver, und deshalb wird der eine Host, der sich selbst widersprach, hier beschrieben, statt ein Urteil zu bekommen.
MTA-STS ist die Richtlinie, die du heute ohne DNSSEC veröffentlichen kannst
MTA-STS löst dasselbe Problem mit einem anderen Vertrauensanker. RFC 8461, im September 2018 von Autoren bei Google, Oath, Comcast und Microsoft veröffentlicht, legt eine Richtliniendatei hinter HTTPS auf einem bekannten Host ab und verweist von einem TXT-Eintrag darauf. Die Web-PKI authentifiziert die Richtlinie, DNSSEC ist also nicht nötig.
| DANE für SMTP | MTA-STS | |
|---|---|---|
| Standard | RFC 7672, 2015 | RFC 8461, 2018 |
| Vertrauensanker | DNSSEC | Web-PKI über HTTPS |
| Veröffentlicht als | TLSA pro MX-Host | TXT-Eintrag plus Richtliniendatei |
| Braucht signierte Zone | Ja | Nein |
| Unterstützung großer Anbieter | Selten | Verbreitet |
Sie sind keine Rivalen, und eine Domain kann beides veröffentlichen. Wenn deine Zone signiert ist und du eigene Mailserver betreibst, ist DANE stärker, weil es nicht auf dem Zertifizierungsstellensystem aufbaut, das es ersetzt. Ist deine Zone nicht signiert, ist MTA-STS das einzige der beiden, das du überhaupt einsetzen kannst, und es ist das, was die großen Anbieter beachten.
Was zu tun ist, der Reihe nach
- Prüfe, was deine MX-Hosts bereits veröffentlichen, mit unserer MX-Eintrag-Abfrage, bevor du irgendetwas entscheidest. Auf einer gehosteten Plattform liegt die Antwort bei deinem Anbieter, nicht bei dir.
- Veröffentliche MTA-STS. Es funktioniert ohne DNSSEC, die großen Anbieter setzen es durch, und es ist die Änderung, die in diesem Quartal die tatsächliche Zustellung betrifft. Unser MTA-STS-Checker liest den TXT-Eintrag und die Richtliniendatei gemeinsam.
- Veröffentliche TLS-RPT. Es ist ein einziger TXT-Eintrag, ändert nichts an der Zustellung und ist der Weg herauszufinden, ob eine der beiden Richtlinien beachtet wird. Unser TLS-RPT-Checker validiert den Eintrag samt der Groß- und Kleinschreibung beachtenden Versionsangabe, die einen kleingeschriebenen Eintrag stillschweigend verwirft.
- Füge DANE nur hinzu, wenn du deine Zone signierst und deinen eigenen MX betreibst. Veröffentliche
3 1 1pro Host und rotiere den Eintrag vor dem Zertifikat, nie danach. - Veröffentliche TLSA niemals in einer unsignierten Zone. Es authentifiziert nichts und verpflichtet dich dazu, einen Eintrag ohne jeden Gewinn mit einem Zertifikat synchron zu halten.
Warum wir MTA-STS und TLS-RPT prüfen, DANE aber nicht
Ein DANE-Urteil braucht eine DNSSEC-Vertrauensentscheidung, und unsere Prüfwerkzeuge laufen in deinem Browser über DNS-over-HTTPS. Das AD-Bit in einer DoH-Antwort ist die Behauptung des Resolvers, er habe die Kette validiert, nicht der Beweis, dass sie validiert. Ein grünes DANE-Ergebnis auf der Behauptung eines anderen auszugeben wäre genau das selbstsichere, unverdiente Urteil, das diese Werkzeuge vermeiden sollen, also liefern wir keines.
Die Transporteinträge, die wir vollständig lesen können, lesen wir vollständig. Alles andere an deiner Sendekonfiguration ist eine andere Ebene, und unser Leitfaden zur E-Mail-Authentifizierung behandelt, wie SPF, DKIM und DMARC darüber zusammenspielen. Über die Domains, die wir für den Unspam 2026 E-Mail-Zustellbarkeitsbericht testen, veröffentlichen 48 % eine DMARC-Richtlinie, und das ist die offene Arbeit, die mehr Post bewegt, als TLSA es je tun wird.
Um zu sehen, was eine echte Nachricht bei der Ankunft wirklich trägt, mach einen kostenlosen Spam-Test.
