Uma migração sem interrupção significa que cada mensagem enviada ao seu domínio chega a uma caixa de correio, e que cada funcionário pode escrever aos seus correspondentes no dia da virada. Ela não significa que o histórico, os celulares e os hábitos mudam sem nenhuma ação.
Duas plataformas funcionam em paralelo.
A lacuna clássica vem de um MX virado enquanto uma cópia está incompleta, ou de uma copiadora, um site ou um CRM que ainda envia com o identificador antigo.
O MX é um registro DNS: ele indica aos servidores remetentes onde entregar as mensagens do seu domínio. Trocar de serviço de e-mail é, antes de tudo, trocar esse endereço de entrega. O resto (contas, histórico, dispositivos) é preparado em torno disso.
O protocolo SMTP tolera bem os incidentes curtos. Um servidor remetente que recebe um erro temporário mantém a mensagem na fila e tenta novamente mais tarde. Um servidor momentaneamente inacessível, portanto, não faz perder mensagens. Por outro lado, um erro definitivo (caixa desconhecida, mensagem recusada) devolve a mensagem ao remetente, e essa mensagem nunca chegará por conta própria. O principal risco de uma virada não é a pane, é a nova plataforma recusar um destinatário porque um alias ou uma lista não foi recriado.
O TTL (tempo de vida) define por quanto tempo um resolvedor DNS pode manter uma resposta em memória. Durante esse prazo, parte dos remetentes ainda entrega na plataforma antiga. Isso é normal, e é por isso que a antiga deve continuar capaz de receber durante a transição.
Duas semanas antes. Inventário das caixas, aliases, listas, caixas compartilhadas e de todas as aplicações que enviam e-mail. Redução do TTL DNS do MX para um valor curto (muitas vezes 300 segundos), para que o dia D se propague rapidamente. Criação das contas de destino. Primeira cópia do histórico.
O TTL é reduzido cedo porque um resolvedor que leu o valor antigo o mantém até a sua expiração: o TTL curto só entra em vigor depois que o cache antigo expirar. A primeira cópia, por sua vez, é a mais longa; iniciá-la cedo dá tempo para descobrir as caixas que apresentam problemas.
Alguns dias antes. Verificação de uma amostra: número de mensagens, pastas ou marcadores, compromissos, contatos. Correção do método se a amostra falhar. Preparação dos guias para celulares e Outlook. Teste de envio a partir do destino para o Gmail e o Outlook.com, com SPF, DKIM e DMARC já válidos na nova plataforma. Esses registros podem ser publicados antes do MX.
Concretamente: um único registro SPF que autoriza as duas plataformas durante a transição (dois registros SPF distintos fazem a verificação falhar), uma chave DKIM da nova plataforma publicada sob o seu próprio seletor, ao lado da antiga, e uma política DMARC revisada. O DMARC exige que a mensagem seja autenticada por SPF ou por DKIM em nome do domínio do remetente; se a sua política for estrita e o destino ainda não estiver autorizado, os seus correspondentes rejeitam as suas mensagens.
Na véspera. Segunda passagem: copiar apenas o que chegou desde a primeira cópia. Congelar as alterações de aliases e de listas.
No dia D. Virada do MX. Verificação externa imediata: um e-mail enviado de uma caixa pessoal externa deve chegar à nova plataforma dentro do prazo do TTL. Monitoramento da fila. Reconfiguração das aplicações de envio. Suporte interno identificado, com o direito de reverter o MX se um fluxo crítico falhar.
Altere ao mesmo tempo o registro autodiscover, se existir: é ele que o Outlook consulta para encontrar o seu servidor. Remova também os MX secundários que ainda apontariam para a plataforma antiga: um remetente que não consegue alcançar o MX principal tenta os seguintes.
Nos dias seguintes. A plataforma antiga em modo de leitura. Levantamento das divergências (uma pasta faltando, uma caixa compartilhada). Terceira passagem direcionada, se necessário. Em seguida, encerramento do envio na antiga, para que um funcionário não responda mais a partir de dois lugares.
Este último ponto tem uma razão técnica. A plataforma antiga continua se considerando responsável pelo seu domínio: uma mensagem enviada a partir dela para um colega é entregue localmente, sem consultar o MX. O colega nunca a verá em sua nova caixa.
| Risco | O que acontece | Prevenção |
|---|---|---|
| MX virado cedo demais | As novas mensagens chegam, o histórico falta | Virar após a verificação da amostra e a segunda passagem |
| Alias ou lista esquecidos | O destino recusa definitivamente essas mensagens | Inventário, congelamento dos aliases na véspera, teste dos endereços coletivos |
| SPF, DKIM ou DMARC incompletos | Suas mensagens são rejeitadas ou classificadas como spam pelos correspondentes | Publicar antes do dia D, verificar em uma mensagem real |
| Aplicação que envia com a conta antiga | Faturas, alertas ou digitalizações deixam de ser enviados | Lista das aplicações, novo servidor SMTP configurado no dia D |
| Envio que permaneceu aberto na plataforma antiga | Mensagens internas ficam no sistema antigo | Encerrar o envio assim que a amostra for validada |
| Reversão não preparada | O MX volta atrás, mas as mensagens recebidas nesse meio-tempo ficam no destino | Plano escrito, incluindo a recuperação dessas mensagens |
Tomemos, a título de ilustração, um escritório de 40 pessoas. Ele opta por fazer a virada em uma quinta-feira no fim do dia, em vez de uma sexta-feira: no dia seguinte, a equipe está presente para tratar as divergências, e o suporte interno tem um dia útil pela frente. A copiadora da recepção, que digitaliza para o e-mail, é reconfigurada na mesma noite. Se duas caixas compartilhadas relatarem uma pasta faltando, uma passagem direcionada as completa. Nesse cenário, nenhuma mensagem é perdida, mas vários funcionários precisam reconfigurar sua conta no telefone: essa é a parte visível que deve ser anunciada.
Eles trocam de servidor no Outlook ou no celular. O primeiro carregamento de uma caixa grande leva tempo. As mensagens já em cache no telefone podem ficar duplicadas se o perfil não for refeito corretamente. Preveja o procedimento “excluir a conta e recriá-la” em vez de um improviso de configuração de servidor.
O motivo é o mesmo para o Outlook: o perfil guarda um cache local ligado ao servidor antigo. Um novo perfil parte de um estado limpo; um perfil antigo modificado mistura os dois mundos. No celular, o protocolo utilizado (Exchange ActiveSync ou IMAP, conforme o destino) às vezes muda com a plataforma, o que é mais um motivo para recriar a conta.
As regras do lado do servidor, as assinaturas centralizadas e as permissões de delegação precisam ser reconfiguradas. Anuncie isso. Não é uma interrupção das mensagens. É trabalho de administração.
Esse encaminhamento exige uma configuração explícita: a plataforma antiga, que ainda acredita hospedar as caixas, deve ser configurada para retransmitir para a nova em vez de entregar localmente. Na falta disso, uma passagem de recuperação direcionada faz o mesmo trabalho.
As particularidades de cada ponto de partida são descritas em migrar do Microsoft 365 e migrar do Google Workspace.
Pelo tempo necessário para verificar que nenhum fluxo ainda utiliza a antiga e que as divergências levantadas foram tratadas. Isso depende do número de caixas, das aplicações que enviam e do ritmo de reconfiguração das estações. Encerrar cedo demais impede as correções; encerrar tarde demais deixa funcionários trabalhando em dois sistemas.
Não, se for preparada. Durante o TTL, parte dos remetentes ainda entrega na plataforma antiga, e a outra parte na nova. As duas recebem, e a passagem seguinte reúne as duas. As mensagens só se perdem se forem recusadas, daí a importância dos aliases e das listas.
Em geral, não: os endereços não mudam. Avise, por outro lado, os parceiros que filtram estritamente as suas mensagens ou que lhe atribuíram uma regra específica, e aqueles que trocam com você mensagens criptografadas, se as chaves mudarem.
Sim, restaurando o MX antigo, desde que a plataforma antiga ainda esteja ativa. As mensagens recebidas pela nova nesse meio-tempo devem então ser copiadas de volta ou permanecer acessíveis. O plano de reversão diz quem decide, em quanto tempo e como essas mensagens são recuperadas.
Pergunte ao operador o que ele garante: a chegada das mensagens, a recuperação do histórico ou ambos. São compromissos diferentes. Peça também o plano de reversão, por escrito, com a pessoa que tem o direito de acioná-lo.
Uma garantia sobre a chegada das mensagens diz respeito ao dia D e aos dias seguintes. Uma garantia sobre o histórico diz respeito à cópia e à sua verificação. Um prestador pode cumprir uma sem a outra; o orçamento deve dizer qual delas ele assume e como ela é verificada.
Na Klytic, as orientações e sugestões para preparar a migração do e-mail são gratuitas, e nenhum e-mail é perdido. A migração realizada pela Klytic é feita sob orçamento. As assinaturas estão na página Preços e são faturadas à parte. O detalhamento dos itens de custo está em quanto custa uma migração do Microsoft 365, e a lista de verificação, na checklist. Para comparar os destinos, veja escolher um e-mail europeu.
Esta página descreve um método. O andamento real depende dos seus fluxos, dos seus volumes e da plataforma que você está deixando.
Consultadas em outubro de 2026.
Orientação gratuita, nenhum e-mail perdido. A migração realizada pela Klytic é orçada após um inventário.
Oferta de boas-vindas
Oferta de teste sem compromisso. Um consultor entra em contato para entender suas necessidades e preparar seu espaço Klytic.
