Migrar o e-mail para um novo fornecedor sem interrupções
Quando é preciso migrar o e-mail para a infraestrutura de um novo fornecedor, isso não tem de significar uma interrupção de 24 horas durante a qual as mensagens são rejeitadas ou desaparecem. O temido «buraco negro» acontece quando os administradores ignoram o tempo de propagação do DNS e tentam fazer tudo de uma só vez. Com uma execução em paralelo, o sistema antigo continua ativo enquanto o novo é sincronizado em segundo plano e o tráfego só é mudado depois de os dois serem reconciliados.
Este guia explica o plano de transição utilizado por administradores que migram o e-mail para novos ambientes com o mínimo de interrupções. Para conhecer toda a teoria da migração, consulte o nosso guia de migração por IMAP.
Porque falha o método «Big Bang»
A abordagem «Big Bang», copiar tudo na sexta-feira à noite, mudar o DNS e esperar que resulte, falha porque as velocidades de transferência não são constantes. A limitação de tráfego (erros HTTP 429) e os limites de largura de banda podem parar uma migração a meio. Chega a manhã de segunda-feira, metade das caixas de correio estão vazias e a equipa de suporte fica sobrecarregada.
A prática profissional ao migrar o e-mail para um novo fornecedor consiste em manter os dois ambientes em paralelo. Prepara-se o novo ambiente, sincronizam-se os dados históricos em segundo plano e o DNS só é atualizado depois de o destino ser reconciliado com a origem. Para saber como preservar a reputação do remetente de e-mail durante a mudança, leia esse guia antes de começar.
As 4 etapas da migração de e-mail
| Etapa | Momento | Ação | Objetivo |
|---|---|---|---|
| Preparação | T-7 dias | Sincronizar por IMAP os e-mails com mais de 30 dias | Migrar 90% do armazenamento sem pressionar a largura de banda |
| Redução do TTL | T-48 horas | Reduzir o TTL de MX/SPF para 300 segundos | Diminuir a cache de DNS para uma janela de transição prevista de 5 minutos |
| Transição | Momento zero (sexta-feira à tarde) | Atualizar os registos MX para o novo fornecedor | Encaminhar os novos e-mails recebidos para o novo servidor |
| Sincronização delta | T+1 hora | Sincronizar os itens recentes (últimos 30 dias) | Recolher o e-mail entregue no servidor antigo durante a transição |
Fase 1: propagação do DNS e a regra dos 300 segundos
O encaminhamento dividido, no qual alguns remetentes chegam ao servidor antigo e outros ao novo, é causado por valores de TTL longos nos registos DNS. Os resolvedores recursivos guardam os registos MX em cache de acordo com o TTL. Um TTL comum é 86,400 segundos (24 horas). Se mudar os registos MX sem o reduzir primeiro, alguns remetentes podem continuar a encaminhar mensagens para o servidor antigo enquanto as respetivas caches forem válidas. Quem pretende migrar o e-mail para um novo fornecedor deve preparar primeiro o TTL.
O procedimento é simples: verifique o TTL atual, reduza os TTL de MX e SPF para 300 segundos e espere pelo menos o período do TTL original antes de avançar. Esse valor é apenas um limite indicativo para caches que respeitam o TTL, não uma garantia de propagação global. Se ignorar a espera, alguns resolvedores ainda terão os registos anteriores em cache.
A armadilha das 10 consultas de SPF
Durante a migração, poderá querer adicionar o include de SPF do novo fornecedor ao do antigo. Tenha cuidado. A RFC 7208 limita o SPF a 10 consultas DNS. Acumular vários fornecedores (Google + Outlook + novo fornecedor) ultrapassa frequentemente esse limite, causando PermError e problemas de entrega. Achate o registo SPF apenas se mantiver os endereços IP resultantes atualizados de forma fiável, ou remova temporariamente ferramentas de marketing não essenciais durante a transição. Para configurar corretamente o SPF, consulte o nosso guia de SPF.
Fase 2: sincronização de dados por IMAP
Quando migra o e-mail para um novo fornecedor, a migração utiliza o protocolo IMAP (RFC 3501). Não se trata de uma simples cópia de ficheiros, mas de uma sincronização de estados. Ferramentas como o imapsync tratam do trabalho pesado, mas é importante compreender o protocolo.
O problema da «caixa fantasma» do Gmail
Se migrar «All Mail» do Gmail tratando as etiquetas como pastas, pode criar várias cópias visíveis nas pastas IMAP: uma única mensagem com 3 etiquetas pode ser copiada 3 vezes para 3 pastas diferentes. A documentação de migração de dados da Google descreve este comportamento das etiquetas. A solução é configurar a ferramenta de migração para mapear as etiquetas de forma inteligente ou excluir totalmente a pasta [Gmail]/All Mail.
Limitação de tráfego e códigos de erro
Ao migrar o e-mail para um novo fornecedor, é normal que o servidor de origem imponha limites. A Google devolve falhas de ligação 11001/11002 quando o acesso IMAP está desativado ou bloqueado por uma firewall. Os erros HTTP 429 indicam que está a enviar demasiados dados; muitos fornecedores interrompem as ligações acima de 2 GB/hour/user. Utilize uma ferramenta de migração com espera exponencial que detete a limitação e pause automaticamente.
Fase 3: impacto nas aplicações de e-mail
Depois de migrar o e-mail para os servidores do novo fornecedor, o lado do servidor costuma ser a parte simples; o nosso guia sobre transferência de uma caixa de correio explica em detalhe a transição do DNS. É nas aplicações que pode surgir a avalanche de pedidos ao suporte.
Certificado não correspondente: se o Outlook continuar aberto durante a mudança do DNS, liga-se a mail.yourdomain.com, que agora aponta para o novo fornecedor, utilizando as credenciais antigas. Podem surgir avisos de certificado SSL/TLS. Recomende que a aplicação seja reiniciada na manhã de segunda-feira.
OAuth em dispositivos móveis: as aplicações móveis modernas utilizam tokens OAuth associados a um tenant específico. Em algumas aplicações, é suficiente voltar a autorizar ou reconfigurar a conta; noutras, o utilizador terá de eliminar a conta antiga e adicionar uma nova ligação IMAP.
Ciclos de encaminhamento interno: após a mudança de MX, o servidor antigo pode continuar a considerar-se responsável pelo domínio. Se o utilizador A (no antigo) escrever ao utilizador B (também no antigo), o servidor entrega a mensagem localmente e o utilizador B, que já consulta o novo, não a vê. Reconfigure em segurança a entrega local do fornecedor antigo para encaminhar o correio tardio para o novo enquanto as caches de DNS expiram; não a desative sem confirmar primeiro o percurso alternativo.
A reversão: uma rede de segurança de 15 minutos
Como reduziu o TTL para 300 segundos na fase 1, a reversão pode ser mais rápida nos resolvedores que respeitam o TTL. Se a tentativa de migrar o e-mail para o novo fornecedor falhar, por exemplo devido a um bloqueio da firewall, problemas de licenciamento ou ausência total de fluxo de e-mail durante 30+ minutos, reponha os registos MX do fornecedor antigo. O tráfego regressará gradualmente à medida que as caches expirarem, mas não há garantia de que isso aconteça em 5 minutos.
Como o TrekMail simplifica a migração
Migrar manualmente o e-mail para um novo fornecedor implica gerir scripts do imapsync, interpretar erros enigmáticos como 0x800CCC0E e acompanhar a propagação do DNS. O TrekMail inclui um mecanismo de migração IMAP que automatiza o mapeamento de pastas, a espera em caso de limitação e as sincronizações delta para os dados IMAP suportados; no fim, continua a ser necessária uma reconciliação com a origem.
| Plano | Preço | Mais indicado para |
|---|---|---|
| Free | $0 | Testes e domínios pessoais (sem cartão) |
| Starter | $3.50/mo | Pequenas empresas e um único domínio |
| Pro | $10/mo | Vários domínios e utilizadores avançados |
| Agency | $23.25/mo | MSP que migram 50+ domínios de clientes com armazenamento partilhado |
Todos os planos pagos incluem uma avaliação de 14 dias (é necessário um cartão). O plano Nano não exige cartão.
O TrekMail centra-se no armazenamento e na entrega de e-mail de alto desempenho, com calendários e contactos por caixa de correio através de CalDAV e CardDAV. Se também precisar de criar e-mail com o seu próprio domínio, o nosso guia de configuração explica todos os passos. A migração propriamente dita transfere apenas o e-mail: exporte os calendários e contactos do fornecedor antigo e importe-os quando as caixas estiverem ativas.
Para agências que migram regularmente o e-mail de dezenas de domínios ao mesmo tempo para um novo fornecedor, o TrekMail oferece armazenamento partilhado (distribua 200 GB por todos os seus domínios), SMTP gerido com reputação de IP já estabelecida e aprovisionamento por modelos para aplicar as definições de DNS e migração a 100 domínios de uma só vez.
Conclusão: migrar o e-mail sem um buraco negro
Migrar corretamente o e-mail para um novo fornecedor exige gerir em simultâneo uma transição de estado no DNS, nos dados e no acesso dos utilizadores. Todos os administradores que precisem de o fazer devem planear esta complexidade. O sucesso passa por reduzir rejeições, perdas de dados e chamadas urgentes através de verificações e reconciliações. Prepare o TTL de 300 segundos, utilize uma arquitetura em paralelo e mantenha pronto um plano de reversão.
Para saber mais sobre como escolher a plataforma de e-mail certa e proteger a reputação do domínio durante a mudança, consulte esses guias.
Deixe de pagar taxas por utilizador por funcionalidades que não usa. Experimente o TrekMail gratuitamente e descubra como é um alojamento de e-mail criado para administradores.
