EPP-Statuscodes: Alle Statuscodes für Domains erklärt

EPP-Statuscodes bilden die schreibgeschützte Steuerungsebene Ihres Domain-Portfolios. Sie sind die einzige öffentlich einsehbare Oberfläche, auf der jeder den tatsächlichen Sicherheits- und Lebenszyklusstatus einer Domain ablesen kann.

Dieser Artikel gibt einen vollständigen, aktuellen Überblick über alle 23 EPP-Statuscodes: über ihre Bedeutung, ihre Dringlichkeit und wie Sie eine Status-Baseline über 50 oder 5.000 Domains hinweg durchsetzen, statt jede Domain einzeln zu prüfen. Am Ende sollten Sie eine einzige Frage beantworten können: Befindet sich mein Domain-Portfolio in dem Zustand, in dem ich es vermute?

Was EPP-Statuscodes sind und wer sie festlegt

EPP-Statuscodes sind standardisierte Kennzeichnungen, die einer Domain zugewiesen werden und deren aktuellen Zustand melden. Registrare und Registries setzen sie über das Extensible Provisioning Protocol, definiert in STD 69 (RFC 5730 bis 5734), dem Maschine-zu-Maschine-Protokoll, das sie zur Erstellung, Übertragung, Aktualisierung und Löschung von Domainnamen verwenden. RFC 3915 fügt den Status der Registry Grace Period hinzu, die den Verlauf einer Domain bis zum Ablauf und zur Löschung verfolgen.

Insgesamt gibt es 23 Codes: die 17 standardisierten EPP-Statuscodes plus 6 Statuscodes der Registry Grace Period. Die ICANN veröffentlicht die maßgebliche Liste, aufgeteilt in 18 server- und RGP-Codes sowie 5 client-Codes. Dies sind keine Erfindungen einzelner Registrare: serverHold hat dieselbe Bedeutung, unabhängig davon, welche Registry den Statuscode setzt.

Wenn ein Registrar einen Transfer Lock setzt oder eine Registry eine Domain löschen möchte, wird diese Handlung als Statuscode sichtbar, den jeder lesen kann. Genau das macht die Codes zu einer Steuerungsebene und nicht nur zu einer Dokumentation. Die eigentlichen Stellhebel, ob eine Domain transferiert, aktualisiert, gelöscht oder aufgelöst werden kann, befinden sich im EPP. Die Statuscodes sind die öffentliche Anzeige der aktuellen Position jedes Hebels.

Das Präfix verrät, wer die Kontrolle hat, und es zu lesen ist der schnellste Weg zur ersten Einschätzung der Lage:

• Der Registrar setzt die client-Präfix-Codes auf Ihren Wunsch und kann sie in Minuten hinzufügen oder entfernen.
• Die Registry setzt die server-Präfix-Codes. Ihr Registrar kann sie nicht aufheben. Das kann nur die Registry, und in der Regel nur nach einem definierten Verifizierungsverfahren außerhalb des Systems.
• Manche Codes erscheinen automatisch. addPeriod, autoRenewPeriod, redemptionPeriod und pendingDelete treten von selbst auf, während die Domain ihren Lebenszyklus durchläuft. Niemand tippt sie manuell ein.

Alle 23 EPP-Statuscodes: die Referenztabelle

Der Begriff „Dringlichkeit“ ist hier absichtlich unmissverständlich verwendet. Dringend heißt: jetzt handeln. Schutz heißt: beibehalten. Prüfen heißt: lesen und klären, ob der Status beabsichtigt ist. Info heißt: zur Kenntnis nehmen und weitermachen.

Client-Codes, gesetzt von Ihrem Registrar

Server- und Registry-Grace-Period-Codes, gesetzt von der Registry

Wie EPP-Statuscodes zusammenwirken

