Migração de e-mail: 7 falhas perigosas

A migração de e-mail parece uma simples cópia até as mensagens começarem a chegar em dois lugares, os usuários responderem a conversas antigas e receberem retornos e alguém descobrir que a caixa do diretor é 85GB maior que o plano contratado. Se o seu foco são as ferramentas, comece por este guia operacional do imapsync. Este artigo é o runbook para os problemas ao redor: DNS, mapeamento de pastas, limitações, cotas e casos extremos que transformam uma migração rotineira em uma indisponibilidade durante todo o fim de semana.

O problema é simples: as pessoas tratam e-mail como arquivos. O agravante é pior: as caixas continuam mudando durante o transporte, caches de DNS mostram uma realidade antiga e servidores IMAP discordam sobre o comportamento das pastas. A solução não exige heroísmo. Exige preparação, verificação e recusa a atalhos que parecem inofensivos às 6 PM e catastróficos às 9 AM de segunda-feira.

Por que a migração de e-mail falha em produção

A migração falha quando os operadores a tratam como um único evento, e não como uma sequência controlada: inventário, pré-carga, virada, sincronização do delta e validação. O e-mail é um dado vivo. O DNS é armazenado em cache. Os clientes se comportam de formas diferentes. Se você pular uma dessas camadas, não terá uma mudança limpa, mas entrega parcial, duplicados ou perda silenciosa de dados.

1. A divergência de DNS causa a primeira indisponibilidade

A primeira falha geralmente não está na cópia, mas no roteamento. Alguns remetentes adotam o novo MX em minutos. Outros mantêm o antigo no cache por horas. Durante essa janela, o e-mail pode chegar aos dois sistemas. Se o host antigo já foi desligado, há retornos. Se continua ativo, mensagens ficam isoladas.

A Microsoft recomenda reduzir o TTL do MX antes da virada IMAP para que os registros atualizados se propaguem mais rápido. É um conselho entediante, mas salva migrações. Se o TTL atual é 86,400 segundos e você altera o MX na noite da mudança, já perdeu o controle do cronograma.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

Se estiver migrando para a TrekMail, obtenha os registros exatos em Adicionar um domínio à TrekMail e confirme que o domínio ficou ativo antes de anunciar a mudança. A TrekMail também verifica o DNS em tempo real, ajudando a encontrar o erro clássico de deixar registros MX antigos.

Virada ruim: alterar o MX às 10 PM, desligar o host antigo às 10:05 PM e descobrir na segunda-feira que o gateway de um fornecedor manteve o registro antigo em cache durante todo o fim de semana.

Outra armadilha é o SPF. Se a entrada aponta para o sistema novo, mas a autenticação de saída ainda está errada, as respostas começam a cair no spam. As regras do Google para remetentes não são mais opcionais. Use um único registro SPF, alinhe o DKIM e publique o DMARC.

2. A limitação acaba com a fantasia de migrar em um fim de semana

A segunda falha é física. O gargalo geralmente não é sua largura de banda local, mas o provedor de origem decidindo que você já copiou o suficiente por enquanto. Google, Microsoft e outros sistemas hospedados limitam tráfego IMAP agressivo. Quando isso ocorre, as estimativas de progresso viram ficção e o trabalho fica muito lento ou para por completo.

Por isso, migrar tudo de uma vez é um plano ruim para qualquer equipe que não seja minúscula. Uma caixa de 10GB em um ambiente que na prática permite apenas uma fração por dia não terminará só porque você deseja. Limites de frequência não respeitam sua janela de manutenção.

A solução é uma migração em etapas:

1. Pré-carregue primeiro as mensagens antigas, geralmente tudo com mais de 60 a 90 dias.
2. Deixe a ferramenta repetir e aguardar durante a semana.
3. Só altere o MX depois que o volume histórico já estiver no destino.
4. Execute um delta das mensagens recentes durante a virada.

A importação IMAP no servidor da TrekMail foi criada para esse fluxo. O guia Iniciar uma migração no painel confirma que a ferramenta traz mensagens de um servidor IMAP externo para uma caixa TrekMail escolhida e aceita a opção Ignorar duplicados. Repetir passagens é normal em uma migração segura, não um sinal de problema.

