Domain-Transfer-Prozess technisch betrachtet: Vollständige Anleitung

Ich beschreibe den Domain-Transfer-Prozess technisch, Schritt für Schritt, vom Entsperren bis zur finalen Bestätigung in der Registry. So planst du Auth‑Code, EPP‑Abläufe und das DNS-Update sauber, damit Website und Mail erreichbar bleiben.

Zentrale Punkte

• Entsperren und Inhaberdaten prüfen
• Auth-Code rechtzeitig anfordern
• EPP-Transfer bei neuem Registrar starten
• DNS-Update vorab vorbereiten
• TLD-Regeln und Fristen beachten

Vorbereitung: Domain entsperren und Daten prüfen

Ich starte mit der Transfersperre: Ich deaktiviere die Registrar-Lock im Kundenportal, damit der Wechsel möglich ist. Danach kontrolliere ich die WHOIS-Kontaktdaten, vor allem die E-Mail des Inhabers für Bestätigungen. Passen Angaben nicht, stoppt der Prozess oft unnötig lange. Ich dokumentiere außerdem das aktuelle Setup, damit ich später verlässlich vergleichen kann. Zum Schluss lege ich mir Checklisten bereit, damit ich keinen technischen Schritt vergesse.

DNS-Strategie vor dem Start

Vor produktiven Umzügen plane ich das DNS-Update aktiv, um Ausfälle zu vermeiden. Ich richte beim neuen Anbieter eine identische DNS‑Zone ein und teste A-, AAAA-, MX- und CNAME‑Records. Wer externe Nameserver nutzt, behält diese während des Wechsels bei und reduziert so das Risiko spürbar. Ich prüfe die Time‑to‑Live‑Werte (TTL) und senke sie gezielt, damit Änderungen schneller weltweit ankommen. Für tiefergehende Fehlervermeidung hilft mir dieser Leitfaden: Fehler beim Transfer vermeiden, den ich vor dem Start einmal durchgehe.

Auth‑Code (EPP) sicher anfordern

Ohne Auth-Code läuft kein einziger Transfer an. Ich fordere den Code beim bisherigen Registrar im Account an oder bitte den Support darum. Viele Codes bleiben rund 30 Tage gültig, deshalb nutze ich sie zeitnah. Für .de kann ich bei Problemen einen alternativen Code (AuthInfo2) über den zuständigen Betreiber anstoßen. Ich speichere den Code verschlüsselt und teile ihn nie per ungesicherter E-Mail.

Transfer bei neuem Registrar starten

Den eigentlichen Wechsel stoße ich beim neuen Anbieter an, gebe die Domain ein und tippe den Auth-Code korrekt ab. Im Hintergrund sprechen die Systeme über EPP, das XML‑basierte Protokoll für Registrys. Der neue Registrar schickt die Anfrage, die Registry prüft und informiert den alten Anbieter. Bei gTLDs folgt oft eine kurze Widerspruchsfrist, danach setzt die Registry die Domain um. Wer den vollständigen Ablauf kompakt nachlesen will, schaut in diese Anleitung: Registrar wechseln: Anleitung, die ich gerne als schnelle Referenz nutze.

Technischer Ablauf in der Registry

Damit du den Weg verstehst, fasse ich die technischen Schritte in klaren Worten zusammen und setze die Schwerpunkte auf EPP und Bestätigungen. Zuerst übermittelt der neue Registrar den Transfer-Request mit Domain und Auth‑Code an die Registry. Danach laufen Statusprüfungen: Eigentum, Sperre, Fristen und eventuelle Widersprüche. Der alte Registrar kann zustimmen oder schweigen; fehlende Reaktion bedeutet nach Fristende meist Zustimmung. Nach der Genehmigung weist die Registry die Domain dem neuen Registrar zu und aktualisiert Kontakte, Nameserver und Status.

EPP-Statuscodes gezielt nutzen

Ich lese bei Hängern die EPP-Statuscodes konsequent aus, weil sie klar anzeigen, wo es klemmt und welche Aktion nötig ist:

• ok: Alles bereit, keine Sperren aktiv. Transfer kann starten.
• clientTransferProhibited: Registrar-Lock aktiv. Ich hebe die Sperre im Account auf.
• serverTransferProhibited: Registry- oder Policy-Sperre (z. B. Verfahren/UDRP). Ich kläre den Grund mit dem Support.
• pendingTransfer: Transfer läuft. Ich warte die Frist ab oder prüfe Bestätigungs-Mails.
• redemptionPeriod / pendingDelete: Domain im Löschzyklus. Transfers sind blockiert; erst Wiederherstellung möglich, dann Transfer.
• clientUpdateProhibited: Updates gesperrt. Ich entferne zusätzliche Locks (Registry Lock) vor Änderungen.