Eine Domain trägt in der Regel mehrere Codes gleichzeitig, und das ist auch richtig so. Eine fehlerfreie, geschäftskritische Domain zeigt typischerweise clientTransferProhibited, clientUpdateProhibited und clientDeleteProhibited gemeinsam an, wobei die serverseitigen Entsprechungen darüber stehen, wenn ein Registry Lock vorliegt. Prohibited-Codes sind additiv: Jeder blockiert seine eigene Operation und sie stehen niemals in Konflikt miteinander. Für den Rest gelten drei Regeln. Ein Hold überschreibt die Auflösung, eine vollständig gesperrte Domain mit serverHold ist also trotzdem offline. pendingDelete überschreibt die Schutzcodes, weil der Löschvorgang unabhängig davon weiterläuft. Und ok schließt sich mit allem anderen gegenseitig aus: Wenn Sie ok sehen, gibt es keine Sperren.

Die praktische Schlussfolgerung: Eine intakte, geschäftskritische Domain zeigt eine Reihe von Prohibited-Codes, nie ok, nie einen Hold und niemals einen Pending-Code, den Sie nicht selbst ausgelöst haben. Alles andere ist ein Prüfbefund.

Wo Sie EPP-Statuscodes abfragen: RDAP statt WHOIS

Wenn Sie immer noch instinktiv eine WHOIS-Abfrage durchführen möchten, sollten Sie Ihre Vorgehensweise ändern. Am 28. Januar 2025 hat die ICANN die vertragliche Pflicht für gTLD-Registries und Registrare aufgehoben, WHOIS über Port 43 zu betreiben. RDAP, das Registration Data Access Protocol, ist heute das verpflichtende Protokoll und die maßgebliche Quelle für gTLD-Registrierungsdaten, einschließlich der Statuscodes. Im Januar 2026 hat die ICANN einem Registrar die Akkreditierung entzogen, weil er RDAP nicht implementiert hatte. Damit waren die Zweifel geklärt, ob eine Umsetzung optional ist.

WHOIS ist nicht verschwunden. Betreiber können den Dienst weiterführen und Verisign hat zugesagt, WHOIS für .com parallel zu RDAP aufrechtzuerhalten. Maßgeblich ist es aber nicht mehr und ein Monitoring des Domain-Portfolios auf WHOIS-Scraping aufzubauen bedeutet heute, sich auf einen Dienst zu verlassen, den jede Registry ohne Vorankündigung abschalten kann.

RDAP liefert strukturiertes JSON über HTTPS, also genau das, was Sie im großen Umfang benötigen. Die Statuswerte sind die EPP-Codes mit eingefügten Leerzeichen, clientTransferProhibited erscheint also als client transfer prohibited, eine Übersetzungstabelle ist nicht nötig. Eine Ausnahme sollten Sie kennen, bevor Sie Daten auswerten: Das EPP-ok erscheint in RDAP als active. Die maßgebliche Liste steht im IANA RDAP JSON Values Registry.

Wo Sie nachschauen sollten, geordnet nach Nützlichkeit: RDAP-Abfragen bei der zuständigen Registry oder dem zuständigen Registrar für eine einzelne verbindliche Auskunft; das Control Panel Ihres Registrars oder Ihrer Plattform für das Domain-Portfolio, das Sie betreuen; und API-Antworten für alles, was Skalierung erfordert, da manuelle Einzelabfragen pro Domain bei einem Portfolio von 500 Domains nicht praktikabel sind.

Die RGP-Uhr: Wie wenig Zeit Ihnen tatsächlich bleibt

Wenn Sie ein Domain-Portfolio verwalten, entscheidet der Lebenszyklus der Registry Grace Period über Gewinn und Verlust und die Statuscodes sind Ihre einzige Vorwarnung. Die Abfolge, die eine Domain nach ihrem Ablauf durchläuft, sieht folgendermaßen aus:

1. Ablauf. Die Laufzeit der Registrierung endet.
2. autoRenewPeriod. Ein Kulanzfenster, je nach Registry oft rund 45 Tage, in dem die Domain automatisch oder zum normalen Preis verlängert werden kann. Eine vollständige Wiederherstellung ist noch möglich.
3. redemptionPeriod. Die Domain wurde aus der Zone gelöscht, der ursprüngliche Inhaber kann sie aber über den betreuenden Registrar noch wiederherstellen. Dieses Fenster läuft 30 Tage und die Wiederherstellung kostet eine von der Registry festgesetzte Restore-Gebühr, die deutlich über einer normalen Verlängerung liegt.
4. pendingDelete. Die letzte Phase, typischerweise rund fünf Tage. Sie lässt sich weder unterbrechen noch rückgängig machen. Sobald dieser Status erscheint, ist die Domain praktisch verloren.
5. Freigabe. Die Domain fällt zurück in den freien Pool und kann von jedem registriert werden.

