Associated Domain Checks könnten den Umgang mit DNS Abuse in der Domainbranche künftig deutlich verändern. Denn wenn eine Phishing-Domain entdeckt, gemeldet und der Missbrauch gestoppt wird, ist damit nicht zwangsläufig die gesamte Kampagne beendet. Angreifer arbeiten häufig mit mehreren Domains gleichzeitig: Einige sind bereits aktiv, andere liegen als Reserve bereit und können einspringen, sobald eine Domain gesperrt oder abgeschaltet wird.

Genau an diesem Punkt setzt ein aktueller Policy-Prozess bei ICANN an. Mit Associated Domain Checks, kurz ADC, soll geprüft werden können, ob nach ausreichend belastbaren Hinweisen auf DNS Abuse weitere Domains erkennbar mit demselben Fall zusammenhängen und ebenfalls für Missbrauch eingesetzt werden.

Für Registrare wäre eine solche Regel unmittelbar relevant. Aber auch Reseller, Agenturen und Domainer sollten sich mit dem Thema beschäftigen. Gerade dort werden größere Domain-Portfolios, Kundenaccounts und technische Infrastrukturen gebündelt verwaltet. Genau diese Strukturen können später eine Rolle spielen, wenn beurteilt werden muss, ob mehrere Domains wirklich zusammengehören oder lediglich dieselben technischen Merkmale teilen.

Wichtig ist dabei: Associated Domain Checks sind Stand September 2026 noch keine verbindliche ICANN-Pflicht. Der im August 2026 veröffentlichte Initial Report enthält zunächst vorläufige Empfehlungen. Die Regeln können sich im weiteren Policy-Prozess also noch verändern.

Trotzdem ist das Thema schon heute interessant, weil es ziemlich deutlich zeigt, in welche Richtung sich die Bekämpfung von DNS Abuse entwickeln könnte.

Was versteht ICANN unter DNS Abuse?

DNS Abuse wird im Alltag häufig als Sammelbegriff für sehr unterschiedliche Probleme rund um Domains verwendet. Im ICANN-Kontext ist die Definition jedoch enger gefasst.

Dazu gehören Malware, Botnets, Phishing und Pharming. Spam zählt dann dazu, wenn er als Verbreitungsweg für eine dieser Missbrauchsformen eingesetzt wird. Nicht jedes rechtswidrige, unerwünschte oder problematische Verhalten auf einer Website fällt deshalb automatisch unter DNS Abuse.

Eine Urheberrechtsverletzung, unerwünschte Werbung oder problematische Inhalte können selbstverständlich andere rechtliche oder vertragliche Folgen haben. Sie gehören aber nicht allein deshalb in diese spezielle ICANN-Kategorie.

Diese Abgrenzung ist für Associated Domain Checks wichtig, weil der aktuelle Vorschlag genau an diese Definition von DNS Abuse anknüpft.

Was gilt bei DNS Abuse bereits heute?

Ganz neu ist das Thema nicht. Bereits seit April 2024 gelten für ICANN-akkreditierte Registrare strengere Pflichten beim Umgang mit DNS Abuse.

Wenn einem Registrar ausreichend belastbare Informationen vorliegen, anhand derer er vernünftigerweise feststellen kann, dass eine Domain für DNS Abuse verwendet wird, muss er angemessene Maßnahmen ergreifen, um den Missbrauch zu stoppen oder zumindest zu unterbrechen. ICANN bezeichnet solche belastbaren Informationen als actionable evidence.

Dabei muss ein Missbrauch nicht erst vor Gericht bewiesen worden sein. Eine bloße Behauptung oder ein vager Verdacht reicht allerdings ebenfalls nicht. Die Informationen müssen konkret genug sein, damit eine vernünftige Bewertung möglich ist.

Welche Reaktion angemessen ist, hängt anschließend vom jeweiligen Fall ab. Bei einer Domain, die offensichtlich für eine Phishing-Kampagne eingesetzt wird, kann eine Suspendierung sinnvoll sein. Bei einer legitimen Unternehmenswebsite, die aufgrund einer Sicherheitslücke kompromittiert wurde, könnte eine sofortige Sperrung der gesamten Domain dagegen unverhältnismäßig sein, weil dadurch auch Website, E-Mail und andere legitime Dienste ausfallen können.

Verhältnismäßigkeit und mögliche Kollateralschäden spielen deshalb bereits heute eine wichtige Rolle.

Wie funktionieren Associated Domain Checks?

