Der DNS Tree Walk von DMARCbis: das Ende der Public Suffix List

Hinter DMARC verbirgt sich eine unscheinbare, aber fundamentale Frage: Wenn eine Nachricht von mail.meine-bank.de kommt, zu welcher „Organisationsdomain" gehört sie? Die Antwort bestimmt, welche Policy anzuwenden ist und ob das Alignment erfüllt ist. Bis DMARCbis antwortete DMARC dank einer externen Liste, der Public Suffix List. DMARCbis ersetzt sie durch einen im DNS nativen Mechanismus: den DNS Tree Walk. Dieser Leitfaden erklärt, was die Organisationsdomain ist, warum die PSL problematisch war, wie der Tree Walk funktioniert und was das konkret ändert. Für die Panoramasicht siehe DMARCbis einfach erklärt.

Was ist die „Organisationsdomain"?

Ein Name wie news.marketing.meine-bank.de hat mehrere Ebenen. Für DMARC muss man wissen, welche die Organisationsdomain ist — grob gesagt die von der Organisation „bezahlte und besessene" Domain, hier meine-bank.de. Es ist diese Ebene, die den DMARC-Referenzeintrag trägt und als Basis für das „relaxed"-Alignment dient. Ohne eine verlässliche Definition der Organisationsdomain weiß DMARC nicht, wie es von news.marketing.meine-bank.de bis zur Policy von meine-bank.de hinaufsteigen soll.

Die Schwierigkeit ist, dass die Grenze nicht offensichtlich ist. Für beispiel.de ist die Organisationsdomain beispiel.de. Aber für beispiel.co.uk ist es beispiel.co.uk (und nicht co.uk, das ein Public Suffix ist). Wie weiß eine Maschine, dass .co.uk ein Suffix ist und nicht .uk allein?

Das Problem der Public Suffix List

Die historische Antwort: die Public Suffix List (PSL), eine von der Community gepflegte Liste (ursprünglich für Mozilla), die alle Suffixe aufzählt, unter denen die Öffentlichkeit Domains registrieren kann (.de, .co.uk, .com, .gouv.fr usw.). DMARC nutzte sie, um die Grenze zu finden.

Das funktionierte, aber mit lästigen Mängeln:

• Eine externe Abhängigkeit. Die PSL ist eine Drittdatei, von Hand aktualisiert. Jede DMARC-Implementierung musste sie einbetten und aktuell halten. Eine veraltete Liste = falsche Alignment-Entscheidungen.
• Inkonsistenzen. Je nach Aktualität der eingebetteten PSL konnten zwei Empfänger eine unterschiedliche Organisationsdomain für denselben Namen berechnen.
• Eine Logik außerhalb des DNS. Das DNS ist die Quelle der Wahrheit der Domains… aber diese Schlüsselentscheidung stützte sich auf eine Datei neben dem DNS.

Wie der DNS Tree Walk funktioniert

DMARCbis ersetzt die PSL durch einen nativen Ansatz: das DNS direkt abfragen, Ebene für Ebene. Das ist der DNS Tree Walk.

Das Prinzip, vereinfacht: Um die Organisationsdomain eines Namens zu finden, steigt man den Label-Baum hinauf und sucht auf jeder Ebene den DMARC-Eintrag (_dmarc), bis zu höchstens acht Abfragen. Die erste Ebene, die eine relevante DMARC-Policy trägt, definiert die Organisationsdomain. Das Limit von acht Abfragen ist ein Anti-Missbrauchs-Schutz (um zu verhindern, dass ein überlanger Name eine Lawine von Abfragen auslöst), genau im Geist des Limits der zehn Auflösungen von SPF.

Das Ergebnis: Die Bestimmung der Organisationsdomain wird deterministisch und selbstgenügsam. Keine externe Liste mehr, keine Aktualitätsdivergenz mehr — nur das DNS, das alle auf dieselbe Weise abfragen.

Was das für dich ändert

Gute Nachricht, wie oft bei DMARCbis: auf der Veröffentlichungsseite fast nichts. Du hast kein Tag hinzuzufügen, um den Tree Walk zu „aktivieren": Es ist eine Änderung in der Art, wie die Empfänger deine Domain auswerten, nicht in dem, was du veröffentlichst. Dennoch zwei praktische Implikationen:

• Eine vorhersehbarere Zuordnung, besonders für Organisationen mit komplexen Baumstrukturen (kaskadierende Subdomains, mehrere Marken). Weniger Überraschungen, wo eine Subdomain falsch zugeordnet wird.
• Die Interaktion mit np. Der Tree Walk ist auch das, was erlaubt zu beurteilen, dass eine Subdomain „nicht existierend" ist (sie löst auf keiner Ebene auf), um ihr also das Tag np anzuwenden. Die beiden Neuerungen ergänzen sich.

