Lista de migração de e-mail sem perdas

Se você precisa de uma lista de verificação para migração de e-mail, comece por esta regra: e-mail não é um trabalho de arrastar e soltar pastas. É um sistema em produção, com estados de mensagens que mudam, aliases, encaminhadores, limitações, clientes com problemas e usuários que continuam enviando enquanto você trabalha. É por isso que viradas mal planejadas falham. Se ainda está decidindo onde sua caixa ficará depois da mudança, leia primeiro sobre e-mail corporativo para pequenas empresas. Se já sabe que precisa migrar, use este runbook e mantenha a mudança tranquila.

O problema é simples. A maioria das equipes copia as mensagens, altera o MX e torce. Na segunda-feira aparecem os itens ausentes: o arquivo do fundador, o encaminhador de faturas e a caixa compartilhada que, na verdade, era usada por cinco pessoas na mesma conta. Esta lista corrige isso ao reunir descoberta, sincronização prévia, verificação, novas tentativas e reversão em um único documento operacional.

Lista de migração antes de copiar uma única mensagem

Uma lista de migração começa pela visibilidade. Antes de mover um byte, você precisa de um inventário programático de caixas postais, aliases, regras de encaminhamento, tamanhos das caixas e limites na origem. Se a descoberta for fraca, todas as etapas seguintes serão mais lentas, arriscadas e caras.

Não confie em exportações do RH nem naquela planilha que o cliente enviou no mês passado. Extraia os dados da plataforma de origem e monte um inventário que responda a cinco perguntas:

1. Quais caixas existem e quais ainda recebem mensagens?
2. Quais aliases e contas de função apontam para essas caixas?
3. Quais usuários fogem do padrão de armazenamento?
4. Quais regras de encaminhamento da caixa de entrada, do transporte ou da própria caixa estão ativas?
5. Quais contas são endereços operacionais compartilhados, e não caixas pessoais?

O último ponto importa mais do que se admite. invoices@, support@ e hello@ muitas vezes parecem caixas comuns até o dia da virada. Então ninguém sabe quem é o responsável, qual dispositivo ainda está conectado ou para onde foram as respostas.

Faça também uma análise de dados problemáticos. Procure MIME malformado, anexos grandes demais e árvores de pastas absurdas. O IMAP transfere muita coisa, mas não transforma dados de origem corrompidos em dados de destino íntegros. Lembre também do que o IMAP não transfere bem ou não transfere. O fluxo da TrekMail trata apenas de e-mail, então calendários e contatos precisam de outro plano. A visão geral da migração IMAP da TrekMail deixa esse limite claro.

Exemplo: uma caixa tem 14,200 itens na origem, mas duas mensagens estão corrompidas e um anexo de 80 MB ultrapassa a política do destino. Se o runbook disser “o tamanho parece certo”, você não verá o problema. Se exigir a contagem de itens e a análise do registro de falhas, você o encontrará antes dos usuários.

Lista de verificação para planejar a virada

A lista deve definir a arquitetura da migração antes que alguém marque uma virada para o fim de semana. Caixas pequenas podem suportar uma mudança de uma só vez. Empresas reais normalmente não. Pré-carregue as mensagens históricas, deixe as alterações recentes para o delta final e só altere o DNS quando as caixas mais lentas já estiverem quase prontas.

Há três padrões comuns:

Para a maioria, pré-carga e delta são a escolha certa. Um cronograma prático fica assim:

1. T menos 14 dias: migrar primeiro as mensagens antigas e identificar caixas lentas.
2. T menos 7 dias: confirmar aliases, regras de encaminhamento e mapeamento das caixas de destino.
3. T menos 2 dias: reduzir o TTL do DNS, testar a autenticação e revisar registros de falhas.
4. T zero: alterar o MX, atualizar SPF e DKIM, executar o delta e corrigir os clientes.
5. T mais 1 dia: verificar contagens, testar mensagens recebidas e enviadas e desativar o acesso antigo.

Se o DNS for configurado incorretamente, o fluxo de e-mail para. Reduza o TTL com pelo menos 48 horas de antecedência e compare os registros de destino com os registros DNS obrigatórios da TrekMail.

example.com.        300 IN MX  10 mail.trekmail.net.
example.com.        300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

# DKIM value is generated per domain in the TrekMail dashboard.

Nas primeiras 24 a 48 horas após a mudança do MX, uma política DMARC temporária p=none pode reduzir rejeições causadas pela própria configuração enquanto os caches se ajustam. Quando a migração estiver estável, volte a aplicar uma política rigorosa. Isso importa ainda mais para quem envia volume significativo ao Gmail. As diretrizes do Google para remetentes passaram a exigir SPF, DKIM, alinhamento, TLS e DMARC de remetentes em massa.

Lista para pré-carga e sincronização do delta

O meio de uma migração depende da física, não do otimismo. O IMAP copia as mensagens pasta por pasta, e grandes provedores impõem limites de banda e de frequência. Seu trabalho é mover mensagens antigas cedo, controlar as novas tentativas e manter o delta final pequeno o bastante para terminar na janela da virada.

É aqui que muitas migrações desandam. O IMAP depende de identificadores de mensagens e do estado da caixa. O comportamento dos UIDs e do UIDVALIDITY na RFC 3501 explica por que pastas reindexadas ou danificadas podem provocar uma ressincronização problemática. Se a ferramenta permite ignorar duplicados ou comparar conteúdo, use o recurso. O assistente do painel da TrekMail oferece essa opção, e as etapas estão documentadas em Iniciar uma migração no painel.