Die bestehenden Pflichten konzentrieren sich zunächst auf die Domain, für die entsprechende Hinweise vorliegen. Bei professionell organisierten Angriffen kann das allerdings zu kurz greifen.

Angenommen, ein Angreifer registriert 30 Domains für eine Phishing-Kampagne. Eine davon wird entdeckt und abgeschaltet. Die übrigen Domains bleiben zunächst unberührt und können nach und nach aktiviert werden.

Der aktuelle ICANN-Entwurf beschreibt genau dieses Problem als eine Art „one-at-a-time“-Ansatz. Wird immer nur die gerade gemeldete Domain betrachtet, kann die größere Kampagne im Hintergrund weiterlaufen.

Associated Domain Checks sollen deshalb eine zusätzliche Frage beantworten: Gibt es weitere Domains, die sinnvoll mit diesem Fall verbunden sind – und werden auch diese für DNS Abuse verwendet?

Die Reihenfolge ist dabei entscheidend. Zuerst wird geprüft, welche anderen Domains tatsächlich mit dem Vorgang zusammenhängen könnten. Anschließend muss separat bewertet werden, ob diese Domains selbst missbräuchlich genutzt werden.

Eine Verbindung allein reicht also nicht aus.

Wann gelten Domains als „associated“?

Genau hier wird das Thema besonders interessant für Reseller, Agenturen und größere Domain-Portfolios.

Mehrere Domains können aus ganz unterschiedlichen Gründen Gemeinsamkeiten haben. Sie befinden sich vielleicht im selben Kundenaccount, wurden vom selben Domaininhaber registriert, besitzen ähnliche Namen oder verwenden dieselben Nameserver. Auch bestimmte Registrierungs- oder Infrastrukturmuster können Hinweise liefern.

Keines dieser Merkmale soll nach dem derzeitigen Vorschlag jedoch pauschal genügen.

Das ist wichtig, weil gemeinsame technische Infrastruktur in der Domainbranche völlig normal ist. Tausende Kundendomains können beispielsweise dieselben Nameserver verwenden, ohne dass ihre Inhaber irgendeine Verbindung miteinander haben. Ebenso kann ein Reseller zahlreiche voneinander unabhängige Kunden über dieselbe Plattform verwalten.

Ein gemeinsamer Nameserver bedeutet deshalb nicht automatisch gemeinsamen Missbrauch.

Der Policy-Entwurf versucht genau dieses Problem zu berücksichtigen und sogenannte Over-Association zu vermeiden. Domains sollen nicht nur deshalb miteinander in Verbindung gebracht werden, weil sie ein einzelnes technisches Merkmal teilen.

Gerade für Reseller- und Agenturmodelle ist das entscheidend. Sonst könnten völlig unbeteiligte Kunden unnötig in eine Untersuchung hineingezogen werden.

Warum Associated Domain Checks für Reseller wichtig sind

Reseller werden im aktuellen Entwurf ausdrücklich berücksichtigt.

Ein Registrar könnte sich bei Teilen eines Associated Domain Checks auf Informationen stützen, die beim Reseller vorhanden und ihm im normalen Geschäftsbetrieb vernünftigerweise zugänglich sind. Das ist praktisch nachvollziehbar, denn häufig kennt der Reseller die Endkundenstruktur genauer als der Registrar.

Der Registrar sieht möglicherweise lediglich, dass mehrere Domains über denselben Reseller verwaltet werden. Der Reseller kann dagegen oft unterscheiden, ob diese Domains wirklich demselben Endkunden gehören oder lediglich dieselbe Plattform nutzen.

Die vertragliche Verantwortung gegenüber ICANN bleibt trotzdem beim akkreditierten Registrar. Er kann seine Pflichten also nicht einfach vollständig an den Reseller weitergeben.

Für Reseller könnten saubere Kundenstrukturen, dokumentierte Abuse-Fälle und schnelle Kommunikationswege dadurch künftig noch wichtiger werden. Gerade bei größeren Portfolios sollte nachvollziehbar sein, welche Domains tatsächlich demselben Endkunden gehören und welche lediglich technische Infrastruktur teilen.

Was bedeutet das für Agenturen?

Für Agenturen ist die Situation ähnlich, häufig aber noch etwas vielschichtiger.

Eine Agentur kann mehrere hundert Domains für dutzende unterschiedliche Kunden verwalten. Viele davon laufen möglicherweise über dieselben Nameserver, denselben Hosting-Cluster oder denselben Reseller-Account.

