--- id: "epp-status-codes" kind: "glossary-term" title: "EPP-Statuscodes" language: "de" category: "Transfers und EPP" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/de/glossar/epp-statuscodes/" translations: en: "https://tldlog.com/glossary/epp-status-codes/" es: "https://tldlog.com/es/glosario/codigos-estado-epp/" fr: "https://tldlog.com/fr/glossaire/codes-statut-epp/" it: "https://tldlog.com/it/glossario/codici-stato-epp/" pt-BR: "https://tldlog.com/pt/glossario/codigos-status-epp/" ru: "https://tldlog.com/ru/glossariy/kody-statusov-epp/" zh-Hans: "https://tldlog.com/zh/cihui/epp-zhuangtaima/" --- # EPP-Statuscodes Die standardisierten Kennzeichnungen einer Domain, die ihren Zustand zeigen und welche Aktionen erlaubt sind, etwa Transfer, Änderung, Verlängerung oder Löschung. Codes, die mit client beginnen, setzt der Registrar, Codes, die mit server beginnen, die Registry. Sie erscheinen in RDAP-Ergebnissen. Jeder Domainname trägt mindestens einen Statuscode: eine kurze Bezeichnung wie ok oder clientTransferProhibited, die angibt, in welchem Zustand die Registrierung ist und welche Vorgänge gesperrt sind. Die Codes stammen aus EPP, der Standardsprache, mit der Registrare mit Registrys kommunizieren. Wer sie lesen kann, versteht, warum eine Domain nicht mehr funktioniert, ob sie gegen Diebstahl geschützt ist und ob ihre Löschung bevorsteht. ## Was Domain-Statuscodes sind und wo man sie sieht Die Codes sind im EPP-Standard für Domainnamen, RFC 5731, definiert und in seiner Erweiterung für Grace Periods, RFC 3915, die die Codes der Redemption Grace Period (RGP) hinzufügt. Bei gTLDs prüft man den Status über eine RDAP-Abfrage, etwa mit ICANN Lookup oder dem Abfragewerkzeug eines Registrars. Seit dem 28. Januar 2025 hat RDAP WHOIS als maßgebliche Quelle für Registrierungsdaten von gTLDs abgelöst (Stand Oktober 2026). RDAP schreibt die Codes als kleingeschriebene Wörter mit Leerzeichen, daher erscheint clientTransferProhibited als „client transfer prohibited“ und ok als „active“. Registrare müssen jeden Status anzeigen, der für eine Domain gilt. ccTLDs legen eigene Regeln fest und können den Status anders darstellen. Diese Erläuterung folgt EPP und den Richtlinien für gTLDs. ## Client- und Server-Codes: wer sie gesetzt hat Das erste Wort eines Codes zeigt, wer ihn gesetzt hat. - Codes, die mit client beginnen, setzt der Registrar, der die Domain verwaltet, manchmal automatisch bei der Registrierung, manchmal auf Wunsch des Domaininhabers. - Codes, die mit server beginnen, setzt die Registry. Sie haben Vorrang: Ein Registrar kann einen Server-Code nicht ändern, während eine Registry einen Client-Code nach ihren eigenen Richtlinien übergehen kann. - Codes ohne eines der beiden Präfixe, etwa ok, inactive und die Pending-Codes, verwaltet die Registry. In beiden Fällen wendet sich der Domaininhaber an den Registrar. Bei einem Server-Code leitet der Registrar die Anfrage an die Registry weiter, daher dauert die Aufhebung meist länger. ## Sperrcodes: was gesperrt ist und warum Vier Codepaare sperren jeweils einen Vorgang. Solange einer gesetzt ist, lehnt die Registry die entsprechende Anfrage ab: - clientTransferProhibited und serverTransferProhibited: einen Transfer zu einem anderen Registrar. - clientUpdateProhibited und serverUpdateProhibited: Änderungen an der Domain, etwa an Kontakten oder Nameservern, außer der Aufhebung der Sperre selbst. - clientDeleteProhibited und serverDeleteProhibited: die Löschung. - clientRenewProhibited und serverRenewProhibited: die Verlängerung. Die Client-Sperren für Transfer, Änderung und Löschung helfen beim Schutz vor Domain-Hijacking und Betrug. Die Sperren für die Verlängerung sind selten: Sie erscheinen meist bei Rechtsstreitigkeiten oder vor einer Löschung. Für gTLDs begrenzt die Transfer Policy der ICANN, in der am 21. Februar 2024 veröffentlichten und im Oktober 2026 gültigen Fassung, den Einsatz von clientTransferProhibited. Bietet der Registrar keine Möglichkeit, die Sperre selbst aufzuheben, muss er sie innerhalb von fünf Kalendertagen nach der Anfrage des Domaininhabers aufheben, und er darf dies nicht allein wegen eines Zahlungsstreits verweigern. Stand Oktober 2026 sind Änderungen der Transfer Policy beschlossen, aber nicht in Kraft. Der ICANN-Vorstand hat sie am 7. Juni 2026 beschlossen (Resolution 2026.06.07.04), ein Datum des Inkrafttretens ist nicht angekündigt. Dazu gehört eine verpflichtende Transfersperre für die ersten 720 Stunden (30 Tage) nach der Registrierung. Der Registrar kann bestätigen, welche Regeln gelten. Server-Sperren sind selten. Die ICANN nennt Rechtsstreitigkeiten, den Wunsch des Domaininhabers selbst und eine Domain in redemptionPeriod als übliche Gründe. Manche Registrys bieten einen Registry-Lock-Dienst an, der über den Registrar beantragt wird und Server-Codes als zusätzlichen Schutz nutzt. ## Hold-Codes: warum eine Domain nicht mehr funktioniert clientHold und serverHold weisen die Registry an, die Delegation der Domain nicht im DNS zu veröffentlichen. Website und E-Mail funktionieren nicht mehr, die Domain bleibt aber registriert. clientHold ist selten. Dokumente der ICANN bringen ihn mit Zahlungsausfall, Rechtsstreitigkeiten, bevorstehender Löschung, nicht verifizierten Kontaktdaten und der Unterbindung von DNS-Missbrauch in Verbindung. serverHold setzt die Registry; die Compliance-Hinweise der ICANN sagen, dass Registrys Missbrauchsfälle in der Regel zuerst an den Registrar verweisen sollten. Zwei andere Situationen sehen ähnlich aus: - inactive: Es sind keine Nameserver eingetragen, daher wird die Domain nicht aufgelöst, die Registrierung ist aber in Ordnung. Dauert das mehrere Tage, empfiehlt die ICANN, den Registrar zu kontaktieren; manche TLDs verlangen zuerst Unterlagen. - Ablauf: Nach dem Ablauf muss der Registrar die Auflösung der Domain für einen Teil der Zeit stoppen, in der der Domaininhaber noch verlängern kann, sofern die Registry dies zulässt. Die Domain zeigt dabei möglicherweise keinen Hold-Code. ## Pending-Codes und Codes der Grace Periods Die Pending-Codes (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer und pendingDelete) bedeuten, dass eine Anfrage eingegangen, aber nicht abgeschlossen ist. Während einer Sunrise-Phase kann pendingCreate bedeuten, dass der Name am Ende dieser Phase zugeteilt wird. Die Codes der Grace Periods (addPeriod, renewPeriod, autoRenewPeriod und transferPeriod) dienen der Information. Löscht der Registrar die Domain während einer dieser Phasen, schreibt die Registry ihm die Kosten der Registrierung, Verlängerung oder des Transfers gut. Die Gutschrift geht an den Registrar, nicht an den Domaininhaber. Jede Registry legt die Dauer jeder Grace Period fest. Die Löschung verläuft bei gTLDs in diesen Schritten (Stand Oktober 2026): 1. Der Registrar löscht die Domain. Der EPP-Status wird pendingDelete und der RGP-Status redemptionPeriod, der 30 Tage dauert, außer bei gesponserten gTLDs. Die Domain wird nicht aufgelöst und kann nicht übertragen werden. 2. Beantragt der Registrar eine Wiederherstellung, wird der Status pendingRestore, während die Registry auf einen Wiederherstellungsbericht wartet; die ICANN beschreibt diese Frist als häufig sieben Tage. Geht der Bericht ein, kehrt die Domain zu ok oder ihrem früheren Status zurück. Wenn nicht, kehrt sie zu redemptionPeriod zurück. 3. Wird die Domain nicht wiederhergestellt, bleibt sie nach dem Ende von redemptionPeriod fünf Kalendertage in pendingDelete, wird dann aus der Datenbank der Registry entfernt und ist wieder zur Registrierung verfügbar. ## Was bei einem unerwarteten Status zu tun ist - Die Domain in ICANN Lookup abfragen, feststellen, ob es ein Client- oder ein Server-Code ist, und den Registrar kontaktieren. Bei Server-Codes klärt der Registrar die Sache mit der Registry. - pendingTransfer oder pendingUpdate, die der Domaininhaber nicht beantragt hat: sofort den Registrar kontaktieren und ihn bei einem Transfer bitten, die Anfrage abzulehnen. - redemptionPeriod: sofort den Registrar kontaktieren, um die Möglichkeiten zu besprechen. Im Einzelfall sollte sich der Domaininhaber beim Registrar, bei der Registry oder bei einem Anwalt erkundigen. Ein Beispiel: ICANN Lookup zeigt example.com als „client transfer prohibited“, und der Domaininhaber möchte den Registrar wechseln. Er hebt die Sperre in seinem Konto auf oder bittet den Registrar darum. Sobald der Transfer beantragt ist, zeigt die Domain pendingTransfer; reagiert der abgebende Registrar nicht innerhalb von fünf Kalendertagen, schließt die Registry den Transfer ab. Danach kann die Domain transferPeriod zeigen, was kein Handeln erfordert. ## Quellen - [EPP Status Codes | What Do They Mean, and Why Should I Know?](https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en) - [Transfer Policy](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy) - [Approved Resolutions | Regular Meeting of the ICANN Board | 7 June 2026](https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-06-2026-en) - [Expired Registration Recovery Policy](https://www.icann.org/en/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-en) ## verwandte begriffe - [EPP](https://tldlog.com/de/glossar/epp/) - [clientHold](https://tldlog.com/de/glossar/clienthold/) - [serverHold](https://tldlog.com/de/glossar/serverhold/) - [clientTransferProhibited](https://tldlog.com/de/glossar/clienttransferprohibited/) - [RDAP](https://tldlog.com/de/glossar/rdap/)