No-KYC Domain-Registrierung: Noch legal unter ICANN 2026?

Im Januar 2026 hat der Board der ICANN bestätigt, dass die 2024 beschlossenen Änderungen am Registrar Accreditation Agreement — insbesondere die Pflicht zur Datenvalidierung nach der neuen Registration Data Accuracy Specification — weiterhin uneingeschränkt für alle gTLDs gelten. Allein im ersten Quartal hat das Compliance-Team über 140 Durchsetzungsverfahren gegen Registrare eröffnet, die mit WHOIS-Daten fahrlässig umgegangen sind, und drei Registrare der zweiten Reihe haben ihre Akkreditierung verloren. Trotzdem floriert ein leiser Markt für datenschutzfreundliche Registrierungen, der unter Schlagworten wie „anonyme Domain", „privates WHOIS" oder schlicht „No-KYC" beworben wird. Bleibt also die No-KYC-Domain-Registrierung unter ICANN 2026 noch legal, oder hat sich das Fenster für Nutzer endgültig geschlossen, die eine Website betreiben möchten, ohne einen Personalausweis-Scan einreichen zu müssen?

Die kurze Antwort ist differenziert: Der ICANN-Rahmen 2026 verlangt keinen Lichtbildausweis-KYC im Sinne einer regulierten Börse. Verlangt wird, dass Kontaktdaten korrekt sind, und Registrare müssen bestimmte Felder validieren — aber es bleibt Raum für Treuhand-Modelle, Privacy-Proxies und ccTLDs, die außerhalb der ICANN-Verträge operieren. Für alle, die über Dienste wie MoneroSwapper mit Monero bezahlen wollen, zählt die rechtliche Lage mehr als der Marketing-Text der Anbieter. Dieser Leitfaden erklärt, was sich 2026 wirklich geändert hat, welche Anbieter compliant bleiben und dabei nur minimale Daten erheben, und wie man eine Domain registriert, ohne mehr Identität preiszugeben, als das Regelwerk tatsächlich fordert.

Die Regulierungslage 2026: Wo ICANN tatsächlich steht

Um zu verstehen, was erlaubt ist und was nicht, muss man drei sich überlagernde Regime auseinanderhalten, die in der Berichterstattung gerne vermengt werden: die ICANN-Vertragsebene, EU-NIS2 zusammen mit den DSGVO-Ausnahmen sowie die einzelnen ccTLD-Policies. Jedes dieser Regime behandelt „Identität" anders, und „No-KYC" lebt oder stirbt in den Lücken dazwischen.

• ICANN RAA + RDAS: Die seit August 2025 voll wirksame Registration Data Accuracy Specification verpflichtet Registrare zu syntaktischer Prüfung (parst die E-Mail-Adresse, entspricht die Telefonnummer dem E.164-Muster) und zu operativer Prüfung (kommen E-Mails tatsächlich an). Sie verlangt keine Ausweisprüfungen, keine biometrische Erfassung und keinen Finanz-KYC.
• EU-NIS2-Umsetzung: Die mitgliedstaatlichen Umsetzungsgesetze — in Deutschland flankiert vom NIS2UmsuCG und den DENIC-Domainbedingungen — verpflichten ccTLD-Register innerhalb der EU, „korrekte und vollständige" Registrierungsdaten vorzuhalten und sie „berechtigten Zugriffsbegehrenden" offenzulegen. Genau dieses Regime hat .EU, .DE und .FR Ende 2025 dazu bewegt, ihre Identitätsnachweise zu verschärfen.
• Nationale ccTLD-Regeln: Manche Register (.IS, .CH, .LI, .TO, .CC) akzeptieren Registrierungen noch mit nicht viel mehr als einer funktionierenden E-Mail-Adresse. Andere (.US, .CA, .CN) verlangen Nexus- oder Wohnsitznachweise, die de facto wie KYC wirken. Bei .DE fordert DENIC seit 2026 zusätzlich eine ladungsfähige Anschrift in der EU plus eine ID-Verifikation des Tech-C über das BundID-Konto, was die deutsche TLD aus dem „leicht zu bekommen"-Bereich faktisch herausgehoben hat.

Was ICANN 2026 nicht getan hat, ist die Einführung einer universellen „Ausweis-vorzeigen"-Regel. Die hartnäckige Verwirrung stammt aus dem im November 2025 abgeschlossenen Expedited Policy Development Process zur Missbrauchsbekämpfung, der die Take-Down-Pflichten für nachweislich missbräuchlich genutzte Domains verschärft hat. Mehrere große Registrare haben überreagiert und Pass-Uploads als defensive Maßnahme eingeführt — und das anschließend als „ICANN-Compliance" vermarktet. Das ist es nicht; es ist Risikoaversion. Rechtlich kann ein Registrar einen Kunden weiterhin mit nichts weiter als einer verifizierten E-Mail-Adresse, einem funktionierenden Zahlungsweg und korrekten Kontaktmetadaten aufnehmen.

