Como migrar email com IMAPSync entre servidores sem perder mensagens

Aprenda a migrar email com IMAPSync entre servidores IMAP preservando pastas, flags e datas. Procedimento testado em produção.

Migrar caixas postais entre servidores IMAP é um dos procedimentos mais delicados em administração de email. Mensagens são heterogêneas (tamanhos variando de 2 KB a 50 MB+), as flags importam (lida/não-lida, marcada, respondida), e qualquer interrupção no MX deixa mensagens em trânsito flutuando entre os dois lados. IMAPSync resolve isso com sincronização incremental — você pode rodar várias vezes sem duplicar mensagem e fazer o cutover real em janela curta.

Este tutorial é pra sysadmins que precisam mover uma ou várias contas IMAP entre provedores sem perder mensagens. Cobre o ciclo completo: instalação, dry-run, sincronização em duas fases, troca de DNS, e validação final. Persona típica: alguém migrando de cPanel/Plesk/Zimbra pra outro provedor, ou consolidando contas de um Microsoft 365 antigo pra infraestrutura própria em VPS.

Tempo estimado: 30-45 minutos pra setup e primeira sincronização de uma conta de 5-10 GB. Contas maiores levam horas e podem ser deixadas rodando em background. O cutover final (a segunda execução incremental) tipicamente leva 2-5 minutos por conta.

Pré-requisitos

Você precisa de uma máquina Linux com acesso à internet — pode ser a VPS de destino, uma VPS auxiliar, ou seu próprio desktop. Recomendo rodar IMAPSync em uma VPS no mesmo datacenter do servidor de destino: latência baixa faz diferença real em contas grandes.

Pré-requisitos técnicos

Ubuntu 22.04/24.04 LTS ou Debian 12 com acesso sudo, Perl 5.30+ instalado (default no sistema), 2 GB livres em disco pra cache temporário do IMAPSync, e portas 993 (IMAPS) liberadas pra outbound. Credenciais IMAP de origem e destino — com senha de aplicativo se 2FA estiver ativo.

Porta IMAPS 993
Porta IMAP STARTTLS 143
Cache local ~/.imapsync/
Log por conta LOG_imapsync/

Instalação do IMAPSync

A versão dos repositórios Debian/Ubuntu é antiga (geralmente 1.7xx). Recomendo compilar a partir do source — versão 2.x tem fixes importantes pra Microsoft 365 e Gmail e melhor handling de erros transitórios.

01

Instale as dependências Perl e ferramentas de build:

sudo apt update
sudo apt install -y \
  git make cpanminus libio-socket-ssl-perl libnet-ssleay-perl \
  libcrypt-ssleay-perl libmail-imapclient-perl libdigest-md5-file-perl \
  libdist-checkconflicts-perl libfile-copy-recursive-perl \
  libio-tee-perl libjson-webtoken-perl libreadonly-perl \
  libregexp-common-perl libsys-meminfo-perl libterm-readkey-perl \
  libtest-fatal-perl libtest-mockobject-perl libtest-pod-perl \
  libtest-requires-perl libtest-deep-perl libunicode-string-perl \
  liburi-perl libencode-imaputf7-perl libfile-tail-perl \
  libdata-uniqid-perl libproc-processtable-perl libtime-hires-perl

A lista parece longa mas cada módulo cobre um caso real — SSL, encoding UTF-7 IMAP, parsing de IDs únicos, tail de logs ao vivo. Pular qualquer um vai resultar em erro críptico no meio da migração.

02

Clone e instale o IMAPSync:

git clone https://github.com/imapsync/imapsync.git
cd imapsync
sudo make install
imapsync --version

O comando final deve retornar algo como Imapsync 2.255 ou superior. Se aparecer “Can’t locate … in @INC”, falta algum módulo Perl — identifique o nome pelo erro e instale via sudo cpanm Nome::Modulo.

Dry-run pra validar credenciais e mapeamento de pastas

Antes de copiar qualquer mensagem, rode em modo dry-run. Isso lista as pastas dos dois lados, valida login, e mostra quantas mensagens existem sem transferir nada.

03

Crie um arquivo migracao.sh com as variáveis da conta:

#!/bin/bash
imapsync \
  --host1 mail.origem.com.br \
  --port1 993 \
  --ssl1 \
  --user1 [email protected] \
  --password1 'SENHA_ORIGEM' \
  --host2 mail.destino.com.br \
  --port2 993 \
  --ssl2 \
  --user2 [email protected] \
  --password2 'SENHA_DESTINO' \
  --dry \
  --justfolders

A combinação --dry --justfolders lista as pastas dos dois lados sem tocar em mensagens. É a forma mais rápida de detectar mismatch (ex: origem tem “INBOX.Sent” e destino espera “Sent Items”).

04

