Migração de e-mail tem uma característica que a torna mais delicada que a de um site: o erro é silencioso.

Um site fora do ar gera reclamação em minutos. Uma mensagem que deixou de chegar não gera nada — nem para quem enviou, que muitas vezes recebe uma confirmação de entrega em um servidor que já não é o seu, nem para quem deveria receber, que simplesmente não sabe da existência dela.

A boa notícia é que o procedimento é previsível, e praticamente todos os problemas vêm de uma única causa: fazer as coisas na ordem errada. Este guia organiza a migração em cinco fases, com atenção especial ao momento exato de trocar os registros MX.

O princípio que evita perda de mensagens

Uma ideia orienta o roteiro inteiro: transferir antes, apontar depois.

Os registros MX definem para onde as mensagens novas são entregues. Alterá-los antes de transferir o histórico significa que as mensagens antigas continuam no provedor anterior enquanto as novas chegam ao novo — e reconciliar isso depois é trabalhoso e propenso a perdas.

O segundo princípio, complementar: não desligue nada cedo. O provedor antigo precisa continuar ativo por alguns dias depois da troca, porque servidores pela internet demoram a perceber a mudança e continuarão entregando lá.

Fase 1 — Levantamento

Nada aqui afeta o serviço atual, e é a fase que determina o resultado.

1. Liste todas as contas, incluindo as que ninguém usa mais mas ainda recebem. Contas esquecidas de setores extintos costumam receber mensagens importantes.
2. Identifique os apelidos e redirecionamentos, que existem sem caixa própria e são facilmente esquecidos.
3. Verifique o tamanho de cada caixa e o total. Isso define quanto tempo a transferência vai levar.
4. Anote a configuração atual: servidores de entrada e saída, portas, método de autenticação. Guarde uma cópia.
5. Confira os registros de DNS atuais, especialmente MX e os registros de autenticação de envio.
6. Mapeie quem usa o quê: aplicativos de celular, programas de computador, webmail, integrações de sistemas que enviam mensagens usando essas contas.

O último item é o que mais gera surpresa. Sistemas internos, formulários do site, ferramentas de emissão de nota e plataformas de vendas frequentemente enviam usando uma conta do domínio — e param de funcionar depois da troca se ninguém atualizar a configuração.

Fase 2 — Preparação do novo ambiente

1. Crie as contas com exatamente os mesmos endereços.
2. Recrie apelidos e redirecionamentos.
3. Confirme o espaço disponível por caixa, comparando com o tamanho atual.
4. Teste o envio e o recebimento usando o endereço provisório que o provedor oferece, antes de qualquer alteração de DNS.
5. Prepare os registros de autenticação para o novo servidor de envio, mas ainda não os publique como definitivos.

Sobre o último ponto: trocar de provedor significa trocar de servidor de envio, e os registros que autorizam esse envio precisam acompanhar. Publicar apenas os do novo provedor antes da troca faz as mensagens ainda saindo pelo antigo falharem na verificação; não publicá-los depois faz as novas falharem. A solução é manter ambos autorizados durante a transição e remover o antigo ao final — o funcionamento desses registros está no artigo sobre e-mails caindo no spam.

Fase 3 — Transferência do histórico

Esta é a fase mais demorada e a que roda em paralelo, sem afetar o serviço.

A transferência é feita por ferramentas que se conectam às duas contas simultaneamente e copiam mensagens e estrutura de pastas. Como o protocolo de leitura mantém as mensagens no servidor, é possível copiar tudo enquanto o provedor antigo continua recebendo normalmente.

Pontos de atenção:

• Reserve tempo suficiente. Caixas grandes levam horas, e o processo depende da velocidade de ambos os provedores.
• Verifique a estrutura de pastas ao final, incluindo subpastas e itens enviados.
• Confira contas com contas grandes primeiro, para saber cedo se haverá problema de espaço.
• Confirme se calendário e contatos migram, quando existirem — eles nem sempre acompanham as mensagens.
• Faça um backup independente das caixas antes de começar. Se algo der errado, o histórico existe fora dos dois provedores.

Contas que usam o protocolo antigo, que baixa as mensagens para o dispositivo, exigem atenção redobrada: parte do histórico pode existir apenas no computador de alguém, e não no servidor. Nesses casos, a exportação a partir do próprio programa de e-mail é o caminho.

Fase 4 — A virada

Só depois da transferência concluída e verificada.

1. Reduza o TTL dos registros MX com pelo menos 24 a 48 horas de antecedência, para que a mudança se propague rápido.
2. Escolha o horário de menor movimento — fim de tarde de sexta e madrugadas costumam funcionar bem.
3. Faça uma sincronização final das mensagens recebidas desde a transferência inicial.
4. Altere os registros MX para o novo provedor.
5. Publique os registros de autenticação definitivos, mantendo temporariamente a autorização do provedor antigo.
6. Envie um e-mail de teste de fora para dentro e de dentro para fora, verificando o cabeçalho para confirmar por onde passou.
7. Restaure o TTL depois da propagação.

Durante a propagação, mensagens podem chegar aos dois servidores. É por isso que o antigo precisa permanecer ativo — e por isso a sincronização final não é a última: haverá uma segunda, dias depois.

Fase 5 — Acompanhamento e encerramento

A migração termina alguns dias depois da virada, não no mesmo dia.

