Central de Ajuda

Apontar um domínio para um servidor externo significa alterar o caminho usado pela internet para localizar um site ou outro serviço. O apontamento não transfere arquivos, banco de dados, contas de e-mail, certificado SSL, redirecionamentos nem a administração do servidor. Depois da mudança, cada configuração precisa ser feita por quem controla a camada que passou a atender a conexão.

Resposta rápida: se o site foi apontado para uma infraestrutura externa, as configurações que dependem desse site — como adicionar o domínio ao servidor, publicar arquivos, ajustar PHP, criar redirecionamentos, emitir e renovar o SSL, consultar logs, liberar firewall ou corrigir a aplicação — devem ser realizadas no provedor de destino. A WebinHost só consegue executar alterações na infraestrutura à qual possui acesso e que faz parte do serviço contratado.

O que significa “apontar o domínio”

O DNS funciona como um diretório: ele informa qual endereço ou serviço deve ser procurado para cada nome, como exemplo.com.br, www.exemplo.com.br ou mail.exemplo.com.br. Um apontamento pode alterar somente o site, somente um subdomínio, apenas o e-mail ou toda a autoridade DNS. Por isso, a frase “aponte meu domínio” não é informação suficiente para uma mudança segura.

Antes de alterar qualquer registro, identifique quatro componentes independentes:

1. Registro do domínio: mantém titularidade, contatos, renovação e indicação dos nameservers.
2. DNS autoritativo: publica os registros A, AAAA, CNAME, MX, TXT, CAA e outros.
3. Servidor de destino ou origem: recebe a conexão, reconhece o domínio e entrega o site, API ou e-mail.
4. Aplicação, proxy ou CDN: pode processar HTTPS, cache, firewall e redirecionamentos antes de chegar à origem.

Essas funções podem estar na mesma empresa ou em fornecedores diferentes. Para conhecer cada tipo de entrada, consulte o guia completo de registros DNS.

Quatro formas comuns de apontar para uma estrutura externa

Também é possível apontar apenas app.exemplo.com.br ou loja.exemplo.com.br para fora e manter o domínio principal na hospedagem atual. Veja como adicionar domínio, alias ou subdomínio no cPanel quando o destino estiver em uma conta cPanel administrada por você.

O que cada registro pode afetar

O Zone Editor do cPanel só altera a resposta pública quando a zona editada é realmente autoritativa para o domínio. Se os nameservers foram transferidos a outro provedor, uma mudança feita na zona local do cPanel não se propaga para a internet.

Apontamento DNS não é redirecionamento

Esta é a confusão mais comum. Um registro DNS responde “em qual endereço este nome está?”, enquanto um redirecionamento HTTP responde ao navegador “acesse outra URL”. DNS não envia status 301, 302, 307 ou 308; também não escolhe caminho, não converte /pagina-antiga em /pagina-nova, não preserva parâmetros e não força HTTPS.

Quando uma registradora oferece “redirecionamento de domínio”, normalmente existe um serviço web por trás: o domínio aponta para um servidor da própria registradora, esse servidor recebe a requisição e então devolve o status HTTP. Continua sendo um redirecionamento executado por um servidor, não pelo registro DNS isoladamente.

Se exemplo.com.br já aponta para o servidor externo, o redirecionamento precisa ser configurado no servidor, aplicação, balanceador ou CDN que recebe essa requisição. Uma regra criada no cPanel antigo não será executada porque o acesso não chega mais a ele. Para ambientes que ainda chegam ao cPanel, use o guia de redirecionamentos pelo cPanel e pelo arquivo .htaccess; se houver comportamento repetitivo, consulte como corrigir loop de redirecionamento e ERR_TOO_MANY_REDIRECTS.

Quem deve configurar o redirecionamento no destino

O administrador do destino deve confirmar quais hostnames chegam à aplicação e qual resultado é esperado. “Redirecionar o domínio” pode significar ações diferentes:

• enviar o domínio sem www para www, ou fazer o inverso;
• forçar HTTP para HTTPS;
• encaminhar todo um domínio antigo para um domínio novo;
• mapear cada URL antiga para a página equivalente, preservando SEO;
• manter ou remover caminho e parâmetros de consulta;
• usar redirecionamento permanente (301/308) ou temporário (302/307).

Para uma migração de site, uma única regra para a página inicial raramente basta. URLs relevantes devem apontar para seus equivalentes, sem cadeias e sem retornar para a origem. A documentação oficial da Cloudflare confirma que regras de encaminhamento operam na camada HTTP e podem definir status e preservação da query string.

O que acontece com o certificado SSL