Wird eine einzelne Kundenwebsite kompromittiert, darf daraus selbstverständlich nicht geschlossen werden, dass sämtliche anderen Agenturkunden ebenfalls auffällig sind.

Für Agenturen wird deshalb vor allem die saubere Trennung zwischen Kundenzuordnung und technischer Infrastruktur wichtig. Welche Domain gehört tatsächlich zu welchem Kunden? Welche Domains gehören zum selben Projekt? Und welche teilen lediglich Hosting, DNS oder Verwaltung?

Je klarer solche Zusammenhänge intern nachvollziehbar sind, desto einfacher lässt sich bei einem möglichen Associated Domain Check erklären, warum zwei Domains tatsächlich miteinander verbunden sind – oder eben gerade nicht.

Was bedeuten Associated Domain Checks für Domainer?

Auch für Domainer und Betreiber größerer Domain-Portfolios ist das Thema relevant.

Ein Portfolio mit hunderten oder tausenden Domains ist selbstverständlich nicht automatisch verdächtig. Auch ähnliche Domainnamen, gemeinsame Nameserver oder dieselbe Accountstruktur sind bei professionellem Domainmanagement völlig normal.

Der aktuelle Vorschlag stellt deshalb nicht auf die bloße Größe eines Portfolios ab. Entscheidend wäre vielmehr, ob ausreichend belastbare Hinweise auf DNS Abuse vorhanden sind und ob sich daraus sinnvolle Verbindungen zwischen einzelnen Domains ableiten lassen.

Für Domainer gilt daher besonders: Viele Domains sind kein Problem. Kontext und tatsächliche Nutzung entscheiden.

Ein technisch einheitlich verwaltetes Portfolio darf nicht mit einer koordinierten Missbrauchskampagne gleichgesetzt werden.

Associated Domain Checks und kompromittierte Domains

Eine besonders wichtige Ausnahme betrifft sogenannte compromised domains.

Damit sind Domains gemeint, die ursprünglich für legitime Zwecke registriert wurden und später ohne Wissen oder Zustimmung des Domaininhabers von Dritten für DNS Abuse missbraucht werden.

Ein typisches Beispiel wäre eine Unternehmenswebsite mit einem veralteten CMS. Ein Angreifer nutzt eine Sicherheitslücke, lädt dort ein Phishing-Kit hoch und verwendet die eigentlich legitime Domain plötzlich für Missbrauch.

Nach dem derzeitigen Entwurf soll eine solche kompromittierte Domain den verpflichtenden Associated Domain Check nicht automatisch auslösen.

Diese Ausnahme ist wichtig. Andernfalls könnte eine gehackte Kundenwebsite dazu führen, dass sämtliche weiteren Domains desselben Unternehmens oder der betreuenden Agentur untersucht werden, obwohl der Domaininhaber selbst gar nichts mit dem Angriff zu tun hat.

Dabei sollte man allerdings nicht zu stark vereinfachen. Entscheidend ist nicht nur, ob eine Domain ursprünglich legitim registriert wurde. Die Ausnahme betrifft Fälle, in denen der Missbrauch ohne Wissen oder Beteiligung des Domaininhabers erfolgt.

Bedeutet ein Associated Domain Check automatisch eine Sperrung?

Nein. Genau diese Abgrenzung ist für die Einordnung des Themas wichtig.

Ein Associated Domain Check wäre zunächst eine Untersuchung. Er soll helfen, weitere möglicherweise relevante Domains zu erkennen und anschließend zu prüfen, ob diese tatsächlich für DNS Abuse verwendet werden.

Es gilt also nicht automatisch:

Eine Domain ist missbräuchlich, deshalb werden alle Domains desselben Accounts gesperrt.

Auch wenn mehrere Domains tatsächlich miteinander verbunden sind, muss weiterhin bewertet werden, was auf den einzelnen Domains passiert und welche Maßnahme im jeweiligen Fall angemessen ist.

Eine Suspendierung kann am Ende sinnvoll sein, ist aber nicht das automatische Ergebnis eines ADC.

Welche Informationen können bei Associated Domain Checks genutzt werden?

Auch hier versucht der aktuelle Entwurf, die Anforderungen realistisch zu halten.

Ein Registrar soll grundsätzlich mit Informationen arbeiten, die ihm im normalen Geschäftsbetrieb vernünftigerweise zur Verfügung stehen. Dazu können beispielsweise Account- und Registrierungsinformationen, technische Daten sowie Erkenntnisse aus Abuse-Meldungen gehören.