Ich halte mir bewusst, dass gTLDs neben dem Auth‑Code zunehmend vom Begriff TAC (Transfer Authorization Code) sprechen – das Prinzip bleibt identisch: ein zeitlich begrenzter, sensibler Token, der den Transfer legitimiert.

Locks, 60‑Tage‑Regeln und zulässige Ablehnungen

Ich plane Zeitpuffer für Policies ein, die gerne übersehen werden. Nach Registrierung oder erfolgreichem Transfer setzen viele Registrare einen 60‑Tage‑Lock, in dem weitere Transfers meist abgelehnt werden. Ein Inhaberwechsel (Change of Registrant) kann bei gTLDs ebenfalls einen Sperrzeitraum auslösen, sofern nicht vorab ein Opt‑out gesetzt wurde. Zulässige NACK‑Gründe des alten Registrars sind u. a.: aktive Sperren, fehlende Zahlung, Identitätskonflikte oder rechtliche Verfahren. Liegt nichts davon vor, soll ein Transfer nicht grundlos verzögert werden. Ich prüfe daher vorab: Bezahlt? Entsperrt? Kontakte korrekt? Dann vermeide ich unnötige Schleifen.

DNS-Update ohne Ausfälle

Ich halte die Seite erreichbar, indem ich die DNS‑Zone vor dem Start kontrolliert spiegle und die TTL senke. Während der weltweiten Verteilung (Propagation) kann es zu kurzen Unterschieden bei der Auflösung kommen. Ich teste das Ziel aus mehreren Netzen und prüfe A‑ und MX‑Records mit Tools wie dig oder nslookup. Bei Bedarf setze ich temporär beide Infrastrukturen parallel auf, bis alle Caches umgestellt sind. Wer zusätzlich Details zu Zeitfenstern kennen will, nutzt meinen Hinweis weiter unten zur Dauer.

DNSSEC sauber migrieren

Mit DNSSEC berücksichtige ich den DS‑Eintrag bei der Registry. Wechselt der Nameserver und damit der Key, habe ich zwei sichere Strategien:

• Umbau mit Lücke: Ich entferne kurz vor der Umschaltung den DS bei der Registry, warte auf globale Aktualisierung (niedrige TTL hilft), stelle auf neue Nameserver um und setze anschließend den neuen DS. Das vermeidet SERVFAILs durch falsche Signaturen.
• Nahtloser Rollover: Ich hinterlege den neuen DNSKEY parallel (KSK‑Rollover), lasse ihn signieren und aktualisiere dann den DS. Erst danach entferne ich den alten Key. Das reduziert Validierungsrisiken bei strikt validierenden Resolvern.

Unterstützen Registry und Provider CDS/CDNSKEY, kann die DS‑Aktualisierung teils automatisiert erfolgen. Ohne Automation steuere ich die Reihenfolge manuell und protokolliere die Zeitpunkte, damit ich bei Störungen schnell gegenprüfen kann.

Child‑Nameserver und Glue‑Records

Verwendet die Domain eigene Nameserver (z. B. ns1.meinedomain.tld), existieren Hostobjekte/Glue‑Records bei der Registry. Ich plane hier gesondert:

• Ich füge vor dem Transfer zusätzliche IPs der neuen Infrastruktur zu den Hostobjekten hinzu (Dual‑Stack, Dual‑Provider), damit die Auflösung in der Übergangsphase zuverlässig klappt.
• Nach dem Transfer entferne ich alte IPs wieder, sobald alle Caches sicher auf den neuen Pfad zeigen.
• Ich prüfe, ob der neue Registrar die Verwaltung der Hostobjekte direkt unterstützt; falls nicht, stimme ich den Wechsel eng mit beiden Supports ab.

So verhindere ich, dass Domains, die auf meinen Child‑Nameservern liegen, durch den Transfer unerwartet nicht mehr auflösbar sind.

TLD‑Besonderheiten und Fristen

