Como migrar o e-mail corporativo de provedor sem perder mensagens

Quase toda empresa que pensa em trocar de provedor de e-mail adia a decisão pelo mesmo motivo: medo de perder mensagens. O serviço atual pode estar caro, lento, caindo em spam ou com caixa sempre cheia, e mesmo assim parece mais seguro aguentar do que arriscar anos de histórico e alguns dias de pedidos que não chegam.

O medo tem fundamento, porque migração feita no improviso perde mensagem mesmo. Mas a perda quase nunca vem de onde as pessoas imaginam. O histórico antigo é a parte fácil de copiar. O que some são os e-mails que chegam durante a troca, os encaminhamentos que ninguém lembrava que existiam e os sistemas que enviavam pelo servidor antigo e param sem avisar.

Este guia mostra a migração na ordem em que ela deve acontecer, do inventário ao cancelamento do serviço antigo, para que a troca seja um evento de um dia, e não uma semana de mensagens perdidas. Se a dúvida ainda é para onde ir, comece pela comparação entre Google Workspace, Microsoft 365 e e-mail da hospedagem.

Onde as mensagens realmente se perdem

Entender o mecanismo ajuda a não gastar esforço no lugar errado. O e-mail de uma empresa depende de duas coisas separadas: o domínio, que diz para o mundo onde entregar as mensagens, e o servidor de e-mail, que guarda as caixas. Migrar é trocar o servidor e depois avisar o domínio do novo endereço.

Esse aviso é feito pelo registro MX no DNS do domínio. Quando ele muda, os servidores do mundo não ficam sabendo todos ao mesmo tempo: cada um guarda a informação antiga por um período, o chamado TTL. Durante essa janela, parte das mensagens ainda chega no servidor antigo e parte já chega no novo. Se o antigo for desligado cedo demais, ou se ninguém olhar o que caiu nele depois da troca, essas mensagens se perdem.

Os outros pontos de perda são mais silenciosos:

• Encaminhamentos e aliases configurados no provedor antigo, como contato@ entregando para três pessoas, que não são criados no novo.
• Caixas de ex-funcionários que ninguém migrou porque ninguém usava, mas que ainda recebiam e-mail de cliente antigo.
• Formulários do site e sistemas que enviavam usando usuário e senha do servidor antigo.
• Pastas locais em programas como Outlook, que ficavam só no computador e não no servidor.

Cada um desses itens tem solução simples, desde que seja visto antes da virada.

O que precisa estar na sua mão antes de começar

Uma migração tranquila começa com acesso, não com ferramenta. Antes de contratar o novo serviço, confirme que a empresa tem:

1. A titularidade do domínio. O domínio precisa estar registrado no CNPJ da empresa, com acesso ao painel do registro. Se ele está no nome de uma agência ou de um ex-funcionário, resolva isso primeiro, como explicamos em domínio próprio, titularidade e renovação.
2. Acesso ao DNS. Às vezes o DNS não fica no registro do domínio, e sim na hospedagem ou num serviço como Cloudflare. Descubra onde ele está e quem tem a senha.
3. Acesso de administrador ao provedor atual, para listar caixas, aliases e encaminhamentos, e para redefinir senhas se for preciso.
4. A senha de cada caixa ou um meio de copiar o conteúdo sem ela, que a maioria dos provedores oferece para o administrador.

Sem esses quatro itens, a migração trava no meio, e travar no meio é exatamente o cenário em que as mensagens ficam divididas entre dois servidores por tempo demais.

Faça o inventário das caixas, aliases e encaminhamentos

O inventário é a etapa mais subestimada e a que mais evita problema. Monte uma planilha simples com tudo o que existe no provedor atual:

• Caixas de pessoas, com o tamanho de cada uma em gigabytes.
• Caixas de setor, como financeiro@, vendas@ e nfe@.
• Aliases, que são endereços que entregam em outra caixa sem ter caixa própria.
• Grupos e listas, que distribuem uma mensagem para várias pessoas.
• Encaminhamentos automáticos, inclusive os que mandam para endereços externos.
• Respostas automáticas e regras de filtro que alguém configurou no servidor.