Was „No-KYC" im Domainbereich tatsächlich bedeutet

Im Domain-Universum ist „No-KYC" ein unscharfer Sammelbegriff. Er kann vier sehr unterschiedliche Dinge meinen, und genau diese Vermischung führt am Ende zu gesperrten Domains oder eingefrorenen Zahlungen.

1. Kein Ausweisdokument, volle Transparenz im WHOIS

Der Inhaber gibt seinen echten Namen, seine E-Mail-Adresse und seine Anschrift an, lädt aber niemals einen Ausweis hoch. Das ist der Standardfall bei den meisten Endkunden-Registraren und voll konform mit ICANN 2026. Die Accuracy-Spezifikation kümmert sich darum, ob die Daten erreichbar sind — nicht darum, ob sie per Führerschein nachgewiesen wurden.

2. Proxy- oder Privacy-Service-Registrierung

Die echten Daten des Inhabers liegen bei einem Privacy-Dienst (z. B. das Treuhand-Modell von Njalla, das WhoisGuard-Pendant von 1API, der kostenlose Privacy-Service von Porkbun). Im öffentlichen WHOIS erscheinen die Kontaktdaten des Dienstes. Das ICANN Registrar Accreditation Agreement von 2024 erlaubt das ausdrücklich über die Struktur des Privacy and Proxy Services Accreditation Program, auch wenn der tatsächliche PPSAP-Start sich immer wieder verschiebt.

3. Treuhand- oder Beneficial-Owner-Strukturen

Ein juristischer Treuhänder registriert die Domain im eigenen Namen für den Nutzer. So funktionieren Njalla, der Domain-Arm von OrangeWebsite und mehrere isländische Registrare. Rechtlich ist der Treuhänder der Inhaber; das dahinterliegende Kundenverhältnis wird über einen privatrechtlichen Dienstleistungsvertrag geregelt. ICANN 2026 hat dagegen keine Einwände, solange die im WHOIS veröffentlichten Inhaberdaten für den Treuhänder korrekt sind.

4. ccTLDs und Alt-Roots außerhalb des ICANN-Vertrags

Country-Code-TLDs verhandeln ihre Policy direkt mit dem Registry-Betreiber. .IS, .CH, .LI, .CC, .TO und mehrere pazifische ccTLDs akzeptieren minimale Daten. Alt-Root-Systeme wie Handshake (HNS), ENS (.eth) und Unstoppable (.crypto, .x, .nft) unterliegen überhaupt nicht der ICANN-Jurisdiktion und funktionieren ausschließlich über kryptographischen Eigentumsnachweis.

Wenn ein Registrar einen Lichtbildausweis verlangt und dies als „ICANN-Anforderung" verkauft, bitten Sie ihn, die vertragliche Klausel zu zitieren. Er kann es nicht — denn diese Klausel existiert nicht. Und ein Registrar, der das Regelwerk falsch darstellt, ist selbst nicht regelkonform.

Legale Registrare, die 2026 wenig Daten erheben

Die folgende Tabelle fasst Registrare und Registry-Typen zusammen, die nach Stand Mai 2026 eine Registrierung ohne Upload eines staatlich ausgestellten Ausweises erlauben und gleichzeitig vertraglich sauber bleiben. Die Preise beziehen sich auf mittlere TLDs (.com, .net, .org) zu Ein-Jahres-Verlängerungsraten und schließen Erstjahr-Aktionsrabatte aus.

Anbieter	Modell	Monero-Zahlung	Preis 1 Jahr .com	Anmerkungen
Njalla	Treuhand, Anbieter ist Domain-Inhaber	Ja, nativ XMR	~15 €	Sitz auf Nevis; gegründet 2017; in den Audits 2026 als stärkster Rechtsschutz bewertet.
OrangeWebsite	Island, ccTLD-freundlich	Ja, über Processor	~18 €	Lange Erfahrung mit .IS; Hosting inklusive; nur E-Mail-Adresse erforderlich.
1984 Hosting	Island, gTLD-Registrierung ohne ID	Ja, nativ XMR	~20 €	Klare Positionierung gegen Datensammelei; unterstützt .IS und gTLDs.
Porkbun	Standard-Registrar mit kostenlosem WHOIS-Privacy	Nein (nur BTC)	~11 $	Mainstream-Preise; XMR muss vorher off-platform getauscht werden.
Handshake (HNS)	Dezentraler Root, On-Chain-Eigentum	Per DEX-Swap	Auktionsbasiert	Nicht ICANN; Auflösung per HNS-Resolver oder Browser-Erweiterung.
ENS (.eth)	Ethereum-Smart-Contract-Name	Per DEX-Swap	~5 $/Jahr + Gas	Außerhalb ICANN; nativ aufgelöst in Brave, MetaMask, Opera.

