--- id: "epp-status-codes" kind: "glossary-term" title: "códigos de estado EPP" language: "es" category: "Transferencias y EPP" updated: "2026-10-10T10:28:55Z" canonical: "https://tldlog.com/es/glosario/codigos-estado-epp/" translations: en: "https://tldlog.com/glossary/epp-status-codes/" de: "https://tldlog.com/de/glossar/epp-statuscodes/" 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/" --- # códigos de estado EPP Etiquetas estándar de un dominio que muestran su estado y qué acciones están permitidas, como la transferencia, la actualización, la renovación o la eliminación. Los códigos que empiezan por client los fija el registrador, y los que empiezan por server, el registro. Aparecen en los resultados de RDAP. Todo nombre de dominio tiene al menos un código de estado: una etiqueta breve, como ok o clientTransferProhibited, que indica en qué situación está el dominio y qué operaciones están bloqueadas. Los códigos proceden de EPP, el protocolo estándar con el que los registradores se comunican con los registros. Leerlos explica por qué un dominio ha dejado de funcionar, si está protegido frente a robos y si se acerca a su eliminación. ## Qué son los códigos de estado y dónde consultarlos Los definen la norma EPP para nombres de dominio, la RFC 5731, y su extensión para periodos de gracia, la RFC 3915, que añade los códigos del periodo de gracia de redención (RGP). En los gTLD se consultan con una búsqueda RDAP, como ICANN Lookup o la herramienta del propio registrador. Desde el 28 de enero de 2025, RDAP sustituye a WHOIS como fuente de referencia de los datos de registro de los gTLD (a octubre de 2026). RDAP escribe los códigos en minúsculas y con espacios: clientTransferProhibited aparece como «client transfer prohibited», y ok, como «active». Los registradores deben mostrar todos los estados del dominio. Los ccTLD fijan sus propias normas y pueden mostrar el estado de otra forma. Este texto sigue el estándar EPP y las políticas de los gTLD. ## Códigos client y server: quién los fija La primera palabra del código indica quién lo ha puesto. - Los que empiezan por client los fija el registrador que gestiona el dominio, a veces de forma automática en el alta y a veces a petición del titular. - Los que empiezan por server los fija el registro. Tienen prioridad: el registrador no puede cambiar un código server, y el registro sí puede anular un código client según sus normas. - Los que no llevan prefijo, como ok, inactive y los códigos pending, los gestiona el registro. En ambos casos, el titular se dirige al registrador. Si el código es server, este traslada la petición al registro, y retirarlo suele tardar más. ## Códigos de bloqueo: qué impiden y por qué Hay cuatro parejas de códigos, y cada una bloquea una operación. Mientras uno está activo, el registro rechaza la solicitud correspondiente: - clientTransferProhibited y serverTransferProhibited: la transferencia a otro registrador. - clientUpdateProhibited y serverUpdateProhibited: los cambios en el dominio, como contactos o servidores de nombres, salvo retirar el propio bloqueo. - clientDeleteProhibited y serverDeleteProhibited: la eliminación. - clientRenewProhibited y serverRenewProhibited: la renovación. Los bloqueos client de transferencia, actualización y eliminación protegen frente a secuestros y fraudes. Los de renovación son raros: suelen aparecer en disputas legales o antes de una eliminación. En los gTLD, la Política de Transferencia de la ICANN, en la versión publicada el 21 de febrero de 2024 y vigente a octubre de 2026, limita clientTransferProhibited. Si el registrador no ofrece al titular una forma de retirarlo por su cuenta, debe retirarlo en cinco días naturales desde la petición, y no puede negarse solo porque haya una disputa de pago. A octubre de 2026, hay cambios en esta política adoptados pero no vigentes. La Junta Directiva de la ICANN los adoptó el 7 de junio de 2026 (resolución 2026.06.07.04), y no se ha anunciado su entrada en vigor. Incluyen una restricción obligatoria de transferencias durante las primeras 720 horas (30 días) tras el alta. El registrador puede confirmar qué normas se aplican. Los bloqueos server son poco frecuentes. La ICANN cita como motivos habituales las disputas legales, la petición del titular y que el dominio esté en redemptionPeriod. Algunos registros ofrecen un bloqueo en el registro, que se pide a través del registrador y usa códigos server como protección adicional. ## Códigos de suspensión: por qué un dominio deja de funcionar clientHold y serverHold indican al registro que no publique la delegación del dominio en el DNS. La web y el correo dejan de funcionar, pero el dominio sigue registrado. clientHold es poco habitual. Los documentos de la ICANN lo relacionan con impagos, disputas legales, dominios a punto de eliminarse, datos de contacto sin verificar y la contención del uso indebido del DNS. serverHold lo fija el registro; según las indicaciones de cumplimiento de la ICANN, ante un uso indebido el registro debería acudir primero al registrador. Hay dos situaciones parecidas: - inactive: el dominio no tiene servidores de nombres asociados y no resuelve, pero el registro está en orden. Si dura varios días, la ICANN aconseja contactar con el registrador; algunos TLD exigen antes documentación. - Vencimiento: tras el vencimiento, el registrador debe interrumpir la resolución durante parte del tiempo en que el titular aún puede renovar, si el registro lo permite. Puede que no se vea ningún código de suspensión. ## Códigos pendientes y de periodo de gracia Los códigos pending (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer y pendingDelete) indican que se ha recibido una solicitud aún no completada. Durante un periodo sunrise, pendingCreate puede significar que el nombre se asignará al terminar ese periodo. Los códigos de periodo de gracia (addPeriod, renewPeriod, autoRenewPeriod y transferPeriod) son informativos. Si el registrador elimina el dominio durante uno de ellos, el registro le abona un crédito por el coste del alta, la renovación o la transferencia. El crédito es para el registrador, no para el titular. Cada registro fija la duración de sus periodos de gracia. En los gTLD, la eliminación sigue estos pasos (a octubre de 2026): 1. El registrador elimina el dominio. El estado EPP pasa a pendingDelete y el estado RGP, a redemptionPeriod, que dura 30 días, salvo en los gTLD patrocinados. El dominio no resuelve y no puede transferirse. 2. Si el registrador pide la restauración, el estado pasa a pendingRestore mientras el registro espera el informe de restauración, un plazo que, según la ICANN, suele ser de siete días. Si el informe llega, el dominio vuelve a ok o a su estado anterior; si no, vuelve a redemptionPeriod. 3. Si no se restaura, el dominio sigue en pendingDelete cinco días naturales tras el fin de redemptionPeriod; después se borra de la base de datos del registro y queda libre. ## Qué hacer ante un estado inesperado - Consultar el dominio en ICANN Lookup, ver si el código es client o server y contactar con el registrador. Si es server, el registrador lo tramita con el registro. - pendingTransfer o pendingUpdate que el titular no ha pedido: contactar de inmediato con el registrador y, si es una transferencia, pedirle que la rechace. - redemptionPeriod: contactar enseguida con el registrador para ver qué opciones hay. Ante un caso concreto, conviene consultar al registrador, al registro o a un abogado. Un ejemplo: ICANN Lookup muestra example.com como «client transfer prohibited», y el titular quiere cambiar de registrador. Quita el bloqueo desde su cuenta o pide al registrador que lo retire. Una vez solicitada la transferencia, el dominio muestra pendingTransfer; si el registrador cedente no responde en cinco días naturales, el registro la completa. Después puede mostrar transferPeriod, que no requiere ninguna acción. ## Fuentes - [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) - [Política de recuperación de registraciones vencidas](https://www.icann.org/es/contracted-parties/consensus-policies/expired-registration-recovery-policy/expired-registration-recovery-policy-28-02-2013-es) ## términos relacionados - [EPP](https://tldlog.com/es/glosario/epp/) - [clientHold](https://tldlog.com/es/glosario/clienthold/) - [serverHold](https://tldlog.com/es/glosario/serverhold/) - [clientTransferProhibited](https://tldlog.com/es/glosario/clienttransferprohibited/) - [RDAP](https://tldlog.com/es/glosario/rdap/)