Domain umziehen: Auth-Code, Ablauf und Providerwechsel

Beim Domainumzug wechselt die Domain von einem Anbieter zum anderen. Das kann nötig sein, weil der bisherige Anbieter teurer geworden ist, weil du alle Domains an einem Ort bündeln willst oder weil du mit dem Hosting umziehst. Der Inhaber bleibt dabei derselbe, nur der Anbieter, der die Domain bei der Registry verwaltet, ändert sich. Die Domain selbst bleibt dir erhalten, wenn du die Schritte in der richtigen Reihenfolge gehst. Ärger gibt es meist erst danach, wenn E-Mails nicht mehr ankommen oder die Website nicht lädt, weil DNS-Einträge fehlen.

Eine Abgrenzung vorweg: Willst du die Domain beim bisherigen Anbieter lassen und nur die DNS-Einträge woanders pflegen, reicht ein Nameserverwechsel. Wie das geht, steht unter Nameserver ändern.

Vorbereitung: was du vor dem Umzug sicherst

Viele Anbieter verwalten mit der Domain auch ihre DNS-Einträge auf eigenen Nameservern. Endet der Vertrag, verschwinden diese Einträge oft mit. Bevor du den Umzug startest, solltest du deshalb alle Einträge der Domain notieren oder als Zonendatei exportieren. Wichtig sind vor allem:

• A- und AAAA-Einträge für die Domain, www und alle Subdomains
• MX-Einträge für die E-Mail
• TXT-Einträge für SPF, DMARC und Bestätigungen bei anderen Diensten
• CNAME-Einträge, darunter häufig DKIM-Schlüssel

Lege diese Einträge beim neuen Anbieter an, bevor die Domain umzieht. Wie lange Resolver alte Werte noch im Speicher halten, hängt von der TTL ab. Senkst du sie ein paar Tage vorher, geht der Übergang schneller.

Ist die Domain mit DNSSEC signiert und wechseln mit dem Umzug auch die Nameserver, musst du DNSSEC vorher abschalten. Cloudflare warnt in seiner Anleitung, dass ein Nameserverwechsel bei aktivem DNSSEC die Domain unerreichbar machen kann. DNSSEC lässt sich nach dem Wechsel beim neuen Anbieter wieder einschalten ^[1]. Hintergründe stehen unter DNSSEC: signierte DNS-Antworten.

Umzug einer .de-Domain mit AuthInfo

Bei .de heißt der Auth-Code AuthInfo. Du kannst den Provider jederzeit wechseln ^[2]. Ist der bisherige Provider erreichbar, läuft der Wechsel in vier Schritten ^[2]:

1. Du beauftragst deinen bisherigen Provider, eine AuthInfo zu erzeugen.
2. Der Provider hinterlegt sie verschlüsselt bei der DENIC und teilt sie dir mit.
3. Du gibst die AuthInfo an den neuen Provider weiter.
4. Der neue Provider beantragt mit ihr den Wechsel bei der DENIC. Stimmt die AuthInfo, zieht die Domain sofort um.

Die DENIC speichert nur einen Hash des Codes, kein lesbares Passwort. Eine AuthInfo ist 8 bis 16 Zeichen lang und verfällt nach 30 Tagen automatisch ^[2]. Läuft sie ab, bevor du sie benutzt hast, forderst du einfach eine neue an. Möchtest du gleichzeitig den Inhaber ändern, etwa weil die Domain von einer Privatperson auf eine Firma übergeht, geht das im selben Schritt ^[2].

Wenn der alte Provider nicht reagiert

Manchmal gibt es den alten Provider nicht mehr, oder er antwortet nicht. Dann wendest du dich an den neuen Provider. Er beantragt die AuthInfo direkt bei der DENIC. Die DENIC schickt sie per Einschreiben an die Anschrift, die in den Domaindaten steht, und hinterlegt den Hash ^[2]. Mit diesem Code löst der neue Provider den Wechsel aus. Das klappt nur, wenn deine Anschrift bei der DENIC stimmt. Prüfe deshalb vorher, ob die Inhaberdaten aktuell sind. Liegt die Domain im TRANSIT, weil der alte Provider die Verwaltung aufgegeben hat, bleibt eine von der DENIC erzeugte AuthInfo bis zu ihrem Ablauf gültig ^[2].

