Uma migração de e-mail com domínio próprio do cPanel transfere caixas postais de uma hospedagem cPanel combinada (Bluehost, HostGator, Hostinger ou semelhante) para um provedor especializado sem perder mensagens recebidas durante a transição. A chave é a recepção em paralelo: configurar o novo provedor enquanto o antigo ainda recebe e depois alterar os registros MX com um TTL de DNS baixo, para que a janela de transição dure minutos em vez de horas.
A maioria dos guias de migração do cPanel ignora a recepção em paralelo e descreve uma transição a frio, que pode perder mensagens durante a propagação do DNS. Uma transição a frio costuma perder 10-50 mensagens, dependendo do volume recebido. A abordagem paralela abaixo procura evitar essa perda. O trabalho adicional de configuração leva 30 minutos e ajuda a proteger essas mensagens.
Este guia apresenta a transição em seis etapas, com blocos de código de registros DNS. Para uma visão mais ampla, consulte mover o e-mail para um novo provedor.
Por que uma migração limpa do cPanel é importante
Uma migração limpa é importante porque as mensagens em trânsito durante a propagação do DNS representam um risco real para a receita. Uma transição a frio com propagação de várias horas perde tudo o que chegar ao MX antigo depois que ele parar de aceitar mensagens. A maioria dos responsáveis só percebe o custo quando um cliente reclama.
A abordagem de seis etapas evita a janela de perda com recepção em paralelo: os provedores antigo e novo recebem simultaneamente durante a transição, e o responsável inicia manualmente a desativação somente depois de confirmar que todas as mensagens em trânsito chegaram. A disciplina adicional custa 30 minutos de configuração e pode evitar uma perda difícil de delimitar.
Resumo da transição em seis etapas
Seis etapas abrangem a migração do cPanel com recepção em paralelo. A ordem importa: o resultado de cada etapa permite executar a próxima. O tempo total é de cerca de uma semana, desde a redução do TTL até a desativação completa; o trabalho ativo é de aproximadamente 3-4 horas distribuídas ao longo da semana.
- Reduza o TTL do DNS com 48 horas de antecedência. Isso diminui o tempo de propagação do MX de horas para minutos durante a transição.
- Provisione as caixas no novo provedor. Crie caixas correspondentes no novo serviço enquanto mantém as antigas ativas.
- Copie o histórico por IMAP. Uma ferramenta de migração IMAP no servidor copia as mensagens existentes das caixas antigas para as novas.
- Altere os registros MX. Atualize o DNS para apontar ao novo provedor; os dois recebem durante a propagação.
- Verifique a autenticação e o percurso completo. Confirme que SPF, DKIM e DMARC são aprovados em três destinatários a partir do novo provedor.
- Desative as caixas antigas. Aguarde 48-72 horas após alterar o MX e desative-as quando as mensagens em trânsito tiverem chegado.
Cada etapa funciona como um ponto de controle; reverter qualquer etapa até a etapa 4 é simples. Depois da etapa 4, a alteração do MX, ainda é possível reverter, mas isso fica caro na operação porque as mensagens começam a se acumular no novo provedor. Uma transição padrão não deve precisar de reversão se as etapas 1-3 forem executadas corretamente.
Etapa 1: reduzir o TTL do DNS com 48 horas de antecedência
Reduza o TTL de DNS dos registros MX existentes 48 horas antes da transição planejada. O TTL padrão costuma ser 3600 segundos (1 hora) ou 86400 (24 horas). Defina-o como 300 segundos (5 minutos), para que a alteração do MX na etapa 4 se propague em minutos, e não em horas.
A mudança é feita no painel do host de DNS. Edite o TTL de cada registro MX, defina o valor como 300 e salve. Aguarde 48 horas para o TTL atual expirar e o novo valor baixo se propagar. Depois da etapa 6, eleve novamente o TTL para 3600 durante a operação normal. Exemplo de alteração de registro DNS no Cloudflare:
; before: MX record with default TTL
yourcompany.com. 3600 IN MX 10 mail.oldhost.example.com.
; after: MX record with low TTL for migration window
yourcompany.com. 300 IN MX 10 mail.oldhost.example.com.
Etapa 2: provisionar caixas no novo provedor
Provisione caixas correspondentes no novo provedor. Adicione o domínio à TrekMail, verifique a propriedade pelo registro TXT e crie uma caixa para cada endereço existente na hospedagem cPanel antiga. Nesse ponto, as novas caixas estão prontas, mas o MX ainda aponta ao provedor antigo.
Gere os valores de SPF, DKIM e DMARC fornecidos pelo novo provedor. Ainda não os publique; isso acontecerá na etapa 4, junto com a alteração do MX. Gerá-los com antecedência garante que os valores estejam prontos quando chegar a etapa 4. Esse pré-provisionamento torna possível a recepção em paralelo mais adiante. Consulte migração IMAP para saber os detalhes da ferramenta.
Etapa 3: copiar o histórico por IMAP
Use a ferramenta de migração IMAP do novo provedor para copiar o histórico das caixas cPanel antigas para as novas. A ferramenta no servidor da TrekMail (Starter e planos superiores) faz isso pelo painel: forneça as credenciais IMAP da hospedagem antiga e deixe que ela copie pasta por pasta ao longo de algumas horas.
A migração é executada em segundo plano enquanto o MX ainda aponta ao provedor antigo. Ele continua recebendo mensagens novas; o novo fica com a cópia histórica. Quando a migração termina, os dois têm a mesma estrutura de pastas e as mesmas mensagens, exatamente o estado necessário para a transição com recepção em paralelo da etapa 4. Consulte lista de verificação para migração de e-mail como roteiro estruturado.
Etapa 4: alterar os registros MX
A quarta etapa atualiza os registros MX no host de DNS para que apontem ao novo provedor de caixas postais. Publique os novos valores MX, além dos registros SPF, DKIM e DMARC da etapa 2. A propagação de DNS leva cerca de 5 minutos graças ao TTL baixo da etapa 1. Durante a janela de propagação, os dois provedores recebem em paralelo.
; new MX records pointing at TrekMail
yourcompany.com. 300 IN MX 10 mx1.trekmail.net.
yourcompany.com. 300 IN MX 20 mx2.trekmail.net.
; published SPF, DKIM, DMARC TXT records
yourcompany.com. 300 IN TXT "v=spf1 include:_spf.trekmail.net ~all"
trekmail._domainkey.yourcompany.com. 300 IN TXT "v=DKIM1; k=rsa; p=..."
_dmarc.yourcompany.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourcompany.com"
A janela de recepção em paralelo evita o intervalo habitual de perda. Tudo o que for enviado durante a propagação chega ao provedor antigo, ainda ativo, ou ao novo, recém-ativado, em vez de retornar por causa de uma lacuna entre ambos. Mantenha as caixas antigas ativas e acessíveis por pelo menos 48 horas depois de alterar o MX, para receber mensagens em trânsito que ainda estejam chegando.
Etapa 5: verificar a autenticação e o percurso completo
Verifique a autenticação das mensagens enviadas pelo novo provedor. Envie mensagens de teste de cada caixa nova para contas do Gmail, Outlook.com e Yahoo. Confirme que os cabeçalhos mostram SPF=PASS, DKIM=PASS e DMARC=PASS nos três. Qualquer FAIL significa que os registros publicados na etapa 4 precisam ser ajustados antes de considerar a transição concluída.
Verifique também se as mensagens chegam corretamente ao novo provedor. Envie uma mensagem de teste de um endereço externo para uma das novas caixas e confirme que ela chega à caixa de entrada do novo serviço em poucos minutos. Se chegar ao provedor antigo, a propagação do DNS ainda não terminou; aguarde mais 10-15 minutos e teste novamente.
Etapa 6: desativar as caixas antigas
Desative as caixas antigas 48-72 horas depois de alterar o MX. Nesse momento, a propagação do DNS deve estar concluída globalmente e os remetentes já não devem encaminhar mensagens ao MX antigo. Desative as caixas no painel do cPanel; mantenha o plano cPanel ativo para o site, se necessário, mas desative o recebimento de mensagens.
Se o cPanel também hospedar o site e você não quiser continuar pagando pelo serviço, este é o momento de migrar o site para uma hospedagem web separada. A migração do e-mail do cPanel estará concluída quando o serviço antigo for desativado e o novo provedor estiver recebendo corretamente por vários dias. Eleve novamente o TTL do DNS para 3600 segundos durante a operação normal.
Próximos passos
A migração do cPanel com recepção em paralelo leva cerca de uma semana no calendário e 3-4 horas de trabalho ativo. O objetivo é evitar perda de mensagens e realizar uma transição limpa para um provedor especializado, com autenticação adequada em todas as mensagens enviadas.
O modelo de seis etapas é repetível: aplique-o da mesma forma a cada domínio cPanel adicional, e o processo ficará mais rápido a cada repetição.
Experimente o TrekMail Nano gratuitamente em trekmail.net/pricing, sem cartão. O Starter por $4/mês inclui a ferramenta de migração IMAP no servidor necessária na etapa 3. A plataforma assume as tarefas operacionais de hospedagem de caixas que os provedores cPanel deixavam para você gerenciar no pacote combinado.
Uma observação operacional: a janela de recepção em paralelo da etapa 4 é a razão estrutural pela qual essa abordagem busca evitar perda de mensagens. Transições a frio perdem mensagens porque há um intervalo entre o momento em que o provedor antigo para e aquele em que o novo começa a receber globalmente, durante o qual as mensagens retornam. A recepção em paralelo elimina o intervalo mantendo os dois ativos durante a propagação.
A migração do cPanel costuma ser operacionalmente mais simples do que muitos responsáveis esperam. O medo de uma falha no e-mail pode atrasar a mudança por meses, enquanto o custo de entregabilidade da hospedagem cPanel combinada se acumula. A abordagem de seis etapas reduz o risco de perda que provoca esse atraso, por isso quem faz uma migração costuma hesitar menos para repeti-la em outros domínios.
Para quem gerencia vários domínios personalizados em hospedagens cPanel, o modelo se aplica a cada domínio: as mesmas seis etapas com entradas DNS diferentes. Planeje as transições em dias separados, em vez de executá-las ao mesmo tempo. A atenção necessária durante cada migração é pequena, mas real; transições consecutivas criam carga cognitiva desnecessária e aumentam a probabilidade de uma etapa ser ignorada.
