Auth-Code, EPP-Code, TAC: das Passwort für den Domain-Transfer

Ein Auth-Code ist das Passwort, das Ihnen Ihr Registrar ausstellt, damit Sie Ihre Domain zu einem anderen Registrar umziehen können. Jeder Transfer zwischen Registraren benötigt einen.

Der Code belegt, dass die Transferanfrage von einer berechtigten Person stammt, aber er identifiziert sie nicht, also die Person, die den Transfer beantragt. Er bestätigt lediglich, dass derjenige, der die Anfrage gestellt hat, über den Code verfügt. Behandeln Sie den Code deshalb so sorgfältig wie ein Passwort: Erzeugen Sie ihn erst, wenn Sie ihn brauchen, und übermitteln Sie ihn über einen Kanal, dem Sie vertrauen.

Dieser Beitrag erklärt, was der Code leistet, wie sich die Regeln bei gTLDs und ccTLDs unterscheiden, warum ein Transfer scheitern kann und wie Sie Codes über ein ganzes Domain-Portfolio hinweg handhaben.

Was ein Auth-Code leistet

Der Code autorisiert genau eine Aktion: den Umzug einer Domain von einem Registrar zu einem anderen. Sobald Sie die Domain aus der Transfersperre oder dem Registry Lock gelöst haben, übermitteln Sie den Auth-Code und starten damit den Transfer.

Das Format legt jede Registry selbst fest. Auth-Codes bestehen aus Buchstaben, Zahlen und Sonderzeichen, und die Länge variiert. Manche Registrys schränken den Zeichensatz bewusst ein: Bei .de verlangt DENIC 8 bis 16 Zeichen und schließt I, l, O, o sowie die Ziffern 0 und 1 aus, damit kein Transfer an einem falsch gelesenen Zeichen scheitert.

Auth-Code, AuthInfo-Code, EPP-Code, TAC: ein Passwort, viele Bezeichnungen

Sie werden diesem Passwort für Domain-Transfers unter verschiedenen Bezeichnungen begegnen: Auth-Code, AuthInfo-Code, Auth-Info, EPP-Code, EPP-Key, Transfer-Code, Providerwechsel-Passwort oder Domain Authorization Code. Unterschiedliche Begriffe, dieselbe Sache.

Der Begriff EPP-Code stammt von dem Protokoll, über das Registrare mit Registrys kommunizieren: dem Extensible Provisioning Protocol (EPP). Das Feld, das das Transfer-Passwort übermittelt, heißt „authInfo“. Aus diesem Feld leitet sich die Bezeichnung „AuthInfo-Code“ ab.

Die ICANN selbst verwendet in ihren FAQs für Domaininhaber die Schreibweise Auth-Code. Der Begriff, der künftig gilt, ist allerdings Transfer Authorization Code (TAC). Die Arbeitsgruppe des Transfer Policy Review hat sich auf diesen Begriff verständigt, und die Community hat ihn gemeinsam mit der übrigen Domain-Transfer-Reform im März 2025 auf der ICANN82 beschlossen. Wenn die Oberfläche eines Registrars „Request TAC“ anzeigt, wissen Sie jetzt, dass der Auth-Code gemeint ist.

Wie der Auth-Code in einen Domain-Transfer eingebunden ist

Wenn Sie Ihre Domain von einem Registrar zu einem anderen umziehen möchten, greift der Auth-Code an dieser Stelle im Prozess.

1. Lösen Sie die Domain bei Ihrem aktuellen, also dem bisherigen Registrar aus der Sperre. Eine Transfersperre oder ein Registry Lock blockiert den Transfer.
2. Erzeugen Sie den Auth-Code beim bisherigen Registrar oder fordern Sie ihn dort an.
3. Übermitteln Sie den Auth-Code mit dem Transferauftrag an den neuen Registrar.
4. Bestätigen Sie den Transfer. Wer bestätigt und auf welchem Weg, hängt von der Endung ab.
5. Die Registry schließt den Umzug ab, und der neue Registrar wird zum verwaltenden Registrar.

Der Domain-Transfer wechselt den verwaltenden Registrar, während Ihre DNS-Einträge unverändert bestehen bleiben. Liegt Ihre Zone jedoch beim Registrar, den Sie verlassen, kann die Auflösung während des Umzugs ausfallen und Website sowie E-Mail mitnehmen. Eine Lösung besteht darin, die Zone vorab beim Zielanbieter oder auf Nameservern zu spiegeln, die von beiden Registraren unabhängig sind. Wenn Sie Ihre DNS-Einträge auf einer anbieterunabhängigen Plattform pflegen, entfällt das Problem vollständig. Das ist eines der Argumente, die Sie in unserem ausführlichen Leitfaden zum Domain-Management finden.