Je nach Endung ändern sich Fristen und Freigaben, deshalb werfe ich einen genauen Blick auf die TLD. gTLDs wie .com oder .net nutzen meist eine Widerspruchszeit von einigen Tagen, bevor der Wechsel greift. .de zieht nahezu in Echtzeit um, wenn der gültige Code vorliegt. Länderspezifische Endungen (ccTLDs) verhalten sich unterschiedlich und folgen eigenen Regeln. Die folgende Übersicht ordnet die wichtigsten Punkte ein und hilft bei der Planung.

TLD	Transfer-Prozess	Besonderheiten	Code/Bestätigung	Nameserver-Verhalten
.com / .net / .org	Request via EPP, kurze Widerspruchsphase	Alte Seite bleibt erreichbar bei richtiger DNS-Vorbereitung	Auth‑Code Pflicht, Inhaber bekommt Mails	Neue Zone vorher einrichten oder externe Nameserver behalten
.de	Echtzeit-Transfer nach Code-Eingabe	Optionaler alternativer Code (AuthInfo2) möglich	Auth‑Code Pflicht, Bestätigung oftmals direkt im Prozess	Alte Zone kann entfallen, daher Zone beim neuen Anbieter vorbereiten
ccTLDs (divers)	Sehr unterschiedlich, Registry‑abhängig	Teilweise zusätzliche Nachweise oder Fristen	Manchmal Code, teils andere Freigaben	Vorher prüfen, ob externe Nameserver bleiben

Abrechnung, Laufzeiten und Verfallsphasen

Ich verliere die Verlängerungslogik nicht aus dem Blick: Bei vielen gTLDs verlängert ein erfolgreicher Transfer die Laufzeit um ein Jahr (bis zur Maximalgrenze). Einige ccTLDs – darunter .de – kennen diese automatische Verlängerung beim Transfer nicht. Läuft eine Domain bald ab, verhindere ich böse Überraschungen so:

• Ich starte Transfers nicht in letzter Minute. Gerät die Domain in die Grace– oder Redemption‑Phase, sind Transfers häufig blockiert oder nur nach Wiederherstellung möglich.
• Auto‑Renew beim alten Registrar kann zu Zwischenrechnungen führen; nach erfolgreichem Transfer werden diese bei gTLDs oft rückabgewickelt. Ich dokumentiere die Zeitpunkte sauber.
• Nach dem Wechsel aktiviere ich beim neuen Registrar Auto‑Renew wieder, damit keine Lücken entstehen.

Zeitplanung und TTL‑Fahrplan

Für kritische Projekte lege ich mir einen kleinen Runbook‑Plan zurecht:

• T‑7 bis T‑3 Tage: Zone spiegeln, Monitoring einrichten (HTTP, MX, DNS). TTLs relevanter Records auf 300–600 Sekunden senken.
• T‑2 Tage: Auth‑Code prüfen, Sperren entfernen, Kontakte revalidieren.
• T‑1 Tag: Letzten Zonen‑Abgleich fahren, DNSSEC‑Plan (DS entfernen oder Rollover) umsetzen.
• T (außerhalb Peakzeiten): Transfer anstoßen, Logs und Status in beiden Portalen beobachten.
• T bis T+1: Nach erfolgreicher Übernahme Tests wiederholen, DS/Records finalisieren, alte Infrastruktur geordnet abbauen.
• T+2: TTLs schrittweise erhöhen, Dokumentation abschließen.

Häufige Stolpersteine vermeiden

Ich vermeide veraltete WHOIS‑Daten, denn fehlgeleitete Mails kosten unnötig Zeit. Eine aktive Transfersperre blockiert jeden Start, deshalb prüfe ich sie zuerst. Zu hohe TTL‑Werte sorgen für lange Propagation, daher setze ich sie im Vorfeld runter. Unterschiedliche Zonenstände bei altem und neuem Anbieter führen zu widersprüchlicher Auflösung. Ich gleiche die Records daher vor dem Start akribisch ab und dokumentiere jede Änderung.

Mail‑ und Hosting‑Umzug separat planen

Der Transfer betrifft nur die Registrierung, nicht Dateien oder Postfächer, und das halte ich mir stets klar. Webinhalte migriere ich per SFTP oder Backup‑Restore und teste sie vor der Liveschaltung. Postfächer ziehe ich mit IMAP‑Sync oder per Export/Import um, damit keine Nachricht fehlt. SPF, DKIM und DMARC übernehme ich sauber in die neue Zone. Erst wenn alles steht, erhöhe ich die TTL wieder und sichere die Stabilität.

Mail-Zustellung und Parallelbetrieb