Umzug bei .com und anderen generischen Endungen

Für .com, .net, .org und die übrigen generischen Endungen gilt die Transfer Policy der ICANN. Der Ablauf ähnelt dem bei .de, hat aber mehr Fristen und Sperren.

Zuerst brauchst du den Auth-Code. Manche Registrare lassen dich ihn selbst im Kundenkonto erzeugen. Sonst musst du ihn anfordern, und der Registrar muss ihn dir innerhalb von fünf Kalendertagen geben ^{[3, 4]}. Steht die Domain auf clientTransferProhibited, lehnt die Registry jeden Umzug ab. Diese Sperre hebst du im Kundenkonto selbst auf, wenn der Registrar das anbietet. Sonst muss er sie auf deinen Wunsch innerhalb von fünf Kalendertagen aufheben ^{[4, 5]}.

Dann beantragst du den Umzug beim neuen Registrar und gibst den Code ein. Nach dem Wortlaut der Policy muss der neue Registrar deine ausdrückliche Zustimmung einholen, die ICANN setzt diese Pflicht aber seit 2020 vorerst nicht durch ^[4]. Der bisherige Registrar bekommt von der Registry eine Mitteilung über den Umzug. Reagiert er innerhalb von fünf Kalendertagen nicht, gilt der Umzug als genehmigt ^[4].

Bestätigungsmails im Blick behalten

Während des Umzugs bekommst du bei generischen Endungen meist mehrere Mails. Der bisherige Registrar muss dir eine Bestätigungsanfrage schicken, spätestens 24 Stunden nachdem die Registry ihn über den Umzug informiert hat ^[4]. Seit dem 25.05.2018 muss der neue Registrar keine eigene Bestätigung beim Inhaber einholen, wenn er dessen Registrierungsdaten nicht einsehen kann ^[3]. Umso wichtiger ist die Mail des bisherigen Registrars. Sie geht an die Adresse, die dort hinterlegt ist. Prüfe deshalb vor dem Umzug, ob diese Adresse noch funktioniert und ob du sie abrufen kannst. Liegt sie auf der Domain, die du gerade umziehst, und stimmen die Mail-Einträge in der Übergangszeit nicht, erreicht dich die Nachricht womöglich nicht. Bekommst du eine Mail über einen Umzug, den du nicht beauftragt hast, melde dich sofort beim Registrar. Mehr dazu unter Domain-Hijacking verhindern.

Wann ein Umzug abgelehnt werden kann

Die ICANN unterscheidet zwischen Gründen, aus denen der Registrar ablehnen darf, und solchen, aus denen er ablehnen muss ^[3].

Die Sperre nach einem Inhaberwechsel ist die häufigste Überraschung. Ändert sich Name, Organisation oder E-Mail-Adresse des Inhabers, muss der Registrar die Domain 60 Tage lang für Umzüge sperren ^{[3, 6]}. Manche Registrare lassen dich vor der Änderung widersprechen, sie müssen es aber nicht ^[6]. Wer beides vorhat, zieht deshalb besser erst um und ändert danach die Inhaberdaten ^[6]. Eine Ablehnung, nur weil du die Umzugsgebühr des alten Registrars nicht zahlen willst, ist nicht erlaubt ^[3].

Auch eine abgelaufene generische Domain lässt sich in der Regel noch umziehen. Ist sie schon in der Wiederherstellungsfrist, muss der bisherige Registrar sie erst wiederherstellen, was eine zusätzliche Gebühr kosten kann ^[3].