Warum die Transferregeln strenger werden

Jahrelang wurde der Auth-Code einmal erzeugt, nämlich bei der Registrierung der Domain, und blieb über den gesamten Lebenszyklus hinweg unverändert. Der Registrar stellte ihn aus, und die Registry legte eine verschlüsselte Kopie ab. RFC 9154, im Dezember 2021 von der IETF veröffentlicht, beschreibt ein anderes Verfahren: Codes sollen stark und zufällig sein, nur kurz gültig, nie beim Registrar gespeichert und bei der Registry ausschließlich als kryptografischer Hash hinterlegt. Die aktuelle Reform der ICANN folgt diesem Modell, weshalb Codes künftig kürzer gültig sind und nicht mehr dauerhaft abrufbar herumliegen.

Was die ICANN-Reform verändert

Stand September 2026 sind zwei Fassungen der Regeln parallel im Umlauf. Es lohnt sich also zu wissen, nach welcher Ihr Registrar arbeitet.

Als gültig führt die ICANN die Transfer Policy in der Fassung vom 21. Februar 2024, die die Vertragspartner bis zum 21. August 2025 umsetzen mussten. Das Transfer Policy Review lief seit 2021 als Policy Development Process der GNSO, und die Community hat seine 47 Empfehlungen im März 2025 auf der ICANN82 beschlossen. Die Reform bringt vier wesentliche Änderungen:

• Der Auth-Code wird zum TAC und wird nur noch auf Anfrage erzeugt. Die Registry speichert ihn als Einweg-Hash.
• Seine Lebensdauer ist begrenzt, standardmäßig auf 14 Tage (336 Stunden), durchgesetzt auf Registry-Ebene.
• Die Form of Authorization des abgebenden Registrars entfällt, und der Transfer beginnt, sobald der Domaininhaber den Auth-Code übermittelt. Die Frist von fünf Kalendertagen wird als 120 Stunden neu formuliert.
• Die Sperrfrist von 60 Tagen verkürzt sich auf 30 Tage.

Diese neue Policy macht Transfers einfacher und die Domain-Portfolio-Konsolidierung weniger mühsam.

So erhalten Sie den Auth-Code

Um den Auth-Code für Ihre Domain zu erhalten, gehen Sie entweder in das Kundencenter Ihres Registrars oder fordern ihn über ein Support-Ticket an. Lösen Sie die Domain zuerst aus der Sperre. Andernfalls zeigt das System den Code möglicherweise nicht an.

Was tun, wenn Ihr Registrar den Auth-Code nicht herausgibt?

Ihr Registrar ist verpflichtet, Ihnen den Auth-Code auszuhändigen, und verstößt gegen die Transfer Policy der ICANN, wenn er das nicht tut. Wenn Sie ihn schriftlich und unter Verweis auf die Frist von fünf Kalendertagen angefordert haben und weiterhin keine Antwort erhalten, reichen Sie eine Transfer-Beschwerde bei ICANN Contractual Compliance ein. Die ICANN greift ein, wenn ein Registrar nicht reagiert. Beachten Sie dabei: Der Eskalationsweg über die ICANN gilt ausschließlich für gTLDs.

Wenn Sie einen Auth-Code für eine Domain unter einer ccTLD benötigen, bieten manche nationalen Registrys einen Ausweg. Für Ihre .de-Domain können Sie beispielsweise bei DENIC eine AuthInfo2 beantragen. DENIC erzeugt den Code selbst und sendet ihn per Einschreiben an die Adresse des Domaininhabers, die in den Domaindaten hinterlegt ist, weltweit. EURid stellt für .eu einen Notfallcode aus, sobald Sie nachgewiesen haben, dass die Domain Ihnen gehört. Und nic.at kann für .at einen Bestätigungs-Token ausstellen, der dem Domaininhaber per E-Mail zugeht.

Behandeln Sie den Auth-Code wie ein Passwort

Gehen Sie mit Auth-Codes so um, wie Sie es mit geschäftskritischen Passwörtern tun würden: Beschränken Sie, wer sie erzeugen darf, übermitteln Sie sie über Kanäle, denen Sie vertrauen, und dokumentieren Sie, was passiert ist.

AutoDNS übernimmt die Erzeugung von Codes, den Abruf in großen Mengen und einen protokollierten Nachweis jeder Änderung, auf Infrastruktur in der EU. Schauen Sie sich das an oder sprechen Sie mit einem Partnermanager von InterNetX über die Konsolidierung Ihres Domain-Portfolios.

Auth-Codes in AutoDNS verwalten