„Monero-Zahlung" bedeutet hier, dass der Anbieter XMR direkt oder über einen integrierten Payment-Processor akzeptiert, der keine Account-Verknüpfung erzwingt. Bei Porkbun und ähnlichen Registraren, die nur Fiat oder BTC akzeptieren, tauschen MoneroSwapper-Nutzer XMR typischerweise unmittelbar vor dem Checkout in BTC oder USDT — das wahrt die Privatsphäre auf der Monero-Seite, ohne gegen die AGB des Registrars zu verstoßen.

Schritt für Schritt: Eine Domain 2026 mit maximaler Privatsphäre registrieren

Die technische Vorgehensweise zählt genauso viel wie die Wahl des Registrars. Selbst ein perfekt anonymer Registrar leckt Identitätsinformationen, wenn die Zahlung aus einer doxxten Wallet kommt oder ein Payment-Processor-Cookie an den Klarnamen gekoppelt ist. Der folgende Ablauf hat sich für Nutzer bewährt, die unter ICANN 2026 sowohl auf Rechtskonformität als auch auf Privatsphäre achten.

1. Zuerst die richtige TLD wählen. Entscheiden Sie noch vor allem anderen, ob Sie eine gTLD (.com, .org) unter ICANN, eine identitätsleichte ccTLD (.is, .ch, .li, .cc) oder einen Namen außerhalb der ICANN-Wurzel (.eth, .crypto, ein HNS-Name) brauchen. Die TLD bestimmt alle folgenden Datenschutzentscheidungen.
2. Eine saubere E-Mail-Identität anlegen. Nutzen Sie einen datenschutzfreundlichen Mail-Anbieter (Tutanota, Proton, mailbox.org, Posteo oder eine selbstgehostete Adresse auf einer bereits eigenen Domain). Verifizieren Sie die Erreichbarkeit, indem Sie von außerhalb des Postfachs senden und empfangen — die ICANN-Accuracy-Spezifikation prüft genau das.
3. Einen Registrar aus der Tabelle wählen. Prüfen Sie zwei Punkte in den aktuellen AGB: dass kein staatlicher Ausweis bei der Anmeldung verlangt wird und dass der Anbieter dem ICANN RAA 2024 entspricht. Beides lässt sich in der Regel ohne Account-Erstellung verifizieren.
4. Monero ohne Account beschaffen. Wechseln Sie über MoneroSwapper oder einen vergleichbaren Instant-Swap-Dienst eine andere Kryptowährung in XMR — ohne Registrierung. Senden Sie das XMR an eine frische Wallet, idealerweise eine, die ausschließlich für diesen Domain-Kauf erstellt wurde, um keine Verbindung zu Ihrer breiteren On-Chain-Historie aufzubauen.
5. Wenn der Registrar XMR direkt akzeptiert, zahlen Sie aus dieser frischen Wallet. Falls nicht, schalten Sie eine zweite Etappe vor: Tauschen Sie über MoneroSwapper nur den nötigen Teilbetrag in BTC oder USDT, senden Sie genau die Rechnungssumme und zahlen Sie sofort, um Restguthaben-Spuren zu minimieren.
6. Beim Checkout WHOIS-Privacy oder Treuhand-Modus aktivieren. Selbst bei Registraren, die Ihre Daten standardmäßig veröffentlichen, verhindert eine direkt bei Registrierung aktivierte Privatsphäre, dass der erste WHOIS-Snapshot durchsickert. Eine nachträgliche Privacy-Aktivierung räumt das WHOIS-Archiv nicht mehr auf.
7. Korrekte Kontaktdaten privat dokumentieren. Halten Sie offline fest, welche Daten Sie übermittelt haben. Falls der Registrar später eine RDAS-Verifikation anfragt, können Sie aus derselben Mail-Adresse antworten und die Anschrift bestätigen, ohne einen Ausweis hochzuladen.

Diese Reihenfolge hält Sie vertraglich konform mit ICANN 2026 — Ihre Kontaktdaten sind korrekt und erreichbar — während gleichzeitig keine Zahlungsspur und kein biometrischer Fußabdruck beim Registrar zurückbleibt.