Jeito antigo e jeito novo: provedores antigos cobram por usuário e ainda vendem uma ferramenta separada de migração. No jeito novo, você prepara a mudança com migração IMAP integrada, paga um plano fixo a partir de $3.50 por mês e deixa de transformar cada caixa em uma nova licença.

3. O UIDVALIDITY pode criar três cópias da mesma caixa

Essa falha se esconde atrás de uma barra de progresso aparentemente bem-sucedida. Mensagens IMAP têm identificadores únicos, mas eles só são confiáveis dentro das regras da caixa a que pertencem. Quando o servidor altera o estado da pasta o bastante para redefinir o UIDVALIDITY, uma ferramenta ingênua pode confundir mensagens antigas com novas e copiá-las outra vez.

IMAP4rev1 (RFC 3501) define UIDVALIDITY por um motivo. Se ele mudar, os UIDs antigos deixam de ser confiáveis. É o comportamento normal do protocolo, mas péssimo para uma ferramenta que depende apenas de UIDs.

Motivos frequentes:

• Um usuário renomeia ou recria uma pasta durante a mudança.
• O servidor de origem refaz os índices.
• Um administrador executa manutenção que muda o estado da caixa.

A defesa prática é simples. Suspenda a organização das caixas durante a migração. Oriente os usuários a não renomear pastas, mover milhares de mensagens para o arquivo nem limpar os itens enviados enquanto a sincronização está ativa. Use um destino capaz de ignorar duplicados em novas passagens em vez de confiar cegamente nos UIDs.

Na validação manual, compare as contagens das pastas antes e depois. Não pare na caixa de entrada. Verifique enviados, lixeira, pastas personalizadas de projetos e estruturas compartilhadas de arquivo. É ali que tempestades de duplicados se escondem.

4. O mapeamento de pastas torna a migração estranha rapidamente

O mapeamento interrompe migrações porque servidores IMAP discordam sobre separadores de hierarquia, nomes de pastas do sistema e o modelo de marcadores do Gmail. Para o usuário, aparecem pastas ausentes ou mensagens duplicadas. Tecnicamente, o e-mail muitas vezes está presente, mas mal organizado, o bastante para gerar pânico e chamados.

Há duas versões comuns. Primeiro, separadores diferentes: um servidor usa pontos nos nomes, outro usa barras. Segundo, os marcadores do Gmail: uma mensagem pode aparecer sob vários marcadores, que o IMAP apresenta como pastas.

Assim uma caixa Gmail bem organizada vira um destino inchado, com mensagens repetidas em enviados, pastas personalizadas e arquivos. A própria documentação da Microsoft destaca e-mails duplicados quando existem marcadores do Gmail e a pasta [Gmail] não é excluída.

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

Ao migrar do Gmail, ignore [Gmail]/All Mail, a menos que exista uma exceção muito específica. Caso contrário, você está pedindo duplicação. Depois da mudança, a TrekMail simplifica a configuração com valores IMAP padronizados em Configurações IMAP e SMTP para todos os clientes.

5. A caixa gigante destrói orçamentos e cronogramas

Os planos de migração costumam falhar por usar médias. Ambientes reais falham por causa das exceções. Uma caixa que acumula mensagens desde 2011 pode ser maior que dez usuários comuns juntos. Se você orçar o trabalho, escolher o plano de destino e definir o prazo sem medir todas as caixas, uma única exceção destruirá o projeto.

Essa é a armadilha de reduzir a licença. Sistemas de origem, principalmente instalações locais antigas, muitas vezes toleravam caixas gigantes. Muitas plataformas hospedadas não toleram. Quando a cota de destino é menor que o tamanho real, a migração não falha de forma educada. Em geral, falha tarde, após desperdiçar horas de transferência.

Faça primeiro um inventário. Sem exceções. Depois decida se o modelo de destino aceita tamanhos desiguais sem exigir upgrades individuais caros.

É por isso que armazenamento compartilhado funciona melhor que armazenamento por usuário. Na TrekMail, o espaço é dividido pela conta, em vez de forçar cada caixa à mesma capacidade pequena. Isso importa para fundadores, caixas jurídicas e entradas compartilhadas de agências. Para equipes com muitos domínios, a hospedagem de e-mail para vários domínios só funciona se o modelo não penalizar exceções.

Para acompanhar o uso depois da mudança, a TrekMail documenta limites e cotas em Cotas de armazenamento das caixas.