Das 30-Tage-Fenster ist kein Entgegenkommen der Registry. Die Expired Registration Recovery Policy der ICANN verpflichtet alle gTLD-Registries, gesponserte gTLDs ausgenommen, dieses Zeitfenster anzubieten. Die Restore-Gebühren dagegen setzt jede Registry selbst und sie fallen sehr unterschiedlich aus. Prüfen Sie den Betrag für die konkrete TLD, anstatt von einem einheitlichen Betrag auszugehen.

Zwei Einschränkungen: Die genauen Fristen unterscheiden sich je nach Registry und TLD, und viele ccTLDs haben einen völlig anderen Lebenszyklus. Außerdem ist die RGP-Uhr öffentlich einsehbar, was bedeutet, dass eine abgelaufene Domain in der redemptionPeriod für Wettbewerber und Drop-Catcher sichtbar ist, die genau auf dieses Signal warten.

Die einzige zuverlässige Abwehrmaßnahme besteht darin, nicht erst zu reagieren, wenn die redemptionPeriod erscheint. Es wird Auto-Renew plus Ablauf-Monitoring benötigt, damit eine kritische Domain den Ablauf nie unbemerkt erreicht. Wenn Sie die redemptionPeriod erst aus einer Statusabfrage ablesen, zahlen Sie im besten Fall eine Restore-Gebühr und verlieren im schlimmsten Fall die Domain.

Transfer Lock und Hijacking-Signale

Bei den transferbezogenen EPP-Statuscodes wird das Lesen des Status zur Sicherheitsfrage.

clientTransferProhibited blockiert ausgehende Transfers und gehört auf jede geschäftskritische Domain. Es ist eine der günstigsten und wirksamsten Kontrollen, die es gibt. Entfernen Sie es nur bewusst, zu Beginn eines geplanten Transfers, und setzen Sie es wieder, sobald der Transfer abgeschlossen ist. Die Antwort auf die Frage „Sollte ich sie entfernen?“ lautet Nein, es sei denn, Sie sind gerade dabei, die Domain aktiv zu verschieben.

pendingTransfer bedeutet, dass ein Transfer läuft. Wenn Sie ihn ausgelöst haben, ist alles in Ordnung. Wenn nicht, behandeln Sie ihn als laufenden Hijacking-Versuch. Die wahrscheinlichste Ursache ist ein kompromittierter Registrar-Account: Jemand hat sich Zugang verschafft, den Transfer Lock entfernt, den Auth-Code abgerufen und mit der Übertragung der Domain begonnen. Gehen Sie am besten in dieser Reihenfolge vor:

1. Kontaktieren Sie Ihren Registrar und lassen Sie die Transferanfrage in Ihrem Namen ablehnen. Dieser Schritt stoppt den Transfer und ist fristgebunden: Eine unbeantwortete Anfrage wird nach fünf Tagen automatisch genehmigt.
2. Setzen Sie clientTransferProhibited, den Transfer Lock, erneut und vergewissern Sie sich, dass er in RDAP sichtbar ist.
3. Wechseln Sie den Auth-Code. Das verhindert einen weiteren Versuch, hat jedoch keinen Einfluss auf die bereits laufende Anfrage.
4. Sichern Sie Ihren Account ab: Zugangsdaten, MFA und eine vollständige Überprüfung der Zugriffsberechtigungen.
5. Bei einer besonders wertvollen Domain sollten Sie parallel dazu die Registry einschalten.

Geschwindigkeit ist entscheidend, denn sobald ein Transfer zu einem anderen Registrar abgeschlossen ist, wird die Rückholung kein Support-Ticket mehr sein, sondern ein formelles Streitverfahren. Unser Leitfaden zu Domain-Hijacking und was im Fall der Fälle zu tun ist zeigt, wie schwierig die Rückgewinnung einer gestohlenen Domain tatsächlich ist.

