--- id: "domain-transfer" kind: "glossary-term" title: "Domaintransfer" language: "de" category: "Transfers und EPP" updated: "2026-10-10T23:12:43Z" canonical: "https://tldlog.com/de/glossar/domaintransfer/" translations: en: "https://tldlog.com/glossary/domain-transfer/" es: "https://tldlog.com/es/glosario/transferencia-dominio/" fr: "https://tldlog.com/fr/glossaire/transfert-nom-domaine/" it: "https://tldlog.com/it/glossario/trasferimento-dominio/" pt-BR: "https://tldlog.com/pt/glossario/transferencia-dominio/" ru: "https://tldlog.com/ru/glossariy/perenos-domena/" zh-Hans: "https://tldlog.com/zh/cihui/yuming-zhuanyi/" --- # Domaintransfer Der Umzug eines Domainnamens von einem Registrar zu einem anderen, oft wegen eines besseren Service oder Preises. Der Inhaber entsperrt den Namen, besorgt sich den Auth-Code und beauftragt den neuen Registrar, den Transfer zu starten. In gTLDs verlängert ein Transfer die Laufzeit meist um ein Jahr. Ein Inhaberwechsel ist ein eigener Vorgang. Ein Domaintransfer verschiebt einen Domainnamen von einem Registrar, dem Unternehmen, das ihn für den Inhaber verwaltet, zu einem anderen. Der Inhaber bleibt derselbe; nur das Unternehmen wechselt. Für gTLDs wie .com legen die Regeln der ICANN fest, wer was bis wann tut. ## Was ein Domaintransfer ist und was nicht Der abgebende Registrar übergibt den Namen an den aufnehmenden Registrar. Für gTLDs gibt die Transfer Policy der ICANN, in Kraft seit dem 12. November 2004, Inhabern das Recht auf einen Transfer, und nur der Inhaber kann ihn genehmigen oder ablehnen. Stand Oktober 2026 gilt die am 21. Februar 2024 aktualisierte Fassung, verbindlich seit dem 21. August 2025. Ein Transfer ist weder ein Inhaberwechsel (Change of Registrant), für den eigene Regeln gelten, noch ein Wechsel des Webhostings, für den kein Transfer nötig ist. Länderspezifische TLDs legen eigene Regeln fest. Bei .eu dient ein Code für einen neuen Registrar, einen neuen Inhaber oder beides, und ein Registrar-Lock blockiert ihn nicht. Für .es legt Red.es das Verfahren fest. ## Vor dem Start: Sperren, Auth-Code und die 60-Tage-Regel Der abgebende Registrar muss zwei Dinge bereitstellen: - **Einen entsperrten Namen.** Der Registrar-Lock clientTransferProhibited lässt die Registry Transfers ablehnen. Ein Registrar darf sie nur bei der Registrierung oder auf Wunsch des Inhabers setzen, nach Bedingungen im Registrierungsvertrag. - **Den Auth-Code.** Ein geheimer, für jede Domain eigener Code, den der Inhaber dem neuen Registrar gibt. Ohne Selbstbedienungswerkzeug muss der Registrar beides innerhalb von fünf Kalendertagen nach der Anfrage bereitstellen. Er darf das nicht schwieriger machen als eine Änderung der Kontakt- oder Nameserver-Daten und es nicht wegen eines Zahlungsstreits zurückhalten. Stand Oktober 2026 gelten zwei Fristen von 60 Tagen. Ein Registrar darf einen Transfer innerhalb von 60 Tagen nach der Erstellung des Namens oder einem vorherigen Transfer ablehnen. Nach einem Inhaberwechsel (einer wesentlichen Änderung von Name, Organisation oder E-Mail-Adresse des Inhabers) muss er eine 60-tägige Transfersperre verhängen, sofern der Inhaber nicht vorher per Opt-out darauf verzichtet hat. Die Policy rät, zuerst zu transferieren und den Inhaber danach zu ändern. Abgelaufene Namen können transferiert werden, sofern kein früherer Zeitraum unbezahlt ist; ein Name in der Redemption Grace Period muss aber zuerst wiederhergestellt werden, was eine Gebühr kosten kann. ## Schritt für Schritt: vom Antrag bis zum Abschluss 1. Der Inhaber entsperrt den Namen und erhält den Auth-Code. 2. Der Inhaber beauftragt den Transfer beim neuen Registrar und gibt ihm den Code. 3. Die Registry prüft den Code und benachrichtigt beide Registrare. Die Domain zeigt pendingTransfer. 4. Innerhalb von 24 Stunden bittet der abgebende Registrar den Inhaber mit der FOA um Bestätigung. 5. Der abgebende Registrar genehmigt oder lehnt ab. Antwortet er nicht innerhalb von fünf Kalendertagen, schließt die Registry den Transfer ab. 6. Der Registrierung wird ein Jahr hinzugefügt, bis zu insgesamt zehn Jahren. Das sind Höchstfristen, keine typischen Zeiten. Stand Oktober 2026 setzt die ICANN die eigene FOA des aufnehmenden Registrars seit dem 26. Januar 2020 nicht mehr durch. Ein Beispiel: Der aufnehmende Registrar stellt an einem Montag einen Antrag für example.com. Bleibt der abgebende Registrar still, ist der Umzug fünf Kalendertage später abgeschlossen, und das Ablaufdatum verschiebt sich um ein Jahr. Hätte der Inhaber in der Woche davor die E-Mail-Adresse des Inhabers geändert, ohne per Opt-out zu verzichten, würde der Transfer abgelehnt. ## Was es kostet Registrare legen ihre Transferpreise selbst fest, doch ein Transfer darf nicht abgelehnt werden, weil diese Gebühr unbezahlt ist. Die Regeln der Registrys können abweichen: Nach dem .net-Vertrag von 2005 hebt ein Transfer während der Auto-Renew Grace Period das automatisch verlängerte Jahr auf und fügt stattdessen eines hinzu. ## Warum ein Transfer abgelehnt werden kann Der abgebende Registrar muss seinen Grund nennen. Stand Oktober 2026 **darf** er ablehnen bei Belegen für Betrug, einem begründeten Streit über die Identität des Inhabers, unbezahlten früheren Zeiträumen (oder, vor dem Ablauf, dem laufenden), einem ausdrücklichen Widerspruch des Inhabers oder innerhalb der 60 Tage nach der Erstellung oder einem vorherigen Transfer. Er **muss** ablehnen während eines ihm bekannten UDRP- oder URS-Verfahrens, aufgrund eines Gerichtsbeschlusses, während eines laufenden Streits über einen früheren Transfer oder während der 60-tägigen Sperre nach einem Inhaberwechsel. Er **darf nicht** ablehnen, weil ein künftiger Zeitraum unbezahlt ist, weil der Inhaber nicht geantwortet hat oder wegen einer Sperre, die der Inhaber nicht aufheben konnte. ## Probleme und Streitigkeiten: was tun, wenn ein Transfer schiefgeht - **Unerwartetes pendingTransfer.** Die ICANN rät, den Registrar sofort zu bitten, den Antrag abzulehnen. - **Strittige Ablehnung oder Sperre.** Der Inhaber kann bei der ICANN eine Transfer Complaint einreichen. - **Notfälle zwischen Registraren.** Jeder Registrar unterhält einen TEAC. Stand Oktober 2026 muss dort innerhalb von 4 Stunden eine Person antworten; Schweigen kann dazu führen, dass der Transfer rückgängig gemacht wird. - **TDRP.** Nur Registrare können ein Verfahren einleiten, innerhalb von 12 Monaten, bei einem zugelassenen Anbieter (Stand Oktober 2026 das ADNDRC oder Forum, früher National Arbitration Forum). Ein unwirksamer Transfer wird an den abgebenden Registrar zurückgegeben. Der Rechtsweg bleibt offen. Wird ein Registrar übernommen oder verliert er seine Akkreditierung, kann die ICANN einen Bulk-Transfer aller seiner Namen genehmigen: kostenlos bis 50.000 Namen, darüber pauschal 50.000 US-Dollar (Stand Oktober 2026). Manche Registrys bieten BTAPPA für einen Teil eines Portfolios an. ## Bevorstehende Änderungen der Transferregeln Am 7. Juni 2026 nahm der ICANN-Vorstand die 47 Empfehlungen der Transfer Policy Review an (Beschluss 2026.06.07.04). Stand Oktober 2026 sind sie **nicht in Kraft**: Die ICANN führt das Projekt als in der Warteschlange, ohne Datum des Inkrafttretens. Nach der Umsetzung sind die wichtigsten Änderungen: - Der Auth-Code wird zum Transfer Authorization Code (TAC): mindestens 128 Bit stark, 336 Stunden (14 Tage) gültig und nur einmal verwendbar. Der Inhaber wird innerhalb von 10 Minuten nach seiner Ausgabe benachrichtigt. - Die FOA des aufnehmenden Registrars entfällt; das Formular des abgebenden Registrars wird zur Transfer Confirmation, ohne Genehmigung per Mausklick. - Eine verpflichtende Sperre von 720 Stunden (30 Tagen) folgt auf die Registrierung und jeden Transfer; nur die Sperre nach einem Transfer darf vorzeitig aufgehoben werden, auf begründeten Antrag, etwa bei einem dokumentierten Verkauf. - Ein Inhaberwechsel bringt keine Sperre mehr mit sich, nur eine Benachrichtigung innerhalb von 24 Stunden, nach einer eigenen Change of Registrant Data Policy. - Registrare dürfen wegen DNS-Missbrauchs ablehnen und müssen ablehnen, wenn der Inhaber widerspricht. - Ein TEAC hat 24 Stunden Zeit für eine Antwort. - BTAPPA wird Teil der Policy und gilt auch für Kunden, die ihr eigenes Portfolio umziehen. ## Quellen - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Registrar Transfer Dispute Resolution Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/registrar-transfer-dispute-resolution-policy-21-02-2024-en) - [Final Report on the Transfer Policy Review Policy Development Process](https://gnso.icann.org/sites/default/files/policy/2025/correspondence/tpr-team-to-gnso-council-04feb25-en.pdf) ## verwandte begriffe - [Auth-Code](https://tldlog.com/de/glossar/auth-code/) - [Transfersperre](https://tldlog.com/de/glossar/transfersperre/) - [Inhaberwechsel](https://tldlog.com/de/glossar/inhaberwechsel/) - [EPP](https://tldlog.com/de/glossar/epp/)