Es soll dagegen keine Pflicht entstehen, für jeden Fall völlig neue Datenbestände aufzubauen oder Informationen zu beschaffen, auf die der Registrar sonst keinen vernünftigen Zugriff hätte.

Gleichzeitig bleibt Datenschutz ein zentraler Faktor. Ein zukünftiger ADC wäre kein Freibrief, vorsorglich möglichst viele Kundendaten zu sammeln oder miteinander zu verknüpfen. Der Entwurf betont ausdrücklich Verhältnismäßigkeit und Datenminimierung.

Gerade für europäische Anbieter ist das relevant, denn eine mögliche ICANN-Verpflichtung würde selbstverständlich nicht dazu führen, dass geltendes Datenschutzrecht plötzlich keine Rolle mehr spielt.

Muss das komplette Domain-Portfolio geprüft werden?

Auch das ist nicht vorgesehen.

Der Umfang eines Associated Domain Checks soll sich am konkreten Fall orientieren. Bei einem kleinen und klar abgegrenzten Vorfall kann eine begrenzte Untersuchung ausreichend sein. Gibt es dagegen Hinweise auf eine größere koordinierte Phishing- oder Malware-Kampagne, kann eine breitere Prüfung sinnvoll werden.

Es geht also nicht darum, bei jedem Abuse-Fall automatisch zehntausende oder hunderttausende Domains zu analysieren.

Die Untersuchung soll nur so weit gehen, wie es aufgrund der vorhandenen Informationen vernünftig und verhältnismäßig erscheint.

Wie schnell müsste ein ADC durchgeführt werden?

Der aktuelle Entwurf verzichtet bewusst auf eine starre Frist von beispielsweise zwei, zwölf oder 24 Stunden.

Stattdessen soll ein ADC promptly, also ohne unangemessene Verzögerung, durchgeführt werden. Was das konkret bedeutet, hängt vom jeweiligen Fall ab.

Eine aktive Phishing-Kampagne mit erheblichem Schadenspotenzial verlangt verständlicherweise schnelleres Handeln als eine komplexe Untersuchung, bei der zunächst mehrere technische Zusammenhänge geprüft werden müssen.

Der vorgeschlagene Ansatz versucht deshalb, Geschwindigkeit und Sorgfalt miteinander zu verbinden.

Automatisierung bei Associated Domain Checks

Bei großen Portfolios dürfte Automatisierung eine wichtige Rolle spielen.

Software kann beispielsweise erkennen, welche Domains demselben Account zugeordnet sind, welche Namensmuster sich wiederholen oder welche technische Infrastruktur gemeinsam verwendet wird. Solche Werkzeuge können die Analyse erheblich beschleunigen.

Problematisch wäre jedoch ein zu simpler Automatismus.

Wenn eine Domain für Phishing verwendet wird, dürfen nicht automatisch alle ähnlich aussehenden Domains oder sämtliche Domains mit demselben Nameserver als missbräuchlich eingestuft werden.

Gerade bei Shared Hosting, White-Label-Resellern, Agenturen und großen DNS-Plattformen würde das zu zahlreichen Fehlzuordnungen führen.

Automatisierung kann Beziehungen sichtbar machen und Hinweise liefern. Die eigentliche Bewertung muss trotzdem berücksichtigen, warum Domains miteinander verbunden erscheinen und ob tatsächlich belastbare Anzeichen für DNS Abuse vorhanden sind.

Was können Reseller und Agenturen schon heute tun?

Noch besteht kein Grund, aufgrund des aktuellen Initial Reports neue technische Pflichtprozesse einzuführen.

Trotzdem lohnt es sich, die eigenen Strukturen einmal aus dieser Perspektive zu betrachten.

Wenn bei Euch ein ernster Abuse-Fall auftritt, sollte nachvollziehbar sein, welcher Endkunde hinter der betroffenen Domain steht, welche weiteren Domains tatsächlich zu diesem Kunden gehören und welche lediglich dieselbe technische Infrastruktur verwenden.

Ebenso sollte eine dringende Abuse-Meldung nicht tagelang zwischen allgemeinem Support und Technik liegen bleiben, weil intern niemand weiß, wer zuständig ist.

Solche Prozesse helfen unabhängig davon, wie die endgültige ICANN-Policy später aussehen wird.

Für Agenturen gilt im Grunde dasselbe. Wer Domains verschiedener Kunden zentral verwaltet, sollte diese Beziehungen sauber dokumentieren können. Für Domainer mit größeren Portfolios lohnt es sich ebenfalls, Registrierung, Nutzung und Accountstruktur so nachvollziehbar zu halten, dass legitime Portfolio-Strukturen von tatsächlichen Missbrauchsmustern unterschieden werden können.