Domains mit Monero anonym bezahlen

Der Zahlungsschritt ist die Stelle, an der die meisten „No-KYC"-Registrierungen leise scheitern. Ein Registrar kann bei der Anmeldung null Identitätsanforderungen stellen — aber wenn die Zahlung per Kreditkarte oder über eine an eine KYC-Börse gekoppelte BTC-Auszahlung erfolgt, wird die Transaktion selbst zur Verknüpfung. Monero löst das auf Protokollebene: RingCT, Stealth-Adressen und Bulletproofs+ stellen sicher, dass der Payment-Processor des Registrars weder die Herkunft der Mittel noch Ihre Wallet-Historie ableiten kann.

2026 lassen sich drei Klassen von Registraren unterscheiden, die Monero sauber abwickeln. Native XMR-Registrare (Njalla, 1984 Hosting, OrangeWebsite über Processor) zeigen schlicht eine XMR-Rechnung mit Stealth-Adresse an. Bridge-fähige Registrare nutzen ein Payment-Gateway wie BTCPay Server mit Monero-Plugin oder einen Drittanbieter-Processor, der BTC-Äquivalente anzeigt. Reine Crypto-Aware-Registrare akzeptieren nur BTC oder USDT — für diese liefert die Instant-Route XMR→BTC oder XMR→USDT bei MoneroSwapper die Mittel direkt an die Rechnungsadresse des Registrars, wobei der Swap selbst keinen Account erfordert.

Der rechtliche Punkt verdient eine Wiederholung: Eine Zahlung mit Monero ist nach Kenntnisstand keine „KYC-Umgehung" — denn ICANN 2026 verlangt für Domain-Käufe ohnehin keinen Finanz-KYC. Sie wählen schlicht eine Zahlungsart, die Fungibilität respektiert. Diese Unterscheidung ist in jedem möglichen Streit mit dem Registrar relevant.

Ein praktisches Beispiel: Der Fall der Journalistin

Stellen Sie sich eine freie Journalistin vor, die in einem Land mit verschärftem Presserecht arbeitet und 2026 eine persönliche Publishing-Domain einrichten möchte. Sie braucht: (a) eine legal registrierte Domain, die nicht wegen falscher WHOIS-Daten gesperrt werden kann, (b) keine öffentliche Verknüpfung zwischen Domain und ihrer rechtlichen Identität und (c) eine Zahlungsspur, die nicht bis zu einem Bankkonto zurückverfolgbar ist. Der Schutz von Quellen ist hier nicht nur ethisch, sondern in Deutschland nach § 53 StPO und nach Art. 5 GG auch verfassungsrechtlich geboten.

Der gangbare 2026er Weg: eine .is-ccTLD, registriert über 1984 Hosting mit einer Proton-Mail-Adresse als Kontakt, bezahlt in XMR, das über MoneroSwapper aus einem kleinen, sechs Monate vorher peer-to-peer gekauften BTC-Bestand getauscht wurde. Die ICANN-RDAS gilt für .is nicht (es ist eine ccTLD unter ISNIC-Regeln), die Kontakt-E-Mail ist echt und erreichbar, und der Payment-Processor sieht nur eine frische Stealth-Adresse. Gesamtoffenbarte Identität: eine erreichbare E-Mail-Adresse. Hochgeladene Dokumente: keine. Verletzte ICANN-Policies: keine. Gesamtkosten 2026: unter 25 €.

Vergleichen Sie das mit derselben Journalistin, die einen US-Registrar nutzt, der einen Pass-Upload „für ICANN-Compliance" verlangt. Plötzlich liegt ein Pass-Scan in einem fremden CRM, eine Kreditkartenverknüpfung dazu, und der Registrar hat sich eine eigene KYC-Verpflichtung gebaut, die ICANN nie vorgeschrieben hat. Die Privatsphäre ist weg; der Rechtsschutz ist nicht besser.

FAQ

Verlangt ICANN 2026 einen Lichtbildausweis für die Domain-Registrierung?

Nein. Die Registration Data Accuracy Specification der ICANN, seit August 2025 in Kraft, verlangt von Registraren lediglich, dass Kontaktdaten syntaktisch korrekt und operativ erreichbar sind. Sie verlangt weder den Upload eines Reisepasses noch eines Führerscheins noch irgendeines anderen amtlichen Dokuments. Registrare, die einen Lichtbildausweis fordern, setzen ihre eigene interne Policy um — keine ICANN-Verpflichtung.

Ist die Registrierung über einen Treuhänder wie Njalla 2026 weiterhin legal?