O certificado precisa existir no ponto em que a conexão HTTPS é encerrada. Esse ponto pode ser o próprio servidor externo, um proxy, um balanceador ou a borda de uma CDN. Alterar A, AAAA, CNAME ou NS não copia o certificado instalado na hospedagem antiga e não garante que o destino aceite o domínio na porta 443.

Para o HTTPS funcionar, o destino precisa:

1. ter o domínio cadastrado no site virtual, projeto ou aplicação;
2. responder corretamente para todos os nomes usados, como domínio raiz e www;
3. possuir certificado válido, não expirado e compatível com esses nomes;
4. entregar a cadeia intermediária correta;
5. automatizar a renovação e manter disponível o método de validação;
6. aplicar o redirecionamento para HTTPS somente depois de o certificado estar ativo.

Quando o endereço público passa a levar ao servidor externo, a validação HTTP normalmente chega a esse novo servidor. Assim, o AutoSSL do cPanel antigo pode deixar de validar o domínio, mesmo que a conta de hospedagem permaneça ativa. O guia de AutoSSL, DCV e CAA no cPanel explica esse diagnóstico; para uma instalação sob seu controle, consulte também como emitir e instalar SSL no cPanel.

HTTP-01, DNS-01, CAA e renovação automática

Na validação HTTP-01, a autoridade certificadora procura um arquivo de desafio em http://dominio/.well-known/acme-challenge/. Se o DNS leva ao destino externo, esse destino deve publicar a resposta, normalmente pela porta 80. Na validação DNS-01, é criado um TXT em _acme-challenge.dominio; ela depende de acesso ao DNS autoritativo e pode validar certificados curinga.

O registro CAA pode limitar quais autoridades têm permissão para emitir. Uma entrada incompatível causa falha mesmo quando A e CNAME estão corretos. A renovação automática também precisa continuar funcionando depois da primeira emissão: um certificado instalado manualmente hoje poderá expirar mais tarde se ninguém mantiver o desafio, a integração ou as credenciais.

Um erro frequente é alterar o registro A e esquecer um AAAA antigo. Redes com IPv6 podem alcançar outro servidor, apresentar certificado diferente ou falhar de forma intermitente. Valide as duas famílias de endereço e nunca publique um AAAA apenas para “completar” a zona.

Quando existe Cloudflare, CDN ou proxy

Em um hostname com proxy ativo, há duas conexões distintas: visitante até a borda da CDN e CDN até o servidor de origem. Portanto, pode haver um certificado de borda e outro certificado na origem. Um cadeado válido para o visitante não prova que a conexão entre a CDN e o servidor esteja protegida corretamente.

No modo equivalente a Full (strict), a origem deve aceitar HTTPS na porta 443 e apresentar certificado válido, não expirado e correspondente ao hostname. Caso contrário, a borda pode retornar erro de certificado, como 526. Redirecionamentos duplicados na aplicação, no servidor e na CDN também podem criar loops. Antes de ativar proxy ou forçar HTTPS, documente qual camada executará cada regra.

O que muda no e-mail quando o site vai para fora

Apontar apenas o site não deveria, por si só, migrar as caixas de e-mail. Entretanto, o e-mail depende de vários registros que precisam continuar coerentes: MX, endereço do host indicado pelo MX, SPF, DKIM, DMARC, autodiscover e outros nomes usados pelos aplicativos.

Revise especialmente estes casos:

• se o MX aponta para mail.exemplo.com.br, preserve o A/AAAA correto desse hostname;
• se o próprio domínio raiz aparece como destino do MX, trocar seu A pode enviar conexões de e-mail ao servidor do site;
• ao mudar nameservers, copie toda a zona necessária antes da delegação, não apenas A e www;
• mantenha SPF, DKIM e DMARC no DNS autoritativo atual;
• se o servidor cPanel ainda envia formulários, confirme que ele está autorizado no SPF e que a aplicação usa SMTP autenticado;
• confirme o Email Routing do cPanel como Local ou Remote de acordo com o provedor real.

Para investigar falhas depois da troca, siga o diagnóstico de registros MX e DNS de e-mail. Certificados de mail, Webmail ou cPanel são independentes do certificado do site; veja também erros de certificado no cPanel e Webmail.

Serviços que podem continuar apontando para o local antigo

Cada hostname deve ser analisado separadamente. Migrar o site principal não altera automaticamente cpanel, webmail, mail, ftp, api, app ou outros subdomínios. Eles podem permanecer na WebinHost, seguir para o provedor externo ou deixar de ser necessários. A decisão deve ser registrada para evitar entradas órfãs.