Aproveite para limpar

O inventário é o melhor momento para decidir o que não precisa ir. Caixa de quem saiu há três anos pode virar um alias para o gestor, ou ser exportada para arquivo e encerrada. Caixa de setor que só recebe pode virar grupo. Cada caixa a menos é uma licença a menos no provedor novo, e no Workspace ou no Microsoft 365 isso é dinheiro todo mês. O post sobre e-mail de funcionário que sai da empresa detalha as opções.

Some o tamanho total

O tamanho das caixas decide duas coisas: o plano de armazenamento no destino e o tempo da cópia. Uma empresa de dez pessoas com caixas de 5 GB cada tem 50 GB para copiar, o que leva de algumas horas a mais de um dia, dependendo dos limites de velocidade dos dois provedores.

Como o histórico é copiado

Copiar o histórico é a parte que todo mundo teme e a que mais tem ferramenta pronta. Existem três caminhos, e quase sempre o primeiro resolve.

Cópia por IMAP, servidor para servidor

É o método padrão. Uma ferramenta se conecta ao servidor antigo e ao novo pelo protocolo IMAP e copia pasta por pasta, mantendo a estrutura, as datas e o status de lido ou não lido. Google Workspace e Microsoft 365 têm ferramentas próprias de migração que fazem isso pelo painel, e para outros destinos existem ferramentas como o imapsync.

A grande vantagem é que a cópia pode ser repetida. Você faz a primeira cópia dias antes da troca, com as caixas ainda em uso, e depois da virada roda de novo só para trazer o que chegou no meio tempo, sem duplicar o que já foi.

Exportação de arquivo

Quando o servidor antigo não oferece IMAP, ou quando as mensagens estão só no computador, o caminho é exportar para arquivo (PST no Outlook, MBOX em outros programas) e importar no destino. É mais manual e feito caixa por caixa, então serve para exceções, não para a empresa inteira.

As pastas que só existem no computador

Esse é o ponto cego mais comum. Quem usou Outlook por anos com contas POP3, ou criou pastas locais para guardar mensagens antigas, tem histórico que nunca esteve no servidor. Nenhuma cópia servidor para servidor encontra essas mensagens. Pergunte a cada pessoa onde ficam as pastas dela antes da troca, e exporte o que for local.

Prepare a troca do MX com antecedência

O segredo da virada sem perda está numa configuração feita dias antes: baixar o TTL do registro MX. O TTL diz por quanto tempo os outros servidores podem guardar a informação de onde entregar seus e-mails. Muitos domínios estão com 24 horas ou mais.

Dois ou três dias antes da migração, reduza o TTL do MX para 5 minutos (300 segundos). Quando chegar a hora de trocar, o mundo inteiro vai perceber a mudança em minutos, e não em um dia. A janela em que as mensagens ficam divididas entre os dois servidores praticamente desaparece. Depois que tudo estiver estável, o TTL volta ao valor normal.

Escolha também o horário da virada. Sexta à tarde ou véspera de feriado parecem boas ideias porque o movimento é menor, mas qualquer problema fica sem ninguém olhando. Um fim de expediente de terça ou quarta costuma ser o melhor equilíbrio: pouco tráfego, e equipe disponível no dia seguinte.

A virada, passo a passo

Com o inventário pronto, o histórico pré-copiado e o TTL baixo, a troca em si é curta. A ordem importa:

1. Crie todas as caixas, aliases e grupos no provedor novo, conferindo a planilha item por item.
2. Faça a cópia inicial do histórico, se ainda não foi feita.
3. Configure SPF e DKIM do novo provedor no DNS, mantendo o antigo também no SPF durante a transição.
4. Troque o registro MX para o novo provedor e remova os registros MX antigos.
5. Teste a entrega mandando e-mail de fora (de um Gmail pessoal, por exemplo) para algumas caixas e para os aliases.
6. Configure os programas e celulares da equipe com a nova conta.
7. Rode a cópia incremental no dia seguinte, para trazer o que ainda caiu no servidor antigo.
8. Repita a cópia incremental alguns dias depois, antes de desligar o serviço antigo.