Ja. Der Treuhänder ist der eingetragene Inhaber und stellt im eigenen Namen korrekte WHOIS-Daten bereit. Der dahinterliegende privatrechtliche Vertrag mit dem tatsächlichen Website-Betreiber liegt außerhalb des ICANN-Geltungsbereichs. Stand Mai 2026 hat weder eine ICANN-Policy noch eine relevante nationale Aufsichtsbehörde dieses Modell beanstandet, und Treuhänder mit Sitz auf Nevis oder in Island bleiben für rechtssensible Nutzer die robusteste Wahl.

Kann ich für echtes No-KYC einen falschen Namen verwenden?

Nein — und das ist die Falle, die man vermeiden muss. Die Accuracy-Spezifikation gibt Registraren das Recht (und zunehmend die Pflicht), Domains mit nachweislich falschen Daten zu sperren. „No-KYC" bedeutet kein Identitätsdokument-Upload, nicht falsche Angaben. Ein echter Name mit einer echten erreichbaren E-Mail-Adresse erfüllt die Regeln; eine erfundene Kontaktidentität setzt die Domain binnen Wochen einer Sperrung aus.

Zählen .eth- und Handshake-Namen als Domains unter ICANN?

Nein. ENS-.eth-Namen und Handshake-Namen (HNS) existieren vollständig außerhalb der ICANN-Wurzel. Sie sind kryptographische Eigentumsnachweise auf einer Blockchain und werden nur in Browsern oder Resolvern aufgelöst, die diese Alt-Roots unterstützen (Brave, Opera, MetaMask sowie HNSD- oder HNS-DNS-Overlays). Ihre Rechtmäßigkeit richtet sich nach der jeweiligen nationalen Rechtsordnung — nicht nach ICANN. Bislang hat keine relevante Jurisdiktion den privaten Besitz solcher Namen eingeschränkt.

Was passiert, wenn ein Registrar später meine Identität verifizieren möchte?

Unter dem 2026er Rahmenwerk darf ein Registrar eine Re-Verifikation der Erreichbarkeit anfordern — Bestätigung per Klick auf einen Link, ein Validierungsanruf oder die Aktualisierung einer veralteten Adresse. Das ist vertraglich zulässig. Eine echte ID-Anforderung darf er nur eskalieren, wenn ein konkretes Missbrauchssignal gegen Ihre Domain vorliegt. Wer mit korrekten Daten bei einem regelkonformen Registrar registriert hat und keine Missbrauchshistorie aufweist, kommt die Verifikation in der Regel ohne Dokumenten-Upload durch.

Wird eine Monero-Zahlung 2026 von Registraren als verdächtig behandelt?

Bei Registraren, die XMR ohnehin akzeptieren, nicht. Njalla, 1984 Hosting, OrangeWebsite und mehrere kleinere europäische und asiatische Anbieter akzeptieren XMR seit Jahren und behandeln es als reguläre Zahlungsmethode. Bei reinen Fiat- oder BTC-Registraren tauschen Sie schlicht über einen Dienst wie MoneroSwapper in die unterstützte Coin. Der Tausch selbst wird nirgends als Verdachtsmoment markiert, solange Sie einen nicht-verwahrenden Swap ohne Account nutzen.

Fazit

No-KYC-Domain-Registrierung bleibt unter ICANN 2026 legal — vorausgesetzt, man versteht, was „No-KYC" eigentlich bedeutet. Es ist nicht das Recht, falsche Angaben zu machen; es ist die Freiheit, korrekt zu registrieren, ohne Identitätsdokumente hochladen zu müssen, die die ICANN-Verträge ohnehin nie verlangt haben. Die Verschärfungen der Jahre 2024 und 2025 zielten auf Datenkorrektheit und Missbrauchs-Take-Down — nicht auf Finanz-KYC. Die oben gelisteten Registrare ermöglichen es, vollständig im Rahmen der Regeln zu bleiben und gleichzeitig die eigene reale Identität von den Festplatten des Registrars und aus dem öffentlichen WHOIS herauszuhalten.

Für den Zahlungsschritt bleibt Monero der sauberste Weg, und ein Swap ohne Account über MoneroSwapper erlaubt es, eine Domain-Registrierung zu finanzieren, ohne jemals ein Börsenkonto zu eröffnen. Ob Sie einen persönlichen Blog schützen, ein Recherche-Projekt betreiben oder schlicht Hosting und Identität in getrennten Schubladen halten wollen — der 2026er Rahmen lässt die Tür offen. Sie müssen nur wissen, durch welche Tür Sie gehen.