Genau das macht EPP-Statuscodes zu einer Sicherheitsoberfläche und nicht bloß zu einer Referenz. In dem Moment, in dem ein Angreifer den Zustand Ihrer Domain verändert, ändern sich die Statuscodes mit. Ein unerwartetes pendingTransfer oder pendingUpdate ist das früheste externe Signal für einen kompromittierten Registrar-Account und meist sichtbar, bevor weitreichende Schäden entstehen.

Warum kann ich eine gerade registrierte Domain nicht transferieren?

Derzeit sieht die Transfer Policy der ICANN nach drei Ereignissen eine 60-tägige Sperre für Registrarwechsel vor: nach einer Neuregistrierung, nach einem abgeschlossenen Transfer und nach einem Inhaberwechsel. Gerade der Inhaberwechsel verhindert Portfolio-Konsolidierungen und Bereinigungen nach Zukäufen, da die Bearbeitung des Inhabernamens oder der E-Mail-Adresse die Frist erneut auslöst.

Ab dem 3. Quartal 2026 befindet sich diese Regel mitten in einer Reform. Die ICANN hat Änderungen genehmigt, die die Sperre bei einem Inhaberwechsel vollständig aufheben und die beiden anderen Auslöser durch eine verbindliche Sperrfrist von 720 Stunden, also 30 Tagen, ersetzen. Damit wird vereinheitlicht, was bisher im Ermessen der Registrare lag. Die Umsetzung erfolgt von Registrar zu Registrar über etwa 18 Monate. Bis Ihr Registrar das kürzere Zeitfenster bestätigt, sollten Sie daher zeitkritische Migrationen weiter mit einem Zeitpuffer von 60 Tagen planen.

Das Präfix verstehen: Transfer Lock oder Registry Lock

Auf beiden Ebenen gibt es dieselben drei verbotenen Vorgänge. Damit ist das Präfix das einzige Merkmal in einer Statusabfrage, das Ihnen verrät, um welche Art von Sperre es sich tatsächlich handelt.

clientTransferProhibited, clientUpdateProhibited und clientDeleteProhibited bilden einen Transfer Lock und seine Ableger: gesetzt innerhalb Ihres Accounts, in Minuten aufgehoben und entfernbar von jedem, der diesen Account kompromittiert. Auf der Serverseite entspricht dies einem Registry Lock: Nur die Registry kann sie nach manueller Verifizierung außerhalb des Systems aufheben. Genau dadurch wird ein Angreifer gestoppt, der Ihre Zugangsdaten schon besitzt.

Das Präfix beantwortet also eine Frage, die die Codes allein nicht beantworten. Drei serverseitige Prohibited-Codes bedeuten, dass die Domain wirklich abgesichert ist. Drei clientseitige Codes bedeuten, dass sie gegen Unfälle und opportunistische Angriffe geschützt ist, nicht jedoch gegen jemanden, der sich bereits in Ihrem Account befindet. Unser ausführlicher Beitrag zum Registry Lock behandelt die infrage kommenden TLDs, das Verifizierungsverfahren und den zeitlichen Vorlauf, den dieser Aufwand erfordert.

Festlegung einer EPP-Status-Baseline für das gesamte Domain-Portfolio

Eine Code-Referenz macht sich erst dann bezahlt, wenn sie zu einer verbindlichen Richtlinie wird. So verwandeln Sie die Steuerungsebene in eine vertretbare Grundlage.

Schritt 1: Domains in Kategorien einteilen.

Dies ist der Maßstab, anhand dessen Sie Ihre Prüfung durchführen.

Schritt 2: Prüfung des Status bei jedem Registrar. Fragen Sie den Status per RDAP oder über die API Ihrer Plattform für jede Domain ab, unabhängig davon, wo sie verwaltet wird. Markieren Sie jede kritische oder markenbezogene Domain, die als ok angezeigt wird, einen Hold zeigt oder einen Pending-Code aufweist, den Sie nicht ausgelöst haben. Hier zeigen fragmentierte, durch Übernahmen geerbte Domain-Portfolios ihre Lücken, meist in Form vergessener Domains, die bei einem alten Registrar völlig ungeschützt liegen.