Além do DNS, revise integrações que dependem do IP antigo: webhooks, callbacks de pagamento, allowlists, licenças, tarefas cron, acesso remoto ao banco, SFTP, APIs, monitoramento e backups. O servidor externo pode exigir portas, credenciais ou regras de firewall próprias, administradas pelo responsável por ele.

O que a hospedagem antiga ainda consegue fazer

Se o plano continua ativo, os arquivos, bancos e caixas existentes não são apagados apenas porque o DNS mudou. Porém, o domínio público passa a levar o usuário ao destino indicado. O conteúdo antigo pode ser acessível por URL temporária, hostname técnico ou alteração local do arquivo hosts, quando o ambiente permitir.

A equipe da hospedagem antiga pode cuidar dos componentes que continuam sob sua administração, como conta contratada, arquivos nela armazenados, caixas locais ou zona DNS autoritativa mantida no serviço. Ela não consegue, sem acesso e sem um serviço que inclua essa gestão:

• adicionar o domínio ao painel ou virtual host do terceiro;
• alterar arquivos, banco, versão do PHP, aplicação, Nginx, Apache ou IIS externos;
• criar redirecionamentos no servidor que agora recebe a visita;
• emitir, instalar ou renovar certificado no endpoint externo;
• consultar logs, liberar IP, ajustar WAF, CDN ou firewall de terceiros;
• garantir disponibilidade, backup, desempenho ou segurança do destino;
• corrigir valores de DNS que não foram fornecidos pelo administrador externo.

Em outras palavras: manter o registro de domínio ou o DNS na WebinHost não concede acesso ao servidor para onde o domínio foi apontado.

Matriz de responsabilidade

Se o servidor externo também for um serviço contratado da WebinHost, o limite depende do produto: um VPS com acesso root e um plano gerenciado têm escopos diferentes. Consulte servidores VPS ou gerenciamento de servidores para escolher o nível de administração adequado.

Cenários práticos

Site externo e e-mail na WebinHost

Altere somente os hostnames do site conforme os valores do novo provedor. Preserve MX, mail, SPF, DKIM, DMARC e demais registros de e-mail. O SSL do site pertence ao destino; o serviço de e-mail continua usando seus próprios certificados e portas.

Nameservers totalmente externos

Crie e confira a zona completa no novo DNS antes de trocar a delegação. A partir da mudança, registros editados na zona antiga não terão efeito público. DNSSEC exige coordenação especial: um DS antigo ou incompatível no registrador pode fazer o domínio parar de resolver.

Apenas um subdomínio externo

Crie A/AAAA ou CNAME somente para o subdomínio. O provedor externo deve cadastrar esse hostname e emitir SSL para ele. O domínio principal e os demais serviços permanecem onde os registros indicarem.

Domínio que deve apenas redirecionar

Escolha um servidor ou serviço de borda capaz de responder por HTTP e HTTPS aos hostnames de origem. Instale o SSL nesses hostnames e configure o status e a URL de destino. Um A apontado diretamente ao site final não transforma automaticamente um domínio em alias nem preserva SEO.

Checklist antes de solicitar o apontamento

1. Peça ao provedor externo as instruções oficiais e os valores exatos; não tente descobrir o IP por conta própria.
2. Defina se a alteração envolve domínio raiz, www, subdomínio, e-mail ou nameservers completos.
3. Confirme se o destino já cadastrou todos os hostnames e está pronto para atendê-los.
4. Exporte ou registre a zona atual e faça backup do site, banco e caixas envolvidos.
5. Liste A, AAAA, CNAME, MX, TXT, CAA, SRV e NS que precisam ser mantidos.
6. Planeje SSL: quem emite, qual método DCV será usado, quem instala e quem monitora a renovação.
7. Defina redirecionamentos, inclusive caminhos, parâmetros, www e HTTPS.
8. Reduza o TTL com antecedência apenas se houver janela planejada; respeite o tempo do valor que já estava em cache.
9. Defina responsável, horário, teste de aceite e plano de retorno.
10. Não cancele a hospedagem antiga antes de validar site, e-mail, dados, integrações e backups no destino.

Como validar depois da alteração

Propagação não é um botão nem um período fixo universal. O DNS autoritativo pode refletir a mudança rapidamente, enquanto resolvedores e dispositivos mantêm a resposta anterior até o TTL expirar. Consulte mais de uma rede e, se necessário, siga o guia para limpar o cache DNS do dispositivo e do roteador.