Rode e analise o output:

chmod +x migracao.sh
./migracao.sh 2>&1 | tee dry-run.log

Procure no log por linhas começando com Host1 folders: e Host2 folders:. Se houver discrepância (ex: origem usa hierarquia com ponto “INBOX.Trabalho” e destino usa barra “INBOX/Trabalho”), você vai precisar de --regextrans2 's,INBOX\.,INBOX/,g' na execução real.

Microsoft 365 e Gmail exigem app password

Se a origem ou destino é Microsoft 365, Gmail ou iCloud com 2FA ativo, a senha normal NÃO funciona via IMAP. Gere uma “senha de aplicativo” no painel do provedor antes de rodar. Pra Gmail, ative IMAP em Configurações → Encaminhamento e POP/IMAP primeiro.

Primeira sincronização (pré-cutover)

A primeira execução é a pesada — ela copia tudo. Pode levar horas pra contas grandes. Rode em screen ou tmux pra não perder o progresso se a sessão SSH cair.

05

Inicie uma sessão tmux pra rodar em background:

tmux new -s migracao

Se a conexão SSH cair, você reconecta e roda tmux attach -t migracao pra continuar acompanhando.

06

Rode a sincronização completa removendo o --dry --justfolders:

imapsync \
  --host1 mail.origem.com.br --port1 993 --ssl1 \
  --user1 [email protected] --password1 'SENHA_ORIGEM' \
  --host2 mail.destino.com.br --port2 993 --ssl2 \
  --user2 [email protected] --password2 'SENHA_DESTINO' \
  --automap \
  --syncinternaldates \
  --useuid \
  --addheader \
  --logfile LOG_imapsync/usuario.log

O --automap mapeia automaticamente Sent/Sent Items/INBOX.Sent entre provedores diferentes. --syncinternaldates preserva a data original. --useuid torna a sincronização idempotente — rodar de novo não duplica nada. --addheader adiciona X-Imapsync nas mensagens pra você auditar depois quais foram migradas.

Pular pastas que não importam

Pra contas com Trash ou Junk gigantes, adicione --exclude '^Trash$' --exclude '^Junk$' --exclude '^Spam$'. Economiza horas e gigabytes em contas antigas. Sent e Drafts geralmente VALE migrar.

Troca de DNS e cutover

Com a primeira sincronização completa, é hora de virar o MX. As mensagens novas vão chegar no servidor de destino e o antigo recebe zero tráfego novo. A segunda execução do IMAPSync vai pegar só as mensagens que chegaram no antigo entre o início da primeira sync e o momento em que o DNS propagou — tipicamente 30-120 minutos de mensagens.

07

Reduza o TTL do registro MX no provedor de DNS pra 300 segundos (5 min) ANTES de fazer qualquer mudança — idealmente 24h antes. Isso garante que a propagação seja rápida quando você trocar o destino. Se o TTL estava em 3600 ou 86400, todo mundo vai continuar vendo o valor antigo até esse tempo terminar.

# Verifique TTL atual antes de mudar
dig +short mx dominio.com.br
dig +nocmd +noall +answer mx dominio.com.br
08

Troque o MX pro novo servidor. No painel DNS:

  • Tipo: MX
  • Prioridade: 10 (ou a que você usa)
  • Valor: mail.destino.com.br. (com ponto final)
  • TTL: 300

Aguarde 5-10 minutos e confirme propagação:

dig +short mx dominio.com.br @1.1.1.1
dig +short mx dominio.com.br @8.8.8.8

Ambos devem retornar o novo MX. Se um retornar o antigo, o cache do resolver ainda não expirou — espere mais alguns minutos.

09

Rode IMAPSync uma segunda vez — comando idêntico ao Step 06. Por causa do --useuid, ele só vai copiar mensagens que chegaram na origem entre a primeira e a segunda execução. Tipicamente é rápido (2-10 minutos).

./migracao.sh 2>&1 | tee LOG_imapsync/cutover.log

No final do log, procure por Total bytes transferred. Em uma sync incremental bem-sucedida, esse valor é pequeno (alguns MB no máximo).

Verificação

A validação básica é contar mensagens dos dois lados. Se baterem, a migração está íntegra.

10

Compare as contagens da origem e destino:

imapsync \
  --host1 mail.origem.com.br --port1 993 --ssl1 \
  --user1 [email protected] --password1 'SENHA_ORIGEM' \
  --host2 mail.destino.com.br --port2 993 --ssl2 \
  --user2 [email protected] --password2 'SENHA_DESTINO' \
  --justconnect

E depois rode com --dry pra ver o relatório final de mensagens contadas em cada pasta dos dois lados:

./migracao.sh --dry

No final, procure por Folder Host1/Host2 messages — cada par deve bater. Diferença ≤ 5 mensagens em pasta de 10k+ é normal (mensagens que chegaram entre o último sync e a verificação).