Para operadores que testam ferramentas de linha de comando antes de tocar em produção, vale manter aberto este guia complementar sobre imapsync.

imapsync \
  --host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
  --host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
  --ssl1 --ssl2 \
  --syncinternaldates \
  --exclude 'Calendar|Contacts' \
  --skipsize

Calcule a largura de banda antes de prometer a conclusão em um fim de semana. O Google publica limites de banda IMAP do Gmail, incluindo o máximo diário de download de 2,500 MB por conta. A Microsoft funciona de outra forma, mas não é mais generosa. Segundo ela, o desempenho varia e é condicionado pela limitação do serviço. Por isso, uma caixa enorme pode destruir o cronograma se for descoberta tarde.

Mantenha o destino realista. A TrekMail usa apenas IMAP e não é uma suíte de escritório completa. Isso é positivo durante a migração, pois mantém o escopo claro: mover a correspondência, verificá-la e depois cuidar de calendários e contatos separadamente, sem misturar domínios de falha.

Lista de verificação após a mudança do DNS

Uma lista sólida trata a verificação como uma fase própria, não como uma olhada rápida no tamanho da caixa. O tamanho engana. A codificação muda, cada plataforma trata anexos de forma diferente e o cálculo de armazenamento no servidor varia. Contagens de itens, amostras, envios de teste e análise de falhas mostram se o e-mail realmente sobreviveu à mudança.

Use uma matriz simples para cada classe de caixa: executivos, contas compartilhadas, usuários comuns e usuários com caixas muito grandes.

A lista também deve incluir uma etapa para acessos obsoletos. Depois do delta, retire dos usuários o acesso à plataforma antiga. Caso contrário, um telefone esquecido ou perfil do Outlook ainda poderá enviar ou receber pela origem, deixando mensagens isoladas.

As configurações de cliente da TrekMail são diretas: host IMAP imap.trekmail.net, porta 993 e endereço completo como nome de usuário. POP3 não é aceito. Os valores exatos estão no guia de configurações IMAP e SMTP. Se o Outlook insistir no servidor antigo, pare de remendar e crie um novo perfil.

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Lista para novas tentativas, registros e reversão

O último terço da lista define o que fazer quando o plano entra em alerta. Regras de repetição, campos de registro, responsáveis pela escalada e um limite para reversão precisam existir antes da primeira caixa. Se forem improvisados sob pressão, as decisões serão ruins.

O registro deve guardar caixa, pasta, data e hora, servidor de origem, servidor de destino, contagem tentada, contagem copiada, bytes copiados, número de tentativas, estado final e erro legível. Em seguida, classifique as falhas rapidamente:

Reverter não significa “devolver tudo porque um usuário reclamou”. Uma lista séria define os gatilhos antes. Bons gatilhos incluem falha ampla de entrada após alterar o MX, grandes lacunas sem explicação nas contagens de caixas essenciais ou falha de autenticação no destino que bloqueia toda a organização. Um celular desatualizado ou um usuário que nunca trocou a senha não são bons gatilhos.

Se a reversão for necessária, mantenha-a restrita. Restaure primeiro o fluxo de e-mail, envie uma única atualização e preserve todos os registros. Não reinicie três ferramentas de uma vez nem crie uma confusão maior que a falha original.

Por que esta lista funciona melhor na TrekMail

A lista fica mais simples quando a plataforma de destino foi criada para e-mail, não para vender pacotes por usuário. O jeito antigo é pagar por pessoa por uma suíte pouco usada e tratar a migração como tarefa secundária. O jeito novo é migrar para uma plataforma centrada em e-mail, com armazenamento previsível, DNS claro e um caminho IMAP adequado.

A TrekMail segue esse modelo. Ela oferece domínios próprios, caixas IMAP, catch-all, encaminhamento, migração no servidor, assistente para SPF, DKIM e DMARC, SMTP próprio ou incluído e API. Os planos pagos começam em $3.50 por mês no Starter, e a ferramenta integrada de migração está disponível neles. Para testar recursos pagos, há uma avaliação gratuita de 14 dias que exige cartão. Para começar sem cartão, o Nano é sempre gratuito.

O ganho operacional está no armazenamento compartilhado e no gerenciamento de vários domínios por preço fixo. Uma caixa enorme não impõe cobrança por usuário à empresa inteira. Isso importa para agências, MSPs e quem opera contas de função em muitos domínios. Se esse é o seu ambiente, leia a seguir a visão da TrekMail sobre hospedagem de e-mail para vários domínios. Para preços e escolha de plano, consulte os preços da TrekMail.

A execução também fica mais limpa. Você adiciona o domínio, cria a caixa de destino, executa a migração IMAP no servidor, valida o DNS e muda os clientes. Sem desvios por POP3 nem conectores proprietários misteriosos. Apenas IMAP e SMTP padronizados, com configurações explícitas.

Conclusão: mantenha a lista de migração tranquila

A melhor lista de migração é aquela de que ninguém se lembra um mês depois. Inventarie a origem, pré-carregue mensagens antigas, altere o DNS de propósito, execute o delta, confira as contagens, encerre acessos obsoletos e restrinja a reversão. Assim, a migração deixa de ser uma aposta e se torna operação rotineira, como deve ser o e-mail em produção.