1. Consulte os NS públicos e confirme qual provedor é autoritativo.
2. Verifique A e AAAA do domínio raiz, www e subdomínios alterados.
3. Abra HTTP e HTTPS e confira o endereço final, o status e a ausência de loops.
4. Inspecione o certificado: nomes, emissor, validade e cadeia.
5. Teste uma URL interna inexistente e páginas importantes, não apenas a página inicial.
6. Envie e receba e-mail usando uma conta externa; verifique MX, SPF, DKIM e DMARC.
7. Teste Webmail, FTP/SFTP, APIs, formulários, webhooks e áreas autenticadas que fazem parte do projeto.
8. Compare logs e monitoramento no servidor que efetivamente recebeu a requisição.

Se o domínio não resolver, use o diagnóstico de DNS_PROBE_FINISHED_NXDOMAIN. Se o DNS estiver correto e o site continuar indisponível, siga o diagnóstico completo de site fora do ar.

Como voltar com segurança

O rollback só funciona se o ambiente anterior continuar íntegro e se os valores antigos tiverem sido registrados. Reverta os mesmos hostnames no DNS autoritativo, remova um AAAA incompatível quando aplicável, mantenha a zona e os serviços antigos disponíveis durante o TTL e confirme novamente site e e-mail. Não restaure apenas o A se a troca também envolveu NS, MX, TXT, CDN ou configurações na aplicação.

Se dados foram gravados nos dois ambientes durante a transição — pedidos, formulários, uploads ou mensagens — voltar o DNS não sincroniza essas alterações. O responsável pela aplicação deve reconciliar os dados antes da decisão final.

O que enviar em um chamado de apontamento

Para evitar atrasos, informe:

• domínio e hostnames exatos a alterar;
• serviço que ficará externo: site, subdomínio, e-mail, CDN ou toda a zona;
• registros e valores copiados da documentação do provedor de destino;
• se domínio raiz e www devem abrir o mesmo conteúdo;
• quais serviços devem continuar na WebinHost;
• quem administrará o servidor externo, o SSL e os redirecionamentos;
• data e horário da mudança, fuso e contato responsável;
• plano de teste e valores para retorno.

Não envie senha em texto aberto no chamado. Se a solicitação trouxer apenas “aponte para o servidor externo”, o suporte precisará dos valores e do escopo antes de alterar o DNS. A WebinHost pode publicar registros na zona que administra, mas o provedor externo deve preparar e manter a infraestrutura de destino.

Perguntas frequentes

Ao apontar para fora, meu conteúdo é apagado do cPanel?

Não. O DNS muda o caminho público, não apaga arquivos. O conteúdo permanece enquanto a conta estiver ativa, mas deixa de ser o conteúdo servido por aquele hostname.

A WebinHost pode emitir o SSL mesmo com o site em outro servidor?

O certificado deve ser emitido e instalado por quem controla o ponto de HTTPS e consegue concluir a validação. Se a conexão termina no servidor externo, é esse ambiente — ou sua CDN — que deve manter o certificado. Uma validação DNS pode exigir cooperação de quem administra a zona, mas isso não instala o certificado no destino.

Por que o AutoSSL do cPanel começou a falhar depois do apontamento?

Porque o desafio público pode estar chegando ao servidor novo, não ao cPanel antigo. Também verifique CAA, AAAA, redirecionamentos e quais nameservers são autoritativos.

É possível manter os e-mails na WebinHost?

Sim, desde que MX, host do MX, registros de autenticação e roteamento permaneçam corretos. Trocar os nameservers sem copiar a zona é uma causa comum de interrupção.

Por que um redirecionamento criado no cPanel não funciona mais?

Porque o navegador passou a conectar-se ao servidor externo. A regra do cPanel antigo não recebe a requisição e, portanto, não consegue responder com o redirecionamento.

Posso apontar antes de o servidor externo estar pronto?

Não é recomendado. O destino deve reconhecer o domínio, entregar o conteúdo e ter o SSL planejado antes da troca. Caso contrário, visitantes podem receber página padrão, erro de conexão ou alerta de certificado durante a propagação.

Qual é o prazo exato de propagação?

Não existe um único prazo para todos. Ele depende do TTL anterior, caches, tipo de alteração, delegação e resolvedor consultado. O dado mais útil é verificar os nameservers autoritativos e comparar a resposta deles com a resposta recebida pelos usuários.

Referências oficiais: cPanel — Zone Editor e tipos de registros DNS; cPanel — SSL/TLS, DCV e CAA; Let’s Encrypt — validações HTTP-01 e DNS-01; Cloudflare — nameservers autoritativos; Cloudflare — redirecionamentos HTTP; e Cloudflare — HTTPS Full (strict) entre borda e origem.

Recursos relacionados

Continue com tutoriais, ferramentas e serviços relacionados ao diagnóstico.