Und das Tag psd in all dem?

DMARCbis führt auch psd ein, einen Marker für die Public-Suffix-Domains selbst (die Registry-Betreiber, zum Beispiel ein .gouv.fr). Es hilft dem Tree Walk zu wissen, wo er in Sonderfällen aufhören soll — typischerweise zu markieren, dass eine Ebene ein Public Suffix und keine Organisationsdomain ist. Für die überwältigende Mehrheit der Organisationen betrifft dich psd nicht direkt: Es interessiert vor allem die Administratoren von TLDs und öffentlichen Domains. Was dich betrifft, ist, dass dieser Marker den Tree Walk bis zur Spitze des Baums verlässlich macht.

Ein Detail, das für die Konformität zählt

Eine von Hand gepflegte Liste durch eine native DNS-Auflösung zu ersetzen, ist nicht nur eine technische Eleganz: Es ist auch ein Argument der Auditierbarkeit. Eine auf dem öffentlichen DNS gegründete Alignment-Entscheidung ist reproduzierbar und erklärbar — jeder kann den Tree Walk nachspielen und dasselbe Ergebnis erhalten. Für Organisationen, die ihre Kontrollen dokumentieren müssen (siehe Banken), ist das eine gesündere Basis als eine Abhängigkeit von einer Drittdatei.

Ein Tree Walk, Schritt für Schritt

Nehmen wir ein konkretes Beispiel, um den Mechanismus greifbar zu machen. Eine Nachricht kommt mit From: alarm@benachrichtigungen.zahlungen.meine-bank.de. Der Empfänger will die Organisationsdomain finden. Hier, vereinfacht, der Ablauf:

1. Er sucht einen Eintrag _dmarc.benachrichtigungen.zahlungen.meine-bank.de — nichts.
2. Er steigt eine Stufe hinauf: _dmarc.zahlungen.meine-bank.de — nichts.
3. Er steigt noch weiter: _dmarc.meine-bank.de — gefunden: v=DMARC1; p=reject; np=reject; ….

Die Organisationsdomain ist also meine-bank.de, und es ist ihre Policy, die gilt. Das Ganze in drei Abfragen, weit unter der Obergrenze von acht. Wäre beim Hinaufsteigen kein Eintrag bis zum Public Suffix (.de) gefunden worden, hätte der Empfänger daraus geschlossen, dass die Domain nicht durch DMARC geschützt ist. Und hätte benachrichtigungen.zahlungen.meine-bank.de auf keiner Ebene aufgelöst, wäre das Tag np der Organisationsdomain zur Anwendung gekommen.

PSL vs Tree Walk: der Vergleich

	Public Suffix List	DNS Tree Walk
Quelle	Externe, von Hand gepflegte Datei	Das DNS selbst
Aktualität	Hängt von der Aktualisierung jeder Implementierung ab	Immer aktuell (Live-Auflösung)
Kohärenz	Kann von einem Empfänger zum anderen variieren	Deterministisch, identisch für alle
Kosten	Eine Liste einbetten und aktuell halten	Bis zu 8 DNS-Abfragen (gecacht)
Auditierbarkeit	Undurchsichtig (hängt von einer Listenversion ab)	Von jedem reproduzierbar

Der Tree Walk hat Kosten — einige zusätzliche DNS-Abfragen — aber sie werden gecacht und auf acht gedeckelt. Im Gegenzug gewinnt man eine verlässliche, überall identische Zuordnung, die nicht mehr von einer Drittdatei abhängt.

Häufige Fragen zum Tree Walk

Muss ich den Tree Walk „aktivieren"? Nein. Es ist eine Änderung auf Empfängerseite, in der Art, wie er deine Domain auswertet. Du veröffentlichst kein Tag dafür; du hast nichts zu tun.

Verlangsamt der Tree Walk den Empfang der E-Mails? In der Praxis nein. Die maximal acht Abfragen werden von den Resolvern gecacht, und die meisten Fälle lösen sich in zwei oder drei Abfragen auf. Der Einfluss ist vernachlässigbar gegenüber dem Rest der Verarbeitung einer Nachricht.

Was passiert bei einstufigen Domains (beispiel.de)? Der Tree Walk findet den DMARC-Eintrag schon auf der ersten oder zweiten Ebene. Je flacher die Baumstruktur, desto schneller — die meisten Domains sind in diesem Fall.

Und wenn zwei Ebenen je einen DMARC-Eintrag haben? Der Tree Walk hält beim ersten angetroffenen beim Hinaufsteigen an, der zur Referenz-Organisationsdomain wird. Deshalb kann eine Subdomain ihre eigene Policy haben und sich dennoch unter die ihres Elternteils einordnen.

Sonderfälle und bewährte Praktiken

