Uma transferência de nome de domínio mal preparada resulta em e-mails perdidos, um site inacessível ou um domínio bloqueado em status pendingTransfer por dias. O procedimento em si é simples no papel: desbloquear, recuperar o código EPP, validar do lado do novo registrador. O que causa problemas são os detalhes técnicos que a maioria dos guias ignora, especialmente a gestão da zona DNS durante a transição e as especificidades relacionadas às extensões nacionais.
Zona DNS e registros a serem salvos antes da transferência de domínio
A transferência move o controle administrativo do domínio, não a zona DNS em si. Observamos regularmente perdas de registros MX ou TXT após a migração, porque a zona hospedada no antigo registrador não foi duplicada no novo antes da transição.
Leitura complementar : As tendências de moda imperdíveis do ano para um estilo único e marcante
Antes de qualquer manipulação, exporte toda a sua zona DNS. Verifique cada tipo de registro: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), e os eventuais registros SRV. Se o seu domínio usar DNSSEC, desative-o antes de iniciar a transferência: um registro DS órfão no registro provoca falhas de resolução enquanto o novo registrador não republicar suas próprias chaves.
Recrie todos esses registros no novo provedor ou em um serviço DNS de terceiros (Cloudflare, Route 53) antes de iniciar a transferência. Uma vez que a zona esteja pronta de ambos os lados, a transição administrativa não terá mais impacto na resolução. Se você está procurando como transferir um nome de domínio com Fireblog, você encontrará essa lógica de preparação DNS aplicada passo a passo.
Veja também : Os passos essenciais para conectar um novo agente à Cidade de Marselha
Código EPP, desbloqueio e proteção WHOIS: os pré-requisitos técnicos da transferência
Três bloqueios impedem uma transferência se você não os remover na ordem correta.
- O status clientTransferProhibited (ou bloqueio de registrador) deve ser removido pela interface do seu registrador atual. Enquanto estiver ativo, qualquer solicitação de transferência será automaticamente recusada pelo registro.
- O código de autorização EPP (ou Auth-Code) é uma senha de uso único vinculada ao domínio. Sua validade varia de acordo com o registrador, às vezes apenas alguns dias. Recupere-o no momento em que estiver pronto para iniciar o procedimento, não com antecedência.
- A proteção de privacidade WHOIS deve ser desativada temporariamente. Vários registradores ocultam o endereço de e-mail do titular por trás de um proxy. O e-mail de validação da transferência é enviado para o endereço WHOIS: se ele apontar para um serviço de privacidade que filtra ou redireciona mal, a validação falha silenciosamente.
Recomendamos verificar o WHOIS público do domínio após desativar a proteção, para confirmar que o endereço de e-mail exibido é realmente aquele que você consulta. Um e-mail de validação não recebido é a principal causa de transferência abortada.
O bloqueio de sessenta dias após alteração WHOIS
A política da ICANN impõe um bloqueio de sessenta dias após qualquer mudança de titular nos gTLD (.com, .net, .org). Se você recentemente alterou o nome ou o e-mail do titular no WHOIS, a transferência será recusada durante esse período. Planeje suas atualizações de contato bem antes da migração, ou faça-as depois.
Transferência de domínio de acordo com a extensão: gTLD, ccTLD e casos especiais
Os artigos generalistas descrevem um processo universal. Na prática, cada tipo de extensão obedece às suas próprias regras de transferência.
Para os gTLD (.com, .net, .org), o processo é padronizado pela ICANN: código EPP, solicitação no novo registrador, e-mail de confirmação, e então um prazo de cinco a sete dias durante o qual o antigo registrador pode aprovar ou deixar expirar a solicitação. A aprovação explícita do lado do antigo registrador acelera o procedimento.
Os ccTLD (extensões nacionais) seguem regras diferentes. O .fr, gerido pela AFNIC, utiliza um código de autorização semelhante ao código EPP, mas o procedimento de mudança de escritório de registro passa por uma Solicitação de Operação Afnic (DOA). O .uk funciona com um sistema de tags: você solicita ao seu registrador atual para mudar a tag IPS para o novo provedor, sem código EPP. O .de (DENIC) impõe um Auth-Code, mas com um processo de validação distinto.
Essas diferenças têm um impacto direto nos prazos. Uma transferência de .com geralmente leva menos de uma semana. Um ccTLD pode exigir várias semanas se documentos de identidade ou residência forem exigidos pela autoridade nacional.
E-mails e certificado SSL após a transição
A transferência de domínio não transfere sua hospedagem web nem sua mensageria. Se seus registros MX apontavam para os servidores do antigo registrador, seus e-mails deixarão de funcionar assim que a zona DNS for alterada. Verifique se os MX apontam para seu provedor de mensageria real (Google Workspace, Microsoft 365, servidor dedicado) e não para um serviço ligado ao registrador de saída.
No que diz respeito ao SSL, um certificado Let’s Encrypt se renova automaticamente se a validação DNS ou HTTP ainda estiver funcional. Um certificado pago vinculado ao antigo provedor de hospedagem deverá ser reemitido ou transferido. Verifique a data de expiração e o modo de validação antes da transferência para evitar uma transição para HTTP não seguro.
Checklist de verificação pós-transferência do nome de domínio
Uma vez que o domínio esteja exibido no novo registrador, o trabalho não está terminado. Observamos que a maioria dos incidentes ocorre nas quarenta e oito horas seguintes à transição, quando ninguém verifica mais nada.
- Compare a zona DNS ativa com seu backup inicial. Cada registro A, MX, CNAME e TXT deve corresponder exatamente.
- Envie um e-mail teste para e de cada endereço vinculado ao domínio para confirmar o bom funcionamento dos MX.
- Verifique a resolução DNSSEC se você a reativou: uma ferramenta como DNSViz permite identificar uma cadeia de confiança quebrada.
- Reative o bloqueio do domínio (clientTransferProhibited) e a proteção WHOIS no novo registrador.
- Verifique se o certificado SSL é válido e se seu site responde bem em HTTPS sem erro de certificado.
A transferência de um nome de domínio continua sendo uma operação administrativa, não técnica no sentido estrito. O que provoca as interrupções é a falta de preparação DNS antecipada e o esquecimento das verificações posteriores. Prepare a zona antes, verifique tudo depois: entre os dois, a transferência em si leva apenas alguns cliques.