6. Mensagens corrompidas são normais e exigem regras operacionais

Uma migração limpa não significa que todos os itens são válidos. Armazenamentos antigos acumulam MIME quebrado, anexos vazios e convites de calendário malformados. Se o processo parar em cada item ruim, uma mensagem estragada de 2014 poderá travar uma migração que estaria correta.

É aqui que se confunde precisão com competência. Você precisa de um histórico de auditoria, mas não de todo o lote parado porque um anexo morto não pode ser interpretado.

Defina um limite de itens ruins. Registre cada item ignorado. Analise o relatório e prossiga. A maioria é lixo, duplicados de sistemas anteriores ou convites antigos malformados que ninguém precisa. Se o CSV de itens ignorados contiver algo importante, extraia a mensagem manualmente. Ainda será mais rápido que manter toda a migração refém.

O fluxo integrado da TrekMail exibe progresso e falhas no painel. Se as mensagens não chegam ao lugar esperado após a virada, a verificação mais rápida é Não estou recebendo e-mails, que orienta a conferir MX e caixas.

7. LegacyExchangeDN é a armadilha exclusiva do Exchange que sobrevive à migração

Essa falha é específica, desagradável e comum. Usuários respondem a uma conversa interna antiga no Outlook e recebem um retorno IMCEAEX ou de destinatário inexistente, embora a caixa exista e mensagens novas funcionem. O motivo não é SMTP, mas a identidade antiga do Exchange incorporada em mensagens históricas e endereços armazenados.

O Exchange guarda endereçamento antigo no estilo X.500 no atributo LegacyExchangeDN. Ao migrar entre ambientes Exchange, ou sair mal de um deles, respostas a mensagens antigas ainda podem usar essa identidade. Se o destino não tiver o valor antigo como endereço proxy X500, a resposta falhará.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

Isso não afeta todas as migrações porque transferências IMAP simples não carregam objetos nativos do Exchange como migrações completas. Mas, se os usuários do Outlook precisam continuar respondendo a conversas internas antigas sem erros, confira antes da aprovação. É um problema que só aparece depois que o projeto foi declarado concluído.

Um plano de virada mais seguro

Uma migração segura é deliberadamente escalonada, medida e entediante. Esse é o objetivo. Você quer menos surpresas, não mais automação só por automatizar. As melhores viradas parecem comuns porque o trabalho arriscado ocorreu antes da troca do MX.

1. Inventariar o tamanho de todas as caixas e marcar as muito grandes.
2. Reduzir o TTL do MX entre 24 a 48 horas antes da virada.
3. Criar primeiro os domínios e as caixas de destino.
4. Executar a sincronização IMAP histórica antes do fim de semana.
5. Suspender limpeza de pastas e movimentos em massa durante o delta final.
6. Alterar o MX apenas quando o destino estiver pronto para receber.
7. Executar uma sincronização final do delta.
8. Testar entrada, saída, contagens de pastas e respostas a conversas antigas.

Se estiver montando o destino do zero, criar e-mail com seu domínio explica a sequência, e criar contas de e-mail em massa ajuda ao preparar mais que alguns usuários.

Na TrekMail, o caminho é direto: adicionar o domínio, verificar o DNS, criar caixas, executar a migração IMAP integrada em um plano pago e alterar o tráfego ao vivo depois da cópia pesada. Os preços começam em $3.50 por mês. Os planos pagos incluem avaliação gratuita de 14 dias com cartão obrigatório. O Nano é separado: sem cartão, sem avaliação e sempre gratuito.

Conclusão: migrar e-mail é operação, não cópia

A migração funciona quando você respeita as partes difíceis: DNS em cache, origens limitadas, comportamento inconsistente do IMAP, cotas divergentes e resíduos do Exchange. Ignore isso e o projeto parecerá bom até os usuários começarem a perder mensagens. Trate a migração como infraestrutura ativa e ela ficará previsível. Esse é o objetivo.

Se quiser um modelo de preço fixo depois da mudança, a TrekMail oferece vários domínios, armazenamento compartilhado, migração IMAP integrada, encaminhamento, acesso à API e configuração baseada em padrões, sem cobrança por usuário. Comece em trekmail.net ou compare os planos em Preços da TrekMail.