Uma migração sem interrupção significa que cada mensagem enviada para o seu domínio chega a uma caixa de correio, e que cada colaborador pode escrever aos seus correspondentes no dia da mudança. Não significa que o histórico, os telemóveis e os hábitos mudam sem qualquer intervenção.
Duas plataformas coexistem em paralelo.
A falha clássica resulta de um MX mudado enquanto uma cópia está incompleta, ou de uma fotocopiadora, de um site ou de um CRM que ainda envia com o identificador antigo.
O MX é um registo DNS: indica aos servidores remetentes onde entregar o correio do seu domínio. Mudar de serviço de email é, antes de mais, mudar este endereço de entrega. O resto (contas, histórico, dispositivos) prepara-se à volta disso.
O protocolo SMTP tolera bem os incidentes curtos. Um servidor remetente que recebe um erro temporário mantém a mensagem em fila de espera e volta a tentar mais tarde. Um servidor momentaneamente inacessível não faz, portanto, perder correio. Pelo contrário, um erro definitivo (caixa desconhecida, mensagem recusada) devolve a mensagem ao seu remetente, e essa mensagem nunca chegará por si só. O principal risco de uma mudança não é a avaria, é a nova plataforma recusar um destinatário porque um alias ou uma lista não foi recriado.
O TTL (tempo de vida) fixa durante quanto tempo um resolvedor DNS pode manter uma resposta em memória. Durante esse prazo, uma parte dos remetentes continua a entregar na plataforma antiga. É 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 partilhadas e de todas as aplicações que enviam email. Redução do TTL DNS do MX para um valor curto (muitas vezes 300 segundos), para que o dia D se propague depressa. Criação das contas de destino. Primeira cópia do histórico.
O TTL reduz-se cedo porque um resolvedor que leu o valor antigo mantém-no até expirar: o TTL curto só produz efeito depois de esgotada a cache antiga. A primeira cópia, por sua vez, é a mais longa; lançá-la cedo dá tempo para descobrir as caixas que levantam problemas.
Alguns dias antes. Controlo de uma amostra: número de mensagens, pastas ou etiquetas, compromissos, contactos. Correção do método se a amostra falhar. Preparação das instruções para telemóveis e Outlook. Teste de envio a partir do destino para Gmail e Outlook.com, com SPF, DKIM e DMARC já válidos na nova plataforma. Estes registos podem ser publicados antes do MX.
Concretamente: um único registo SPF que autorize as duas plataformas durante a transição (dois registos SPF distintos fazem falhar a verificação), uma chave DKIM da nova plataforma publicada sob o seu próprio seletor, ao lado da antiga, e uma política DMARC revista. 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 rigorosa 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 listas.
No dia D. Mudança do MX. Verificação externa imediata: um email enviado a partir de uma caixa pessoal externa deve chegar à nova plataforma dentro do prazo do TTL. Monitorização da fila de espera. Reconfiguração das aplicações de envio. Linha de apoio interna identificada, com o direito de repor o MX anterior se um fluxo crítico falhar.
Altere ao mesmo tempo o registo autodiscover, se existir: é ele que o Outlook consulta para encontrar o seu servidor. Retire também os MX secundários que ainda apontem para a plataforma antiga: um remetente que não consegue contactar o MX principal tenta os seguintes.
Nos dias seguintes. A plataforma antiga em modo de leitura. Recolha das discrepâncias (uma pasta em falta, uma caixa partilhada). Terceira passagem direcionada, se necessário. Depois, encerramento do envio na antiga, para que nenhum colaborador continue a responder a partir de dois sítios.
Este último ponto tem uma razão técnica. A plataforma antiga continua a considerar-se responsável pelo seu domínio: uma mensagem enviada a partir dela para um colega é aí entregue localmente, sem consultar o MX. O colega nunca a verá na sua nova caixa.
| Risco | O que acontece | Prevenção |
|---|---|---|
| MX mudado demasiado cedo | O correio novo chega, falta o histórico | Mudar após o controlo 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 | As suas mensagens são rejeitadas ou classificadas como indesejadas nos correspondentes | Publicar antes do dia D, verificar numa 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 deixado aberto na plataforma antiga | Mensagens internas ficam no sistema antigo | Encerrar o envio assim que a amostra estiver validada |
| Reversão não preparada | O MX é reposto, mas as mensagens recebidas entretanto ficam no destino | Plano escrito, com a recuperação dessas mensagens |
Tomemos, a título ilustrativo, um escritório de 40 pessoas. Opta por mudar numa quinta-feira ao fim do dia em vez de numa sexta-feira: no dia seguinte, a equipa está presente para tratar as discrepâncias, e a linha de apoio interna tem um dia útil pela frente. A fotocopiadora da receção, que digitaliza para email, é reconfigurada na mesma noite. Se duas caixas partilhadas comunicarem uma pasta em falta, uma passagem direcionada completa-as. Neste cenário, nenhuma mensagem se perde, mas vários colaboradores têm de reconfigurar a conta no telemóvel: é a parte visível que convém anunciar.
Mudam de servidor no Outlook ou no telemóvel. O primeiro carregamento de uma caixa grande demora. As mensagens já em cache no telemóvel podem ficar duplicadas se o perfil não for refeito corretamente. Preveja o procedimento «eliminar a conta e voltar a criá-la» em vez de um remendo na configuração do servidor.
A razão é a mesma para o Outlook: o perfil mantém uma cache local ligada ao servidor antigo. Um perfil novo parte de um estado limpo; um perfil antigo modificado mistura os dois mundos. No telemóvel, o protocolo utilizado (Exchange ActiveSync ou IMAP, consoante o destino) muda por vezes com a plataforma, o que é mais uma razão para recriar a conta.
As regras do lado do servidor, as assinaturas centralizadas e os direitos de delegação voltam a ser configurados. Anuncie-o. Não é uma interrupção do correio. É trabalho de administração.
Esse reencaminhamento exige uma configuração explícita: a plataforma antiga, que ainda julga alojar 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 estão descritas em migrar a partir do Microsoft 365 e migrar a partir do Google Workspace.
O tempo necessário para verificar que nenhum fluxo ainda utiliza a antiga e que as discrepâncias comunicadas estão tratadas. Depende do número de caixas, das aplicações que enviam e do ritmo de reconfiguração dos postos de trabalho. Encerrar demasiado cedo impede a correção; encerrar demasiado tarde deixa colaboradores a trabalhar em dois sistemas.
Não, se for preparada. Durante o TTL, uma parte dos remetentes continua a entregar na plataforma antiga e a outra na nova. As duas recebem, e a passagem seguinte junta as duas. O correio só se perde se for recusado, daí a importância dos aliases e das listas.
Em geral, não: os endereços não mudam. Avise, contudo, os parceiros que filtram as suas mensagens de forma rigorosa ou que lhe atribuíram uma regra específica, e aqueles que trocam consigo correio cifrado, se as chaves mudarem.
Sim, repondo o MX antigo, desde que a plataforma antiga ainda esteja ativa. As mensagens recebidas entretanto pela nova devem então ser copiadas de volta ou continuar acessíveis. O plano de reversão define quem decide, em quanto tempo e como essas mensagens são recuperadas.
Pergunte ao operador o que garante: a chegada das mensagens, a recuperação do histórico, ou ambas. São compromissos diferentes. Peça também o plano de reversão, por escrito, com a pessoa que tem o direito de o ativar.
Uma garantia sobre a chegada das mensagens incide sobre o dia D e os dias seguintes. Uma garantia sobre o histórico incide sobre a cópia e o seu controlo. Um prestador pode cumprir uma sem a outra; o orçamento deve indicar qual assume e como se verifica.
Na Klytic, os conselhos e sugestões para preparar a migração do email são gratuitos, e nenhum email se perde. A migração realizada pela Klytic é feita mediante orçamento. As subscrições estão na página Preços e são faturadas à parte. O detalhe das rubricas de custo está em quanto custa uma migração do Microsoft 365, e a lista de controlo na checklist. Para comparar os destinos, consulte escolher um email europeu.
Esta página descreve um método. O desenrolar real depende dos seus fluxos, dos seus volumes e da plataforma que está a deixar.
Consultadas em outubro de 2026.
Aconselhamento gratuito, nenhum email perdido. A migração realizada pela Klytic é orçamentada após um inventário.
Oferta de boas-vindas
Oferta de teste sem compromisso. Um consultor liga-lhe para compreender as suas necessidades e preparar o seu espaço Klytic.