Repare que o serviço antigo continua ligado depois da troca. Ele é a rede de segurança dos primeiros dias, e só é cancelado quando o servidor antigo parar de receber mensagens.

SPF, DKIM e DMARC no dia da troca

Muita migração que deu certo na entrega dá errado no envio: as caixas recebem normalmente, mas as respostas começam a cair no spam dos clientes. O motivo quase sempre é a autenticação.

• SPF lista quais servidores podem enviar e-mail em nome do seu domínio. O novo provedor precisa entrar nessa lista no dia da troca.
• DKIM é uma assinatura digital que cada provedor gera. A chave do novo provedor precisa ser publicada no DNS e ativada no painel dele.
• DMARC diz aos destinatários o que fazer com e-mail que falha nos dois testes acima. Se ele já existe com política rígida, um SPF errado faz suas mensagens serem rejeitadas.

Durante a transição, mantenha o servidor antigo e o novo no SPF ao mesmo tempo. Depois que nada mais sair pelo antigo, retire-o. Detalhamos esses três registros em e-mail da empresa caindo em spam.

O que para de funcionar em silêncio

Depois que as caixas estão funcionando, a tendência é dar a migração por encerrada. É nesse ponto que aparecem os problemas que ninguém percebe por dias, porque não geram erro na tela de ninguém.

Formulários do site

O formulário de contato muitas vezes envia usando usuário e senha de uma caixa no servidor antigo. Quando a caixa é desativada, o formulário continua aparecendo no site, o cliente preenche, vê a mensagem de sucesso, e o contato não chega a lugar nenhum. Teste cada formulário depois da troca, como mostramos em formulário do site que não chega.

Sistemas e notas fiscais

ERP, emissor de nota fiscal, sistema de boletos e loja virtual costumam ter configuração própria de envio. Faça uma lista de todo software que manda e-mail em nome da empresa e atualize as configurações de cada um.

Impressoras, scanners e celulares

Scanner que envia digitalização por e-mail e celular com a conta antiga configurada também dependem do servidor antigo. Os celulares são os que mais enganam: continuam mostrando a caixa antiga, sem mensagens novas, e a pessoa acha que o dia está calmo.

Cadastros externos

Bancos, fornecedores, portais do governo e marketplaces não precisam mudar nada se o endereço continua o mesmo. Mas se a migração também mudou algum endereço, como unificar dois domínios em um, cada cadastro externo precisa ser atualizado.

Quando cancelar o serviço antigo

A pressa em cancelar o provedor antigo para parar de pagar dois serviços é compreensível, mas é o último ponto de risco. Uma regra simples funciona bem:

• Mantenha o serviço antigo ativo por pelo menos 15 dias depois da troca do MX.
• Confira o servidor antigo nesse período. Se ainda chegar mensagem, algum servidor externo está com a informação antiga ou algum sistema ainda envia por ele.
• Rode a última cópia incremental logo antes de cancelar.
• Guarde uma exportação completa das caixas em arquivo, como cópia de segurança fora dos dois provedores.

Só depois disso o contrato antigo pode ser encerrado. Os 15 dias de sobreposição custam pouco perto de uma proposta comercial que chegou no servidor desligado.

Perguntas frequentes

Resumindo

Migrar o e-mail corporativo sem perder mensagens é questão de ordem, não de sorte: garantir o acesso ao domínio e ao DNS, inventariar tudo o que existe, copiar o histórico antes, baixar o TTL, trocar o MX num horário com gente por perto e manter o servidor antigo como rede de segurança por alguns dias. O que dá errado quase sempre é o que ninguém listou: o alias esquecido, o formulário do site, a pasta local de alguém.

E vale a lembrança que torna tudo isso possível: só migra com tranquilidade quem tem o domínio no próprio nome. A NSWeb faz a migração de e-mail corporativo completa, do inventário à última cópia, inclusive para quem ainda não decidiu o destino. Fale com a gente e planeje a troca sem risco.