Resolução de problemas

Erro “Too many connections” durante migração paralela

Quando você roda IMAPSync pra várias contas em paralelo, alguns provedores limitam conexões por IP. Reduza concorrência pra 2-3 processos simultâneos e adicione --maxbytespersecond 5000000 (5 MB/s) pra dar respiro ao servidor.

Mensagens duplicadas após segunda execução

Isso indica que --useuid não está funcionando — geralmente porque o destino reescreve UIDs ao copiar mensagens. Solução: use --useheader Message-Id em vez de --useuid. Mais lento, mas deduplica por header em vez de UID nativo.

Pasta “Sent” do Gmail aparece duplicada

Gmail tem peculiaridade: cada mensagem aparece em “[Gmail]/All Mail” E em “INBOX” ou “Sent”. Adicione --exclude '^\[Gmail\]/All Mail$' ou você vai migrar tudo em dobro.

Não delete a conta de origem ainda

Mantenha a caixa de origem ativa por pelo menos 7-14 dias pós-cutover. Mensagens podem aparecer atrasadas (servidores que cacheram o MX antigo por mais tempo, sistemas de retry de outros provedores). Rodar IMAPSync periodicamente nesses dias garante captura.

Próximos passos

Com a migração concluída, considere automatizar verificações pra detectar problemas pós-cutover:

  • Configure SPF, DKIM e DMARC no novo MX antes de tirar o antigo do ar
  • Monitore taxa de bounce nas primeiras 48h pra pegar reputação de IP ruim no novo servidor
  • Documente a senha de aplicativo gerada e revogue após 30 dias
  • Se for migrar dezenas de contas, monte um script com GNU parallel pra rodar em lote
  • Configure backup automático da nova caixa (rsnapshot, restic ou similar) pra ter ponto de recuperação independente do provedor

Se você está consolidando email em infraestrutura própria pra ter controle do MX e dos backups, uma VPS Hostini com IP dedicado e portas SMTP/IMAP liberadas é o ponto de partida — sem bloqueio de porta 25 pra outbound e com reverse DNS configurável pelo painel.

Perguntas frequentes

IMAPSync preserva as datas originais das mensagens?

Sim. O IMAPSync replica o INTERNALDATE de cada mensagem por padrão, então a data de recebimento no servidor de destino bate com a do servidor de origem. Se o destino rejeitar o INTERNALDATE (alguns provedores fazem isso), use a flag --syncinternaldates 0 e aceite que a data passará a ser o momento da migração.

Posso rodar IMAPSync em paralelo pra várias contas?

Pode, mas com cautela. Cada processo abre 2 conexões IMAP simultâneas (uma em cada lado), e muitos provedores limitam conexões por IP. Comece com 3-4 processos paralelos e monitore erros 'Too many connections' no log. GNU parallel é a forma mais simples de orquestrar em lote.

O que acontece com mensagens novas que chegam durante a migração?

Enquanto o MX ainda aponta pro servidor antigo, mensagens chegam lá. Você roda IMAPSync uma primeira vez (sync completa), troca o MX pro servidor novo, e roda uma segunda vez incremental. A segunda execução só copia o delta — mensagens que chegaram entre as duas execuções. Por isso o cutover sempre tem 2 rodadas.

Como lidar com diferenças de tamanho máximo de pasta entre provedores?

Alguns provedores limitam Trash, Junk ou Sent a poucos GB. Use --exclude '^Trash$' --exclude '^Junk$' pra pular pastas que não importam, ou --maxsize 25000000 pra ignorar mensagens maiores que 25 MB. A flag --justfolders na primeira execução lista todas as pastas pra você decidir o que migrar.

Preciso desativar autenticação de 2 fatores na conta de origem?

Depende do provedor. Gmail, Outlook 365 e iCloud exigem senha de aplicativo (app password) quando 2FA está ativo — IMAP simples não passa pelo 2FA interativo. Gere a app password no painel do provedor, use ela no --password1, e revogue após a migração. Provedores com IMAP padrão (cPanel, Plesk, Zimbra) aceitam a senha normal.

IMAPSync funciona com Microsoft 365 e Gmail?

Sim. Pra Microsoft 365, use --host2 outlook.office365.com --port2 993 --ssl2 --authmech2 LOGIN. Pra Gmail, ative IMAP nas configurações da conta, gere senha de aplicativo, e use --host2 imap.gmail.com --port2 993 --ssl2. Ambos têm limites de throughput — espere ~50 GB por dia por conta.

Tópicos:
Próximos passos Cloud Ryzen com NVMe e proteção DDoS sempre ativa.Coloque em produção numa VPS Hostini →
Esse tutorial foi útil?
Falar no WhatsApp