DANE legt den Fingerabdruck des Zertifikats Ihres 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 Ihrer 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 Sie zuerst tun sollten, und die Antwort lautet MTA-STS.
DANE ist ein TLSA-Eintrag unter Ihrem MX-Host, und DNSSEC ist der Kern
Ein TLSA-Eintrag enthält einen Hash des Zertifikats oder des öffentlichen Schlüssels, den Ihr 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 Sie aufschieben können. Ein sendender Server erfährt den Fingerabdruck Ihres 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 Ihres MX-Hosts und nicht Ihrer Domain. Der Eintrag hängt an jedem Hostnamen Ihres 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 Ihr Mandant bekommen hat, und das prüfen Sie besser an Ihrer 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 Ihnen etwas über die Zone. Ein SERVFAIL sagt Ihnen, 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 Sie heute ohne DNSSEC veröffentlichen können
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 Ihre Zone signiert ist und Sie eigene Mailserver betreiben, ist DANE stärker, weil es nicht auf dem Zertifizierungsstellensystem aufbaut, das es ersetzt. Ist Ihre Zone nicht signiert, ist MTA-STS das einzige der beiden, das Sie überhaupt einsetzen können, und es ist das, was die großen Anbieter beachten.
Was zu tun ist, der Reihe nach
- Prüfen Sie, was Ihre MX-Hosts bereits veröffentlichen, mit unserer MX-Eintrag-Abfrage, bevor Sie irgendetwas entscheiden. Auf einer gehosteten Plattform liegt die Antwort bei Ihrem Anbieter, nicht bei Ihnen.
- Veröffentlichen Sie 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öffentlichen Sie 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ügen Sie DANE nur hinzu, wenn Sie Ihre Zone signieren und Ihren eigenen MX betreiben. Veröffentlichen Sie
3 1 1pro Host und rotieren Sie den Eintrag vor dem Zertifikat, nie danach. - Veröffentlichen Sie TLSA niemals in einer unsignierten Zone. Es authentifiziert nichts und verpflichtet Sie 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 Ihrem 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 Ihrer 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, machen Sie einen kostenlosen Spam-Test.