Schritt 3: Beheben Sie die Mängel und dokumentieren Sie sie. Schließen Sie jede Lücke gegenüber der Baseline und halten Sie dann fest, wer was ändern darf und bewahren Sie die Änderungshistorie auf. Die Dokumentation ist entscheidend, um den Status später in einem Audit oder einem Rechtsstreit rechtfertigen zu können.

Schritt 4: Sperrfristen vor jeder Konsolidierung einplanen. Für Domains unter einem Registry Lock muss die verifizierte Entsperrung im Vorfeld terminiert werden. Die Sperre für Registrarwechsel, derzeit 60 Tage, bestimmt, wann eine verschobene Domain erneut wechseln kann. Erfassen Sie dieses Zeitfenster, bevor Sie sich auf einen Migrationstermin festlegen.

Bei 50 Domains können Sie Teile davon manuell erledigen. Bei mehreren hundert Domains über verschiedene Registrare hinweg ist dies nicht mehr möglich und genau dafür gibt es Plattformen, um EPP-Status-Baselines in großen Mengen anzuwenden und zu prüfen. Unser Überblick zu Domain-Management-Tools behandelt die Massenverarbeitungs- und API-Funktionen, die dies machbar machen und mit AutoDNS können Sie eine Baseline für Ihr gesamtes Domain-Portfolio über eine einzige Schnittstelle durchsetzen und überprüfen, anstatt sich bei jedem Registrar einzeln anzumelden.

Überwachung von Änderungen des EPP-Statuscodes

Ein Audit ist eine Momentaufnahme. Die Steuerungsebene funktioniert nur, wenn Sie sie kontinuierlich überwachen, denn der Wert einer schreibgeschützten Oberfläche liegt darin, den Moment zu erfassen, in dem sich der Status ändert.

Worauf Sie achten sollten:

• Eine kritische oder markenspezifische Domain verliert einen Prohibited-Code, den sie eigentlich führen sollte. Das Verschwinden einer Sperre ist ein Warnsignal, unabhängig davon, ob die Änderung autorisiert war oder nicht.
• clientHold oder serverHold erscheint auf einer aktiven Domain.
• pendingTransfer, pendingUpdate oder pendingDelete, das Sie nicht initiiert haben.
• Eine kritische Domain, die wieder den Status ok annimmt.

So geht’s: Geplante RDAP- oder API-Abfragen, die in ein System eingespeist werden, welches den aktuellen Status jeder Domain mit der erwarteten Baseline vergleicht und bei Abweichungen eine Warnung ausgibt. Manuelle Überprüfungen lassen sich nicht über eine Handvoll Domains hinaus skalieren und hängen dem entscheidenden Ereignis immer hinterher. Unser Leitfaden zum Domain-Monitoring deckt das gesamte Spektrum ab, einschließlich der Beobachtung von Domains, die Ihnen nicht gehören, und die defensive Registrierung deckt den Long Tail ab, den Sie ausschließlich halten, damit andere ihn nicht besitzen können.

Kontinuierliches Monitoring macht aus der schreibgeschützten Steuerungsebene ein Frühwarnsystem. Dieselbe Oberfläche, die den Normalzustand meldet, kennzeichnet auch den ersten Schritt eines Angriffs, meist bevor ein Dienst betroffen ist.

Ihre EPP-Statuscodes sind der prüfbare Nachweis dafür, dass Ihre Domain-Richtlinie tatsächlich greift und nicht nur auf dem Papier steht. Lesen Sie sie, setzen Sie sie durch und überwachen Sie sie, dann können Sie die Frage beantworten, mit der dieser Artikel begann: Ja, mein Domain-Portfolio ist in dem Zustand, in dem ich es vermute.

Informieren Sie sich über Ihr Portfolio anstatt zu raten

EPP-Statuscodes machen aus Domain-Sicherheit eine überprüfbare Größe statt einer Annahme. Wenn Sie sehen möchten, wie sich eine Status-Baseline über ein ganzes Domain-Portfolio durchsetzen lässt, sehen Sie sich an, wie AutoDNS Sperren, Monitoring und Audit-Trails auf einer EU-basierten, API-first aufgebauten Infrastruktur umsetzt, oder sprechen Sie mit einem Partner Manager von InterNetX über die Konsolidierung Ihrer Domains auf einer Plattform.

Häufig gestellte Fragen