Einige Situationen verdienen ein Wort. Die sehr tiefen Baumstrukturen (vier oder fünf Ebenen von Subdomains) bleiben abgedeckt: Der Tree Walk steigt bis zu acht Ebenen hinauf, weit über die realen Bedürfnisse hinaus. Die Domains mit mehreren Marken (eine Gruppe, die marke-a.com, marke-b.com betreibt) behalten jeweils ihre eigene Organisationsdomain — der Tree Walk behandelt sie unabhängig, wie es sich gehört. Die Weiterleitungen und CNAME ändern nichts: Es ist das Vorhandensein eines _dmarc-Eintrags auf einer Ebene, das zählt, nicht die Natur der anderen Einträge.

Bewährte Praxis: Veröffentliche deine DMARC-Policy auf der Ebene der Organisationsdomain, nicht nur auf einer isolierten Subdomain. Es ist diese Ebene, die der Tree Walk für die Gesamtheit deiner Subdomains finden wird, und sie ist es, die den „Standard"-Schutz deines gesamten Namensraums trägt. Eine Subdomain kann anschließend bei Bedarf ihre eigene, spezifischere Policy haben, aber das Fundament wird an der Organisationsroot gesetzt.

Behalte schließlich im Kopf, dass der Tree Walk für dich unsichtbar ist: Du „konfigurierst" ihn nie. Dein einziger Hebel bleibt der Eintrag, den du veröffentlichst. Wenn du prüfen willst, wie deine Domain interpretiert wird, zeigt dir ein Analyzer die effektive Policy von Empfängerseite betrachtet.

Ein konkreter Fall, in dem der Unterschied zählt

Um zu verstehen, warum der Wechsel von der PSL zum Tree Walk mehr ist als eine technische Feinheit, stell dir eine reale Panne vor, wie sie unter der PSL vorkam. Ein Land führt eine neue Registrierungsebene ein — sagen wir, ein Registry öffnet Registrierungen direkt unter einem regionalen Suffix, das vorher nicht öffentlich war. Bis diese Änderung in die Public Suffix List aufgenommen und die aktualisierte Liste in jede DMARC-Implementierung eingebettet ist, vergehen Wochen oder Monate. In diesem Zeitfenster berechnen manche Empfänger die Organisationsdomain für Namen unter diesem Suffix falsch: Sie ordnen einen Namen der falschen Ebene zu, wenden die falsche Policy an und können legitime Mail ablehnen oder — schlimmer — gefälschte Mail durchlassen. Zwei Empfänger, einer mit frischer PSL, einer mit veralteter, treffen für dieselbe Nachricht gegensätzliche Entscheidungen. Das ist keine hypothetische Sorge; es war die strukturelle Schwäche einer von Hand gepflegten Liste, die die Realität des DNS immer mit Verzögerung einholte.

Mit dem Tree Walk verschwindet dieses Zeitfenster vollständig. Es gibt keine Liste, die aktuell gehalten werden muss, weil die Antwort direkt aus dem DNS kommt, in Echtzeit abgefragt. In dem Moment, in dem ein Registry eine neue Ebene öffnet, spiegelt das DNS diese Realität wider, und der Tree Walk sieht sie sofort — ohne dass irgendjemand eine Datei aktualisieren muss. Für dich als Betreiber bedeutet das eine Zuordnung, die sich nicht mehr je nach Aktualität der Software deines Empfängers unterscheidet, und das ist besonders wertvoll, wenn deine Organisation unter neueren oder regionalen Suffixen operiert, die in der PSL historisch schlecht oder verspätet abgedeckt waren. Der Tree Walk tauscht eine unsichtbare, schwer diagnostizierbare Fehlerquelle gegen ein paar zusätzliche, gecachte DNS-Abfragen ein — ein hervorragendes Geschäft für die Verlässlichkeit.

Kurz gefasst

Der DNS Tree Walk ersetzt die Public Suffix List zur Bestimmung der Organisationsdomain eines Namens: DMARCbis fragt das DNS Schritt für Schritt ab (höchstens acht Abfragen), statt von einer externen Liste abzuhängen. Ergebnis: eine deterministische, für alle identische, auditierbare und stets aktuelle Zuordnung. Du hast dafür nichts zu veröffentlichen — es ist eine Änderung auf Empfängerseite.

Lass Thomas die Details des Protokolls managen

Organisationsdomain, Tree Walk, psd: Das sind die inneren Zahnräder von DMARCbis, jene, die du niemals von Hand anfassen solltest. Thomas, dein virtueller CISO, argumentiert über die reale Baumstruktur deiner Domain, erzeugt die kohärente Policy auf jeder Ebene (Root, reale Subdomains, nicht existierende) und sagt dir genau, was du veröffentlichen sollst.

Analysiere deine Domain kostenlos → oder erstelle ein Konto. Für den vollständigen Kontext siehe diesen neuen Standard einfach erklärt und das np-Tag.