Cover Image for Aufgenommen in die Hall of Fame 2.0 des BSI: Warum DANE der Schritt ist, der jetzt zählt

Aufgenommen in die Hall of Fame 2.0 des BSI: Warum DANE der Schritt ist, der jetzt zählt

Conbool ist in die Hall of Fame 2.0 des E-Mail-Sicherheitsjahres von BSI, eco und Bitkom aufgenommen worden. Der Beitrag erklärt, was geprüft wurde, warum DNSSEC allein noch keine sichere E-Mail bedeutet, woran DANE in der Praxis scheitert und wie sich TLSA-Einträge dauerhaft betreiben lassen, ohne die eigene Zustellung zu gefährden.

7 minNews / E-Mail-Sicherheit

Es gibt Auszeichnungen, die hängt man sich an die Wand. Und es gibt Auszeichnungen, die einem die Arbeit der nächsten Jahre aufschreiben. Die Hall of Fame 2.0 des E-Mail-Sicherheitsjahres gehört zur zweiten Sorte.

Conbool ist in die Hall of Fame 2.0 aufgenommen worden, mit der das Bundesamt für Sicherheit in der Informationstechnik gemeinsam mit eco und Bitkom zum Abschluss des E-Mail-Sicherheitsjahres Organisationen auszeichnet, die DNSSEC umgesetzt haben. Gemessen wurde nicht, was jemand angekündigt hat, sondern was am 30. Juni 2026 tatsächlich im DNS stand.

Das ist der Teil, über den man sich freut. Der interessantere Teil ist der, der danach kommt.

Was das BSI gemessen hat, und was daraus folgt

Die Ausgangslage der Kampagne war unbequem. Zu Beginn waren nach den Messungen des BSI knapp vier Prozent der .de-Domains mit DNSSEC gesichert. In einigen europäischen Ländern liegt der Wert über fünfzig Prozent. Gleichzeitig beginnen über neunzig Prozent aller Angriffe mit einer E-Mail.

DNSSEC schließt dabei eine Lücke, die kaum jemand sieht, weil sie eine Ebene unter der E-Mail liegt. Das DNS ist das Adressbuch des Internets. Ohne Signatur kann eine Antwort aus diesem Adressbuch unterwegs verändert werden, und dann landet Post bei einem Server, der nur so aussieht wie der richtige. SPF, DKIM und DMARC helfen an dieser Stelle nicht, denn sie prüfen die Absenderidentität, nicht den Weg.

DNSSEC allein liefert allerdings noch keine sichere E-Mail. Es liefert eine vertrauenswürdige Grundlage. Erst was darauf aufsetzt, schützt die Zustellung selbst. Für den Transport ist das DANE.

Warum DANE in der Praxis liegen bleibt

DANE hinterlegt den Fingerabdruck des Mailserver-Zertifikats als TLSA-Eintrag im signierten DNS. Ein sendender Server schlägt diesen Eintrag nach, vergleicht ihn mit dem Zertifikat, das ihm beim Verbindungsaufbau angeboten wird, und stellt nur zu, wenn beides zusammenpasst. Ein untergeschobener Server fliegt damit auf, und das stille Herabstufen auf eine unverschlüsselte Verbindung ebenso.

Die Technische Richtlinie BSI TR-03108 fordert genau das. Trotzdem steht DANE in vielen Unternehmen seit Jahren auf der Liste und wird seit Jahren verschoben. Der Grund ist nicht Unwissen, sondern eine sehr berechtigte Sorge:

Ein Zertifikat wird heute alle neunzig Tage erneuert. Ändert sich dabei der Schlüssel, passt der Fingerabdruck im DNS nicht mehr. Jeder Absender, der DANE prüft, weist die Zustellung dann korrekt zurück. Der Fehler liegt nicht beim Absender, sondern bei uns, und er trifft ausgerechnet die sicherheitsbewussten Gegenstellen zuerst. Wer schon einmal erlebt hat, wie Mails eines großen Kunden plötzlich in der Warteschlange stehen, versteht, warum die Tür lieber offen bleibt.

Das ist der eigentliche Grund, warum eine Technologie aus dem Jahr 2012 immer noch Nischenthema ist. Nicht die Theorie ist schwierig, sondern der Betrieb.

Wie sich das lösen lässt

Der Betrieb wird beherrschbar, sobald drei Dinge geklärt sind.

Der Schlüssel bleibt stabil. Eine Zertifikatserneuerung muss nicht zwingend einen neuen Schlüssel bedeuten. Wird derselbe Schlüssel weiterverwendet, bleibt der Fingerabdruck gleich, und die Erneuerung läuft am DNS vorbei. Damit fällt der häufigste Bruchfall weg, bevor er entstehen kann.

