--- id: "epp-status-codes" kind: "glossary-term" title: "códigos de status EPP" language: "pt-BR" category: "Transferências e EPP" updated: "2026-10-10T23:13:06Z" canonical: "https://tldlog.com/pt/glossario/codigos-status-epp/" translations: en: "https://tldlog.com/glossary/epp-status-codes/" es: "https://tldlog.com/es/glosario/codigos-estado-epp/" 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/" ru: "https://tldlog.com/ru/glossariy/kody-statusov-epp/" zh-Hans: "https://tldlog.com/zh/cihui/epp-zhuangtaima/" --- # códigos de status EPP Rótulos padrão de um domínio que mostram seu estado e quais ações são permitidas, como transferência, atualização, renovação ou exclusão. Os códigos que começam com client são definidos pelo registrador, e os que começam com server, pelo registro. Eles aparecem nos resultados do RDAP. Todo nome de domínio tem pelo menos um código de status: um rótulo curto, como ok ou clientTransferProhibited, que diz em que estado está o registro e quais ações estão bloqueadas. Os códigos vêm do EPP, a linguagem padrão que os registradores usam para se comunicar com os registros. Lê-los explica por que um domínio parou de funcionar, se está protegido contra roubo e se está perto da exclusão. ## O que são os códigos de status de domínio e onde vê-los Os códigos são definidos no padrão EPP para nomes de domínio, a RFC 5731, e na sua extensão para períodos de carência, a RFC 3915, que acrescenta os códigos do período de carência para resgate (RGP). Nos gTLDs, o lugar para consultá-los é uma busca RDAP, como o ICANN Lookup ou a ferramenta de busca do próprio registrador. Desde 28 de janeiro de 2025, o RDAP substituiu o WHOIS como fonte definitiva dos dados de registro dos gTLDs (situação em outubro de 2026). O RDAP escreve os códigos como palavras minúsculas separadas por espaços, então clientTransferProhibited aparece como “client transfer prohibited”, e ok aparece como “active”. Os registradores devem exibir todos os status que se aplicam a um domínio. Os ccTLDs definem as próprias regras e podem mostrar o status de outra forma. Este texto segue o EPP e as políticas dos gTLDs. ## Códigos client e server: quem os definiu A primeira palavra de um código diz quem o definiu. - Os códigos que começam com client são definidos pelo registrador que gerencia o domínio, às vezes automaticamente no registro, às vezes a pedido do titular. - Os códigos que começam com server são definidos pelo registro. Eles têm precedência: um registrador não pode alterar um código server, enquanto um registro pode se sobrepor a um código client segundo as próprias políticas. - Os códigos sem nenhum dos dois prefixos, como ok, inactive e os códigos pending, são gerenciados pelo registro. Nos dois casos, o titular faz o pedido ao registrador. Para um código server, o registrador repassa o pedido ao registro, então a remoção costuma demorar mais. ## Códigos de bloqueio: o que fica bloqueado e por quê Quatro pares de códigos bloqueiam, cada um, uma ação. Enquanto um deles estiver ativo, o registro rejeita o pedido correspondente: - clientTransferProhibited e serverTransferProhibited: uma transferência para outro registrador. - clientUpdateProhibited e serverUpdateProhibited: alterações no domínio, como contatos ou servidores de nomes, exceto a remoção do próprio bloqueio. - clientDeleteProhibited e serverDeleteProhibited: a exclusão. - clientRenewProhibited e serverRenewProhibited: a renovação. Os bloqueios client de transferência, alteração e exclusão ajudam a proteger contra sequestro de domínio e fraude. Os bloqueios de renovação são raros: costumam aparecer durante disputas judiciais ou antes de uma exclusão. Nos gTLDs, a Política de Transferência da ICANN, na versão publicada em 21 de fevereiro de 2024 e em vigor em outubro de 2026, limita o clientTransferProhibited. Se o registrador não oferece uma forma de o próprio titular removê-lo, deve removê-lo em até cinco dias corridos após o pedido do titular, e não pode recusar apenas por causa de uma disputa de pagamento. Em outubro de 2026, mudanças na Política de Transferência foram adotadas, mas não estão em vigor. A Diretoria da ICANN as adotou em 7 de junho de 2026 (resolução 2026.06.07.04), e nenhuma data de vigência foi anunciada. Elas incluem uma restrição obrigatória a transferências nas primeiras 720 horas (30 dias) após o registro. O registrador pode confirmar quais regras se aplicam. Os bloqueios server são incomuns. A ICANN cita disputas judiciais, o pedido do próprio titular e um domínio em redemptionPeriod como os motivos habituais. Alguns registros oferecem um serviço de bloqueio no registro (registry lock), solicitado por meio do registrador, que usa códigos server como proteção extra. ## Códigos de suspensão (hold): por que um domínio para de funcionar clientHold e serverHold dizem ao registro que não publique a delegação do domínio no DNS. O site e o e-mail param de funcionar, mas o domínio continua registrado. O clientHold é incomum. Documentos da ICANN o associam a falta de pagamento, disputas judiciais, a etapa pendente de exclusão, dados de contato não verificados e combate ao abuso do DNS. O serverHold é definido pelo registro; a orientação de conformidade da ICANN diz que os registros devem, em geral, encaminhar primeiro os casos de abuso ao registrador. Duas outras situações parecem semelhantes: - inactive: nenhum servidor de nomes está vinculado, então o domínio não resolve, mas o registro está em ordem. Se isso durar vários dias, a ICANN sugere contatar o registrador; alguns TLDs exigem documentos antes. - Vencimento: depois do vencimento, o registrador deve fazer o domínio parar de resolver durante parte do tempo em que o titular ainda pode renovar, quando o registro permite. O domínio pode não mostrar nenhum código de suspensão. ## Códigos pending e de período de carência Os códigos pending (pendingCreate, pendingUpdate, pendingRenew, pendingTransfer e pendingDelete) significam que um pedido foi recebido, mas não concluído. Durante um período sunrise, pendingCreate pode significar que o nome será atribuído quando esse período terminar. Os códigos de período de carência (addPeriod, renewPeriod, autoRenewPeriod e transferPeriod) são informativos. Se o registrador excluir o domínio durante um deles, o registro dá ao registrador um crédito pelo custo do registro, da renovação ou da transferência. O crédito vai para o registrador, não para o titular. Cada registro define a duração de cada período de carência. A exclusão segue estas etapas nos gTLDs (situação em outubro de 2026): 1. O registrador exclui o domínio. O status EPP passa a ser pendingDelete e o status RGP passa a ser redemptionPeriod, que dura 30 dias, exceto nos gTLDs patrocinados. O domínio não resolve e não pode ser transferido. 2. Se o registrador pede uma restauração, o status passa a ser pendingRestore enquanto o registro aguarda um relatório de restauração, um prazo que a ICANN descreve como frequentemente de sete dias. Se o relatório chega, o domínio volta a ok ou ao status anterior. Se não chega, volta a redemptionPeriod. 3. Se o domínio não é restaurado, fica em pendingDelete por cinco dias corridos após o fim do redemptionPeriod, depois é removido da base de dados do registro e fica disponível para registro. ## O que fazer diante de um status inesperado - Consultar o domínio no ICANN Lookup, observar se o código é client ou server e contatar o registrador. Para códigos server, o registrador trata com o registro. - pendingTransfer ou pendingUpdate que o titular não pediu: contatar o registrador imediatamente e, no caso de uma transferência, pedir que a recuse. - redemptionPeriod: contatar o registrador sem demora para discutir as opções. Para um caso específico, o titular deve consultar o registrador, o registro ou um advogado. Um exemplo prático: o ICANN Lookup mostra example.com como “client transfer prohibited”, e o titular quer mudar de registrador. Ele remove o bloqueio na sua conta ou pede ao registrador que o remova. Depois que a transferência é pedida, o domínio mostra pendingTransfer; se o registrador atual não responder em cinco dias corridos, o registro a conclui. Em seguida, o domínio pode mostrar transferPeriod, o que não exige nenhuma ação. ## Fontes - [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) ## termos relacionados - [EPP](https://tldlog.com/pt/glossario/epp/) - [clientHold](https://tldlog.com/pt/glossario/clienthold/) - [serverHold](https://tldlog.com/pt/glossario/serverhold/) - [clientTransferProhibited](https://tldlog.com/pt/glossario/clienttransferprohibited/) - [RDAP](https://tldlog.com/pt/glossario/rdap/)