Gelten Associated Domain Checks auch für .de-Domains?

Nicht aufgrund dieses Policy-Prozesses.

Associated Domain Checks werden derzeit innerhalb der Generic Names Supporting Organization, kurz GNSO, diskutiert. Damit geht es um den ICANN-regulierten Bereich der generischen Top-Level-Domains, also gTLDs.

Country-Code-Domains wie .de, .at oder .ch unterliegen dagegen den Regeln ihrer jeweiligen Registry sowie dem jeweiligen rechtlichen Rahmen.

Gerade Reseller mit einem breiten TLD-Portfolio sollten deshalb nicht davon ausgehen, dass eine spätere ICANN-Regel automatisch für jede angebotene Domainendung identisch gilt.

Associated Domain Checks: Was gilt schon und was noch nicht?

Die verschärften DNS-Abuse-Pflichten für Registrare gelten bereits seit April 2024.

Associated Domain Checks dagegen noch nicht.

Der aktuelle Initial Report vom August 2026 enthält lediglich vorläufige Empfehlungen. Die öffentliche Kommentierungsphase läuft bis zum 28. September 2026. Anschließend kann die Working Group Änderungen vornehmen, bevor ein Final Report entsteht.

Erst danach folgen weitere Schritte im GNSO- und ICANN-Prozess.

Es wäre deshalb falsch zu behaupten, Reseller oder Registrare müssten heute bereits zwingend ADCs durchführen.

Genauso wenig sollte man das Thema allerdings als rein theoretische Diskussion abtun. Die Vorschläge sind konkret, Reseller werden ausdrücklich berücksichtigt und die grundsätzliche Richtung ist klar erkennbar.

Warum das Thema für die Domainbranche wichtig ist

Bislang wird DNS Abuse häufig aus Sicht einer einzelnen Domain betrachtet. Die aktuelle Diskussion verschiebt den Fokus stärker in Richtung Kampagnen und zusammenhängende Strukturen.

Das ist nachvollziehbar. Professionelle Angreifer können ganze Domainbestände vorbereiten und einzelne Domains nach Bedarf aktivieren. Wird immer nur auf die gerade entdeckte Domain reagiert, kann die restliche Infrastruktur einer Kampagne länger bestehen bleiben.

Associated Domain Checks könnten dabei helfen, solche Strukturen früher zu erkennen.

Gleichzeitig muss verhindert werden, dass legitime Kunden durch zu einfache Korrelationsregeln betroffen sind. Gerade für Reseller, Agenturen und Domainer ist dieser Balanceakt wichtig, weil große Mengen vollkommen legitimer Domains häufig gemeinsame technische Merkmale besitzen.

Fazit: Associated Domain Checks brauchen Kontext

Associated Domain Checks verfolgen eine nachvollziehbare Idee: Wenn eine missbräuchliche Domain offensichtlich Teil einer größeren Struktur ist, sollte man nicht zwangsläufig warten, bis jede weitere Domain einzeln gemeldet wird.

Die entscheidende Frage lautet aber nicht einfach, welche Domains ähnlich aussehen oder dieselben Nameserver verwenden.

Es geht darum, ob belastbare Hinweise auf einen echten Zusammenhang vorliegen – und anschließend darum, ob die weiteren Domains tatsächlich ebenfalls für DNS Abuse genutzt werden.

Genau deshalb trennt der aktuelle ICANN-Entwurf bewusst zwischen Association und Abuse.

Für Reseller könnten dadurch künftig zusätzliche Anforderungen an Zusammenarbeit und Nachvollziehbarkeit entstehen. Agenturen profitieren von klaren Kundenzuordnungen und sauber getrennten Infrastrukturen. Domainer wiederum sollten wissen, dass ein großes oder technisch einheitliches Portfolio nicht automatisch verdächtig ist.

Stand September 2026 sind Associated Domain Checks weiterhin ein Policy-Vorschlag und keine bereits geltende Pflicht.

Trotzdem zeigt die Diskussion eine grundsätzliche Entwicklung: DNS Abuse wird zunehmend nicht nur auf Ebene einer einzelnen Domain betrachtet, sondern als möglicher Bestandteil einer größeren Kampagne.

Die entscheidende Frage verändert sich damit von:

„Was machen wir mit dieser Domain?„

zu:

„Gehört diese Domain möglicherweise zu etwas Größerem?„