Der Wechsel wird angekündigt, nicht vollzogen. Muss der Schlüssel doch wechseln, etwa nach einem Vorfall oder einem Serverumzug, wird der neue Fingerabdruck veröffentlicht, solange der alte noch gilt. Beide Einträge stehen eine Weile nebeneinander, erst danach wird das neue Zertifikat aktiv. Kein Absender sieht in dieser Zeit eine Lücke.

Der Eintrag wird überwacht. Ein TLSA-Eintrag ist kein Dokument, das man einmal ablegt. Er gehört zu einem Zertifikat, das sich bewegt. Wer beides nicht zusammen betrachtet, erfährt vom Auseinanderlaufen erst, wenn die Gegenstelle Mails ablehnt.

Nichts davon ist Zauberei. Es ist Handwerk, das jemand einmal einrichten und dann verlässlich wiederholen muss.

Wie wir es machen

Ausgehend prüft unser Gateway bei jeder Zustellung, ob der empfangende Server DANE veröffentlicht. Tut er es, wird nur über eine verschlüsselte Verbindung zugestellt, deren Zertifikat gegen den signierten Fingerabdruck geprüft wurde. Tut er es nicht, bleibt es bei der bestmöglichen Transportsicherung. Für Empfängerdomänen, bei denen es wirklich drauf ankommt, lässt sich das je Domäne verbindlich stellen: Passt die Verbindung nicht, geht die Mail nicht raus, statt ungeschützt zu fliegen.

Eingehend gilt eine Unterscheidung, die wir offen benennen, weil sie oft verschwiegen wird. In einer geteilten Cloud hängen viele Kundendomänen am selben Eingangsserver. Ein einziger Fingerabdruck gilt dort für alle, und ein Fehler bei der Erneuerung trifft alle gleichzeitig. Große Anbieter gehen diesen Weg aus gutem Grund nicht. Deshalb setzen wir eingehend auf die Betriebsform, in der DANE sauber beherrschbar ist: auf die eigene Umgebung des Kunden mit eigenem Eingangsserver, eigenem Zertifikat und eigener Zone. Dort ist der Schaden eines Fehlers auf eine Organisation begrenzt, und der Kunde behält die Kontrolle über seine Zone. In der geteilten Cloud sichern wir den Eingang stattdessen über MTA-STS ab, das dieselbe Downgrade-Frage ohne Pinning löst.

Für die eigene Domäne conbool.com gilt beides zusammen: signierte Zone, DS-Eintrag bei der Registry, TLSA-Eintrag am Eingangsserver, stabiler Schlüssel über alle Erneuerungen hinweg.

Was Sie selbst prüfen können

Wenn Sie wissen wollen, wo Ihre Organisation steht, brauchen Sie dafür keinen Anbieter:

  1. Ist Ihre Zone signiert und liegt der DS-Eintrag bei der Registry? Ohne das ist jeder TLSA-Eintrag wirkungslos.
  2. Veröffentlichen Ihre MX-Hosts einen TLSA-Eintrag? Wenn ja: gehört er zum aktuellen Zertifikat?
  3. Behält Ihr Zertifikat bei der Erneuerung den Schlüssel, und weiß die Person, die den Server betreut, dass davon die Zustellung abhängt?
  4. Und ausgehend: Prüft Ihr Gateway die TLSA-Einträge der Gegenstellen überhaupt, oder verschlüsselt es nur irgendwie?

Die vierte Frage ist die, die am häufigsten mit einem überraschten Blick beantwortet wird. Transportverschlüsselung, die jedes vorgelegte Zertifikat akzeptiert, sieht im Protokoll gut aus und hält einem Angreifer auf dem Weg nicht stand.

Warum wir daran festhalten

Digitale Souveränität entscheidet sich nicht in Strategiepapieren, sondern in Einträgen, die jemand tatsächlich setzt und danach pflegt. Jeder Mailserver, der DANE spricht, nimmt Angreifern eine Möglichkeit und macht den europäischen Mailverkehr ein Stück belastbarer. Die Hall of Fame zeigt, dass das in der Breite möglich ist, ohne dass die befürchteten Nebenwirkungen eintreten.

Wer DNSSEC bereits umgesetzt hat, ist einen Schritt von DANE entfernt. Es lohnt sich, diesen Schritt jetzt zu gehen, solange er eine bewusste Entscheidung ist und nicht die Reaktion auf einen Vorfall.

Conbool als bevorzugte Quelle bei Google

Google zeigt Inhalte bevorzugter Quellen häufiger in der Suche, in den KI-Übersichten und im KI-Modus. Die Auswahl lässt sich jederzeit wieder ändern.

Als bevorzugte Quelle festlegen

Weitere Artikel

Die neuesten Beiträge aus unserem Blog.