Was ist ein EPP-Code für den Domaintransfer

Der Umzug einer Domain von einem Registrar zu einem anderen verläuft meist unkompliziert, doch fast jeder Transfer hängt an einer kurzen Zeichenfolge: dem Auth-Code für den Transfer. Er wird auch EPP-Code, Autorisierungscode, AuthInfo-Code oder Transfer-Schlüssel genannt. Wenn Sie schon einmal mitten in einem Transfer festgesteckt haben, lag es mit großer Wahrscheinlichkeit an diesem Code, an einer aktiven Registrar-Sperre oder an einer Fristenregel, von der Sie nichts wussten. Dieser Leitfaden erklärt, was der Code ist, woher er kommt, wie ein Transfer nach den ICANN-Regeln tatsächlich abläuft und wie Sie die häufigsten Probleme lösen.

Was der Auth-Code eigentlich ist

Die Registries der meisten generischen Top-Level-Domains (gTLDs) wie .com, .net, .org und der neueren Endungen arbeiten mit dem Extensible Provisioning Protocol (EPP). In EPP besitzt jedes Domainobjekt einen authInfo-Wert: eine geheime, meist zufällig erzeugte Zeichenfolge, die nur der aktuelle Registrar und der Domaininhaber kennen sollten. Beantragt ein neuer Registrar den Transfer, muss er diesen Wert an die Registry übermitteln. Stimmt er überein, nimmt die Registry den Antrag an; andernfalls wird er sofort abgelehnt.

In der Praxis funktioniert der Code wie ein Passwort für die Domain selbst, nicht für Ihr Kundenkonto. Wer ihn besitzt und eine entsperrte Domain vorfindet, kann einen Transfer starten. Behandeln Sie ihn deshalb wie Zugangsdaten:

• Fügen Sie ihn nicht in E-Mail-Verläufe, Chatgruppen oder Support-Tickets ein, die Sie nicht selbst kontrollieren.
• Fordern Sie ihn erst an, wenn Sie wirklich umziehen wollen, und lassen Sie ihn neu erzeugen, falls er offengelegt wurde.
• Lassen Sie die Registrar-Sperre aktiviert, solange Sie die Domain nicht aktiv übertragen.

So erhalten Sie Ihren EPP-Code

Bei den meisten Registraren lässt sich der Code in der Domainverwaltung erzeugen oder anzeigen, oft in einem Bereich namens „Transfer“, „Auth-Code“ oder „Domain-Sicherheit“. Manche senden ihn stattdessen per E-Mail an den Inhaberkontakt. Für gTLDs schreibt die ICANN Transfer Policy vor, dass der Registrar den Code innerhalb von fünf Kalendertagen nach der Anfrage an den Domaininhaber herausgibt. Er darf ihn nicht als Druckmittel einsetzen, etwa indem er die Herausgabe verweigert, bis Sie eine nicht zusammenhängende Leistung bezahlen.

Bevor Sie den Code anfordern

• Inhaber-E-Mail prüfen: Gehen Code oder Bestätigungen an eine veraltete Adresse, aktualisieren Sie diese zuerst. Beachten Sie aber, dass ein Inhaberwechsel eine Sperre auslösen kann (siehe unten).
• Ablaufdatum prüfen: Eine Domain kurz vor dem Ablauf kann übertragen werden. Ist sie jedoch bereits abgelaufen und befindet sich in der Redemption-Phase, ist ein Transfer erst nach der Wiederherstellung möglich.
• Statuscodes prüfen: Eine kurze Abfrage mit dem WHOIS/RDAP-Tool von TLDix zeigt Status wie clientTransferProhibited, serverTransferProhibited oder pendingDelete. So wissen Sie vorab, ob der Transfer überhaupt klappen kann.

Der Transfer Schritt für Schritt

Bei einer typischen gTLD folgt ein Transfer zwischen Registraren immer derselben Reihenfolge, unabhängig von den beteiligten Unternehmen:

1. Domain entsperren beim bisherigen (abgebenden) Registrar; dadurch entfällt clientTransferProhibited.
2. Auth-Code anfordern beim abgebenden Registrar.
3. Transfer starten beim neuen (aufnehmenden) Registrar, indem Sie Domainnamen und Code eingeben und die Transfergebühr bezahlen. Bei den meisten gTLDs verlängert sich die Registrierung dadurch um ein Jahr, höchstens jedoch auf insgesamt zehn Jahre.
4. Bei Bedarf bestätigen: Je nach Registrar und geltender Fassung der Policy erhalten Sie eine Bestätigungs-E-Mail oder lediglich eine Mitteilung, dass ein Transfer läuft.
5. Abschluss abwarten: Der abgebende Registrar hat fünf Tage Zeit, den Antrag zu genehmigen oder aus zulässigen Gründen abzulehnen. Reagiert er nicht, genehmigt die Registry den Transfer am Ende dieser Frist automatisch.
6. DNS- und Verlängerungseinstellungen prüfen, sobald die Domain beim neuen Registrar angekommen ist.

Die Nameserver bleiben bei einem Transfer normalerweise unverändert, die Website muss also nicht offline gehen. Probleme entstehen meist dann, wenn das DNS beim alten Registrar gehostet wurde und dieser Dienst mit dem Transfer endet. Übertragen Sie Ihre Zoneneinträge deshalb vorher zum neuen Anbieter.

Auch der Zeitpunkt spielt eine Rolle. Einen Transfer erst in den letzten Tagen vor dem Ablaufdatum zu starten, ist riskant: Das Verfahren kann fünf Tage dauern, und läuft die Domain währenddessen ab, wird es kompliziert. Beginnen Sie nach Möglichkeit einige Wochen vorher, damit Ihnen genug Zeit bleibt, eine Ablehnung oder einen fehlerhaften Code zu korrigieren.