Ich denke besonders an E-Mail-Flüsse. Während der Umstellung können eingehende Mails je nach Resolver mal am alten, mal am neuen MX landen. Ich reagiere darauf so:

• Ich plane bei hohen Volumina eine kurze Freeze‑Phase für Postfach-Strukturänderungen, damit keine Verschiebungen verloren gehen.
• Ich nutze bei Bedarf Dual Delivery (temporär zwei MX‑Ziele) oder ein zentrales Relay, das beide Backends bedient – wohldosiert und kontrolliert.
• Ich verifiziere nach dem Transfer SPF, DKIM und DMARC erneut und prüfe die Auswertung der Empfänger mittels DMARC‑Reports.

Security‑Checks nach dem Wechsel

Nach der erfolgreichen Migration aktiviere ich die Transfersperre wieder. Ich setze 2‑Faktor‑Authentifizierung im Kundenkonto und sichere den Auth‑Code-Verlauf. WHOIS‑Angaben prüfe ich erneut, damit Sichtbarkeit und Datenschutz passen. Fehler in DNSSEC, SPF oder DKIM behebe ich sofort, weil hier Mails stark leiden. Zum Abschluss dokumentiere ich alle Schritte und halte Backups bereit.

Nacharbeiten: Monitoring, Auto‑Renew, Audit

Ich kontrolliere die Auto‑Renew-Einstellung und setze, wenn verfügbar, Benachrichtigungen vor Ablauf. Ich lasse über 24–48 Stunden aktives Monitoring für Website, API‑Endpoints, MX, SPF/DKIM‑Prüfungen und DNSSEC laufen, um Edge‑Cases in Caches zu erwischen. Für Audits archiviere ich Screenshots, Exportfiles, Zonenstände und EPP‑Ereignisse (z. B. pendingTransfer → ok), damit spätere Nachfragen sauber belegbar sind.

Privacy, RDAP und Kontaktwege

Bei aktivem Privacy/Proxy stelle ich sicher, dass Bestätigungs‑Mails mich erreichen (Weiterleitungen funktionieren, Ticketsystem filtert nicht weg). Manche Registrare nutzen statt WHOIS heute RDAP‑basierte Kontaktwege. Ich halte die registrierten E‑Mails konsistent und meide spontane Kontaktwechsel kurz vor dem Transfer, damit keine Validierungs-Sperre greift.

Internationalisierte Domains (IDN)

Bei IDNs prüfe ich Schreibweise und Punycode konsequent in allen Systemen. Ich kontrolliere Zertifikate (SAN‑Einträge), Weiterleitungen und Anwendungen, die unter Umständen nur ASCII‑Labels akzeptieren. Ein Transfer ändert daran nichts, aber die Fehler schleichen sich gerne beim parallelen DNS‑Umbau ein.

Stapeltransfers und Organisation

Überführe ich mehrere Domains, bündele ich sie in Stapeltransfers mit identischem Vorgehen: einheitliche TTL‑Strategie, zentrale Tabelle für Auth‑Codes und Fristen, klare Eskalationswege. Kritische Zonen (z. B. SSO‑Provider, MX) priorisiere ich und stelle erhöhte Beobachtung sicher. So halte ich den Überblick und reduziere Kontextwechsel im Team.

Troubleshooting: Wenn der Transfer hängt

Hakt der Vorgang, arbeite ich eine klare Liste ab. Ich kontrolliere Sperre, Code‑Gültigkeit, Inhaber‑Mails und Nameserver‑Einträge. Danach frage ich beim neuen Registrar Status‑Logs an und bitte den alten Anbieter, eine Rückmeldung an die Registry zu senden. Bei .de fordere ich im Ernstfall einen neuen Code an und starte den Vorgang neu. Im Zweifel pausiere ich Produktiv‑Umschaltungen, bis das DNS konsistent und störungsfrei läuft.

Kurz zusammengefasst

Ich halte den Domain-Transfer-Prozess straff: erst Entsperren und Daten prüfen, dann Auth‑Code sichern, anschließend EPP‑Transfer starten. Parallel baue ich die DNS‑Zone beim neuen Anbieter auf und senke die TTL. Während der Fristen beobachte ich Statusmeldungen und teste Auflösung und Mail. Nach der Übernahme aktiviere ich die Transfersperre, setze Security‑Checks und erhöhe die TTL wieder. Wer diese Reihenfolge einhält, zieht Domains kontrolliert um und bewahrt Erreichbarkeit.