1. Reconfigure os dispositivos dos usuários, com instruções escritas e antecedência. É a etapa que mais gera chamados.
2. Verifique o provedor antigo diariamente por alguns dias, para capturar mensagens que ainda cheguem lá.
3. Faça a sincronização final definitiva dessas mensagens.
4. Atualize os sistemas que enviam usando contas do domínio — a lista da fase 1.
5. Teste a entrega enviando para provedores diferentes e confirmando que as mensagens chegam à caixa de entrada, e não ao spam.
6. Remova a autorização do provedor antigo dos registros de autenticação, depois de confirmar que nada mais sai por lá.
7. Só então encerre o serviço anterior, mantendo um backup do que foi transferido.

O item 5 merece destaque: uma migração tecnicamente bem-sucedida pode terminar com as mensagens indo para o spam, porque o novo servidor de envio não tem histórico com aquele domínio. Testar a entrega faz parte do procedimento.

Os erros que causam perda

Erro	Consequência
Trocar os MX antes de transferir	Histórico fica no provedor antigo
Encerrar o serviço anterior cedo	Mensagens em trânsito são perdidas
Não reduzir o TTL antes	Propagação longa, com entrega dividida
Esquecer apelidos e redirecionamentos	Endereços deixam de existir sem aviso
Ignorar contas em desuso	Mensagens importantes deixam de chegar
Não atualizar os registros de autenticação	Mensagens legítimas vão para o spam
Esquecer sistemas que enviam pelo domínio	Notificações param sem ninguém perceber
Não testar a entrega ao final	Problema descoberto pelo cliente

Quando pedir apoio

Alguns cenários aumentam bastante a complexidade:

• Muitas contas, ou caixas com histórico muito extenso.
• Contas configuradas no protocolo antigo, com histórico apenas em dispositivos.
• Necessidade de migrar calendário, contatos e agendas compartilhadas.
• Domínios com vários serviços de envio já autorizados.
• Operações em que nenhuma mensagem pode ser perdida — jurídico, saúde, atendimento.

Vale confirmar antecipadamente se o novo provedor apoia a migração e o que esse apoio cobre: criação de contas, transferência do histórico, ajuste de DNS e suporte à reconfiguração dos usuários são escopos diferentes.

Conclusão

Migrar e-mails sem perder mensagens depende quase inteiramente de ordem. Transferir o histórico antes de trocar os registros MX, manter o provedor antigo ativo durante a propagação e fazer uma sincronização final dias depois resolvem a maior parte do risco.

Os dois pontos que mais escapam são os menos técnicos: a lista completa de contas — incluindo as em desuso e os apelidos — e o inventário dos sistemas que enviam mensagens usando o domínio. Ambos falham em silêncio.

Se você está planejando essa troca, conheça as soluções de e-mail corporativo da TBF Host e verifique o apoio disponível para a transferência das suas caixas.

Perguntas frequentes

Como migrar e-mails para outro provedor sem perder mensagens?

Transferindo o histórico antes de alterar os registros MX. Crie as contas no novo provedor, copie mensagens e pastas enquanto o serviço antigo continua ativo, reduza o TTL do DNS com antecedência, troque os MX no horário de menor movimento e faça uma sincronização final dias depois, antes de encerrar o serviço anterior.

Devo trocar os registros MX antes ou depois de transferir as mensagens?

Depois. Alterar os MX primeiro faz com que as mensagens novas cheguem ao novo provedor enquanto o histórico permanece no antigo, o que exige reconciliação posterior e aumenta o risco de perda. A ordem correta é sempre transferir antes e apontar depois.

Quanto tempo demora uma migração de e-mail?

Depende do número de contas e do tamanho das caixas. A transferência do histórico roda em paralelo, sem afetar o serviço, e pode levar horas em caixas grandes. A virada em si é rápida quando o TTL foi reduzido com antecedência, mas o acompanhamento se estende por alguns dias após a troca.

Por quanto tempo devo manter o provedor antigo ativo?

Por pelo menos alguns dias depois da troca dos registros MX. Servidores pela internet demoram a perceber a mudança e continuam entregando no endereço anterior durante esse período. Encerrar o serviço cedo demais é uma das causas mais comuns de mensagens perdidas em migrações.

O que é preciso atualizar além das contas de e-mail?

Os registros de autenticação de envio no DNS, para autorizar o novo servidor; os aplicativos e programas dos usuários, que precisam ser reconfigurados; e todos os sistemas que enviam mensagens usando contas do domínio — formulários do site, emissores de nota, plataformas de venda e integrações internas.

Meus e-mails podem cair no spam depois da migração?

Podem, e é um cenário comum. O novo servidor de envio não tem histórico associado ao seu domínio, e os registros de autenticação precisam ser atualizados para autorizá-lo. Testar a entrega para provedores diferentes ao final da migração faz parte do procedimento, e não é uma etapa opcional.

Como migrar contas configuradas em POP3?

Com atenção redobrada, porque parte do histórico pode existir apenas no dispositivo do usuário e não no servidor. Nesses casos, a exportação a partir do próprio programa de e-mail costuma ser o caminho, e vale fazê-la antes de qualquer alteração. É também uma boa oportunidade para migrar essas contas para IMAP.

Calendário e contatos migram junto com as mensagens?

Nem sempre. As ferramentas de transferência costumam copiar mensagens e estrutura de pastas, mas calendário, contatos e agendas compartilhadas podem exigir exportação e importação separadas. Vale confirmar isso com o novo provedor durante o levantamento, antes de iniciar a migração.