Die 60-Tage-Sperren und weitere Fristen

Verschiedene Wartezeiten sollen Domain-Diebstahl und Betrug erschweren. Die wichtigsten für gTLDs sind hier zusammengefasst.

Die einzelnen Sperrstatus und wie man sie liest, erklären wir ausführlich in unserem Leitfaden zur Domain-Transfersperre.

Was die ICANN Transfer Policy vorschreibt

Alle von ICANN akkreditierten Registrare müssen für gTLD-Domains die Transfer Policy einhalten. Sie legt unter anderem die wenigen Gründe fest, aus denen ein abgebender Registrar einen Transfer ablehnen darf: Hinweise auf Betrug, ein laufendes Streitverfahren, ein Gerichtsbeschluss, eine unklare Identität des Inhabers, eine unbezahlte vorherige Laufzeit, die genannten 60-Tage-Fristen oder ein ausdrücklicher Widerspruch des Inhabers. Ein Registrar darf nicht einfach ablehnen, weil er den Kunden behalten möchte.

Die Policy bietet außerdem einen Beschwerdeweg, falls ein Transfer ohne Zustimmung erfolgt ist oder zu Unrecht verweigert wurde: zunächst über die beteiligten Registrare, dann über das Verfahren der Transfer Dispute Resolution Policy (TDRP) bei der Registry und schließlich über ICANN Compliance, wenn ein Registrar seine Pflichten ignoriert. ICANN hat die Transfer Policy überprüft und überarbeitet, unter anderem bei Begriffen sowie beim Umgang mit Auth-Codes und Sperren. Details wie Bestätigungs-E-Mails oder die Dauer von Sperren können sich daher ändern, wenn neue Fassungen in Kraft treten. Prüfen Sie immer die aktuelle Dokumentation Ihres Registrars.

Wie ccTLDs Transfers anders regeln

Länderspezifische Top-Level-Domains (ccTLDs) werden von nationalen Registries betrieben, die eigene Regeln festlegen; die ICANN Transfer Policy gilt für sie nicht. Einige Beispiele zeigen, wie unterschiedlich das sein kann:

• .uk: Nominet verwendet für den Registrarwechsel keinen Auth-Code. Stattdessen erfragen Sie beim neuen Registrar dessen IPS-Tag und lassen den bisherigen Registrar den Tag ändern.
• .de: Die DENIC arbeitet mit einem AuthInfo-Code, den der Registrar auf Anfrage erzeugt und der nur begrenzt gültig ist.
• .eu: EURid nutzt einen Autorisierungscode, den Sie vom aktuellen Registrar erhalten.
• .tr: Seit der Umstellung auf das TRABIS-System folgen Transfers zwischen Registraren den TRABIS-Verfahren, die für türkische Domains eigene Prüfschritte enthalten können.

Manche ccTLDs verlängern beim Transfer nicht um ein Jahr, manche kennen keine 60-Tage-Sperre, andere verlangen zusätzliche Identitätsprüfungen. Lesen Sie die Regeln der jeweiligen Registry, bevor Sie annehmen, dass der Ablauf einer .com-Domain überall gilt.

Häufige Transferprobleme lösen

„Ungültiger Auth-Code“

Kopieren Sie den Code erneut ohne Leerzeichen am Anfang oder Ende, achten Sie auf verwechselbare Zeichen wie 0 und O und stellen Sie sicher, dass er seit dem Erhalt nicht neu erzeugt wurde. Bei manchen Registries laufen Codes zudem ab.

Transfer wird sofort abgelehnt

Meist ist die Domain noch gesperrt oder auf Registry-Seite ist ein Status gesetzt. Führen Sie eine neue Abfrage durch, denn manche Registrare übermitteln die Entsperrung erst mit Verzögerung an die Registry.

Keine Bestätigungs-E-Mail

Wegen der datenschutzbedingten Schwärzung kann der aufnehmende Registrar Ihre E-Mail-Adresse oft nicht sehen. Folgen Sie seinen Anweisungen, prüfen Sie den Spam-Ordner und stellen Sie sicher, dass die Inhaber-E-Mail beim abgebenden Registrar aktuell ist.

Transfer hängt im Status „ausstehend“

Warten Sie die vollen fünf Tage ab. Ist der Transfer danach noch offen, wenden Sie sich mit Domainnamen und Datum des Antrags an den aufnehmenden Registrar.

Ablehnung wegen offener Rechnung

Wurde eine frühere Laufzeit nicht bezahlt, darf der abgebende Registrar ablehnen. Prüfen Sie Ihre Rechnungen und lassen Sie sich die Begründung schriftlich geben, falls keine Forderung besteht; das hilft bei einer späteren Beschwerde.

Nach dem Transfer die Kontrolle behalten

Sobald die Domain angekommen ist, aktivieren Sie die Registrar-Sperre wieder, schalten Sie die Zwei-Faktor-Authentifizierung im neuen Konto ein und prüfen Sie automatische Verlängerung und Zahlungsdaten. Ein neuer Registrar bedeutet auch neue Verlängerungstermine und Preise, die Sie im Blick behalten müssen. Wenn Sie die Domain im Domain-Panel von TLDix hinterlegen, sehen Sie Ablaufdatum, Registrar und Status neben Ihren SSL-Zertifikaten und Hosting-Verlängerungen. So folgt auf einen erfolgreichen Transfer kein versehentlicher Ablauf.