Die ICANN überarbeitet die Transfer Policy gerade. Der GNSO-Rat hat die Empfehlungen der zuständigen Arbeitsgruppe am 12.03.2025 angenommen ^[7]. Der ICANN-Vorstand hat sie am 07.06.2026 beschlossen und die Umsetzung in Auftrag gegeben, allerdings ohne Termin und vorbehaltlich einer Priorisierung ^[13]. Nach der Begründung des Beschlusses machen die Empfehlungen bisher freiwillige Sicherheitssperren verpflichtend. Wie sich das auf die Sperrfristen auswirkt, ist noch offen. Bis die neuen Regeln gelten, bleiben die hier beschriebenen Fristen maßgeblich.

Nach dem Umzug prüfen

1. Prüfe in der Whois-Abfrage, ob der neue Anbieter eingetragen ist.
2. Kontrolliere mit dem DNS-Check, welche Nameserver und Einträge ausgeliefert werden.
3. Rufe die Website auf und schick dir Testmails an jede Adresse der Domain.
4. Schalte DNSSEC beim neuen Anbieter wieder ein, falls du es vorher abgeschaltet hast ^[1].
5. Setze bei generischen Endungen die Transfersperre wieder, damit niemand die Domain ungefragt wegzieht. Mehr Schutz beschreibt Domain-Hijacking verhindern.
6. Kündige erst jetzt den alten Vertrag.

Bei der Kündigung des alten Vertrags hilft unser Schwesterprojekt vertrag-kuendigen.com mit Anleitungen für einzelne Anbieter, etwa IONOS, Strato, united-domains und ALL-INKL.COM. Ziehst du zusammen mit der Domain auch die Website um, findest du die Reihenfolge unter Webhosting wechseln ohne Ausfall.

Typische Fehler beim Domainumzug

Der häufigste Fehler ist eine leere Zone beim neuen Anbieter. Die Domain ist umgezogen, aber dort stehen nur Standardeinträge, und die Mail landet nirgends. Cloudflare weist darauf hin, dass ein automatischer Scan vorhandener Einträge nicht garantiert alle findet und du die Liste selbst prüfen musst ^[1]. Das gilt sinngemäß für jeden Anbieter, der Einträge beim Umzug übernimmt.

Ein zweiter Fehler ist eine falsch geschriebene AuthInfo. Bei .de sind die Zeichen I, l, O, o, 0 und 1 ausgeschlossen, damit es keine Verwechslungen gibt ^[2]. Taucht so ein Zeichen in deinem Code auf, hast du ihn vermutlich falsch abgeschrieben. Ein dritter Fehler ist die verpasste Frist: Eine AuthInfo verfällt nach 30 Tagen ^[2]. Wer den Code anfordert und den Umzug dann liegen lässt, muss neu anfangen.

1. Organisation Set up a primary zone (Full setup). Cloudflare. Stand ohne Datum. abgerufen am 29.10.2026
2. Organisation Providerwechsel. DENIC eG. Stand ohne Datum. abgerufen am 29.10.2026
3. Organisation FAQs for Registrants: Transferring Your Domain Name. ICANN. Stand ohne Datum. abgerufen am 29.10.2026
4. Organisation Transfer Policy, Abschnitte I.A.2 bis I.A.5. ICANN. Stand Fassung vom 21.02.2024, von Registraren bis 21.08.2025 umzusetzen. abgerufen am 29.10.2026
5. Organisation EPP Status Codes: What Do They Mean, and Why Should I Know?. ICANN. Stand ohne Datum. abgerufen am 29.10.2026
6. Organisation About Change of Registrant. ICANN. Stand ohne Datum. abgerufen am 29.10.2026
7. Organisation PDP Transfer Policy Review. ICANN GNSO. Stand 21.04.2026. abgerufen am 29.10.2026
8. Behörde Approved Resolutions, Regular Meeting of the ICANN Board, Beschluss 2026.06.07.04 (Transfer Policy Review). ICANN-Vorstand. Stand 07.06.2026. abgerufen am 29.10.2026

Zuletzt geprüft am 29.10.2026, nächste Prüfung spätestens im Oktober 2027. Fehler entdeckt? Schreib uns.