Tiago Carvalho

Email e colaboraçãoGuia

Como migrar o email de uma PME para o Microsoft 365: guia passo a passo

Do inventário à checklist do dia da mudança: a sequência que evita perder correio — e o plano de reversão que raramente chega a ser usado.

Tiago Carvalho14 min de leitura
Passos
15 passos
Tempo de execução
A preparação faz-se ao ritmo da empresa; a mudança em si concentra-se num dia
Nível
Intermédio

Antes de começar

  • Tenant Microsoft 365 criado e domínio validado (ver o guia de implementação)
  • Acesso de administrador ao sistema de email atual
  • Acesso à gestão de DNS do domínio
  • Tempo para fazer o inventário do passo 1 a sério — é ele que evita as surpresas

No fim deste guia

O correio da empresa a funcionar no Microsoft 365: histórico migrado, aliases e caixas partilhadas no sítio, domínio autenticado e um plano de reversão que ficou por usar.

A migração de email é o momento mais delicado da adoção do Microsoft 365: mexe numa coisa que toda a gente usa todos os dias e que ninguém aceita perder. A boa notícia é que uma migração bem preparada é um não-acontecimento — o correio muda de casa durante a noite e, na manhã seguinte, as pessoas trabalham como se nada fosse.

Este guia percorre o processo do inventário à checklist do dia da mudança, para uma PME que venha do Gmail, de um alojamento com cPanel, de um servidor IMAP ou de um Exchange antigo. A regra de ouro atravessa todos os passos: quase tudo pode ser preparado com antecedência. A alteração do MX é o ponto de corte operacional — é reversível, mas a reversão não é instantânea nem elimina a necessidade de reconciliar o correio que circulou entretanto.

Se ainda não tem o tenant criado e o domínio validado, comece pelo guia de implementação do Microsoft 365, que cobre essa fundação em detalhe; este guia concentra-se na mudança do correio em si.

Como usar este guia. Marque cada passo como concluído à medida que avança — o progresso fica guardado no seu navegador. Os passos 1 a 8 fazem-se com calma, dias antes; os passos 9 a 13 pertencem ao dia da mudança e aos dias seguintes. Os valores concretos (nomes de servidores, registos DNS) são sempre os que os assistentes do seu tenant apresentarem.

Em resumo: inventarie tudo o que recebe e envia email, escolha o método de migração conforme a origem e o que precisa de levar (só correio, ou também calendários e contactos), prepare tenant, utilizadores, aliases, caixas partilhadas e o plano de reversão antes de mexer no fluxo de correio — e só então mude os registos MX, complete a autenticação do domínio, configure os clientes e valide. Com o plano de reversão preparado antes do corte, até o pior cenário tem um caminho definido.

  1. Passo 1: Fazer o inventário das caixas de correio

    As migrações correm mal por causa do que ninguém se lembrou de listar. Antes de qualquer decisão técnica, escreva o inventário completo:

    • Caixas de correio individuais, com o tamanho aproximado de cada uma e quem as usa
    • Aliases e endereços alternativos (o geral@, o faturas@ que na verdade cai na caixa da contabilidade)
    • Caixas usadas por mais do que uma pessoa — candidatas a caixas partilhadas
    • Listas de distribuição e grupos
    • Tudo o que envia email pelo domínio sem ser pessoa: software de faturação, CRM, loja online, impressoras, formulários do site
    • Contas esquecidas: antigos colaboradores, caixas de teste, endereços usados em registos de serviços

    Este inventário decide quase tudo o que se segue: o método de migração, as licenças a comprar e a lista de verificações do dia da mudança.

  2. Passo 2: Escolher o método de migração

    O método depende de duas perguntas: de onde vem o correio, e o que precisa de levar consigo. As opções nativas do Microsoft 365 mais relevantes para uma PME:

    MétodoOrigem típicaO que migraNotas
    Migração do Google WorkspaceGmail empresarialCorreio, calendário e contactosAssistente próprio no centro de administração do Exchange; exige configuração no lado Google
    Migração IMAPcPanel, alojamentos web, servidores IMAP genéricosApenas correio — calendários, contactos e tarefas ficam de foraAs caixas têm de existir primeiro no Microsoft 365; há limites de tamanho por mensagem e de número de itens
    Migração cutoverExchange Server local antigoCorreio, calendário e contactosTudo de uma vez; suportada até 2 000 caixas, mas a Microsoft recomenda-a na prática para 150 ou menos
    Importação de PSTFicheiros locais do OutlookO que estiver nos PSTÚtil como complemento, para histórico antigo
    Ferramentas de terceirosQualquer origemDepende da ferramentaA considerar quando as opções nativas não cobrem o cenário (por exemplo, IMAP com calendários noutro sistema)
    A limitação mais subestimada é a do IMAP: só leva o correio. Se a equipa vive de calendários partilhados no sistema atual, isso tem de ser tratado à parte — exportação manual, ferramenta de terceiros, ou aceitação consciente de que se recomeça do zero.
  3. Passo 3: Preparar o tenant

    Com o método escolhido, confirme que a fundação está pronta. Nada disto mexe no correio atual — é tudo preparação sem risco:

    • Tenant criado, com a conta inicial protegida e contas de emergência preparadas
    • Domínio adicionado e verificado no Microsoft 365 (o registo TXT de verificação não interfere com o correio existente)
    • Registos MX ainda a apontar para o sistema atual — a mudança fica para o passo 9
    • Licenças decididas com base no inventário: quem precisa de caixa própria, o que passa a caixa partilhada

    Os detalhes de cada um destes pontos estão no guia de implementação, nos passos do tenant e do domínio.

  4. Passo 4: Preparar os utilizadores de acordo com o método de migração

    A forma de preparar os utilizadores depende do método escolhido no passo 2. Não crie e licencie indiscriminadamente todas as caixas antes de confirmar a sequência aplicável — numa migração cutover, por exemplo, destinatários criados antecipadamente entram em conflito com os que o serviço de migração cria.

    MétodoPreparação do destino
    IMAPCriar os utilizadores, atribuir licenças com Exchange Online e confirmar que as caixas existem antes da migração
    Google WorkspaceAprovisionar os utilizadores conforme o fluxo do assistente (normalmente como mail users); o serviço de migração converte-os em caixas
    Cutover de ExchangeNão criar previamente destinatários com os mesmos endereços — a migração cria os utilizadores e as caixas. Depois de verificar o resultado, atribuir as licenças antes de alterar o MX; o período de tolerância de 30 dias antes de uma caixa sem licença ser desativada é uma salvaguarda, não uma janela normal de planeamento
    Importação de PSTCriar primeiro a caixa de destino e atribuir a licença necessária
    Ferramenta de terceirosSeguir os requisitos da ferramenta e validar com uma conta piloto
    • Em qualquer método, os endereços principais ficam exatamente iguais aos atuais — joao@empresa.pt continua a ser joao@empresa.pt, para que nada do que está lá fora deixe de chegar
    • Assim que a conta de destino existir e estiver pronta para utilização, peça ao utilizador que registe o MFA antes do dia da mudança — evita juntar dois sustos no mesmo dia
  5. Passo 5: Confirmar endereços e mapear aliases, grupos e caixas partilhadas

    Antes de migrar conteúdo, confirme o endereço principal, todos os aliases, o nome de início de sessão e o respetivo utilizador de destino, cruzando com as variantes que o inventário revelou. Uma caixa migrada para o endereço errado é trabalho a dobrar.

    Aproveite para decidir o destino de cada item do inventário que não é uma pessoa: qual passa a alias, qual passa a caixa partilhada, qual passa a grupo. Escreva essa correspondência — é o mapa do passo 7.

  6. Passo 6: Migrar mensagens, calendários e contactos

    A migração de conteúdo pode e deve começar antes de mudar os MX. Os lotes de migração copiam o histórico enquanto o correio continua a entrar no sistema antigo; no dia da mudança, só falta sincronizar o que chegou entretanto.

    • Criar o lote de migração no centro de administração do Exchange, conforme o método escolhido no passo 2
    • Começar por um lote piloto com duas ou três caixas — incluindo uma grande e uma complicada — e verificar o resultado antes de avançar para as restantes
    • Acompanhar os relatórios do lote: caixas concluídas, itens ignorados, erros
    • Contar com tempo real de cópia: caixas grandes demoram, e a velocidade depende sobretudo do sistema de origem
    Atenção: não apague nada na origem. Até ao fim da validação (passo 13), o sistema antigo é a sua rede de segurança — e parte do plano de reversão.
  7. Passo 7: Configurar aliases e caixas partilhadas

    Com o mapa do passo 5, recrie no Microsoft 365 tudo o que não é uma caixa individual:

    • Aliases adicionados aos utilizadores respetivos (cada pessoa pode ter vários endereços; um é o principal)
    • Caixas partilhadas criadas, com as permissões de acesso e de envio («enviar como») atribuídas — uma caixa partilhada pode armazenar até 50 GB sem licença própria; quem lhe acede precisa de uma caixa Exchange Online licenciada, e a conta associada à caixa partilhada não deve ser usada para início de sessão direto
    • Listas de distribuição ou grupos do Microsoft 365 para os endereços coletivos
    • Reencaminhamentos internos apenas onde forem mesmo necessários; o encaminhamento automático externo deve estar bloqueado por predefinição e apenas ser permitido através de exceções justificadas, aprovadas e monitorizadas
  8. Passo 8: Preparar o plano de reversão

    Antes de tocar no MX, escreva o plano de reversão. O seu conteúdo é curto: os registos DNS antigos completos (MX, SPF e restantes, copiados antes de qualquer alteração), o tempo de propagação esperado, quem decide reverter e até que hora — e o que fazer com o correio que circular entretanto.

    Reverter o MX volta a encaminhar o correio novo para o sistema anterior, mas não desfaz automaticamente tudo o que aconteceu depois do corte: as mensagens que já chegaram ao Microsoft 365 permanecem lá, os perfis de Outlook já alterados continuam alterados, e as caches DNS podem manter temporariamente o correio dividido entre os dois destinos — as alterações de MX podem demorar até 72 horas a ser reconhecidas por todos os sistemas externos. O plano deve por isso incluir a reposição dos registos necessários (MX, autodiscover, SPF), a comunicação aos utilizadores, a reversão dos clientes prioritários e um procedimento para reconciliar as mensagens recebidas ou enviadas durante a janela de mudança.

    Um plano de reversão que nunca é usado não foi trabalho perdido — foi o que permitiu fazer a mudança com calma. O cenário sem plano é que é caro.

  9. Passo 9: Alterar os registos MX

    Este é o momento da mudança: quando os registos MX passam a apontar para o Microsoft 365, o correio novo começa a entrar nas caixas novas. Tudo o que veio antes deste passo existiu para que este seja curto e sem surpresas.

    • Escolher uma altura de pouco movimento — fim do dia ou fim de semana, conforme o negócio
    • Reduzir o TTL do registo MX para 3600 segundos ou menos, com antecedência suficiente para que o valor anterior expire — se o TTL atual for de 24 horas, faça a alteração pelo menos 24 horas antes do corte
    • Substituir o MX pelo valor que o assistente do seu tenant indica (é único do seu domínio), e atualizar também o CNAME autodiscover
    • Depois do corte, manter o lote ativo e confirmar pelo menos uma sincronização posterior à alteração do MX; quando o método permitir iniciar manualmente uma sincronização, executá-la — e não eliminar o lote antes de cumprir os critérios do passo 13
    Durante a janela de propagação é normal parte do correio ainda entrar no sistema antigo. É por isso que ele fica ligado e intocado — e que o lote final de sincronização existe.
  10. Passo 10: Autenticar o domínio: SPF, DKIM e DMARC

    A autenticação prepara-se antes e completa-se no dia do corte. Os dois registos CNAME do DKIM e um DMARC inicial em modo de observação podem — e devem — ser publicados antecipadamente: reduz tarefas e riscos durante a janela mais sensível. O SPF é o que se coordena com a mudança das origens de envio:

    • Antes do corte: publicar os CNAME necessários para o DKIM e preparar o registo DMARC em modo de observação
    • No dia do corte: confirmar a ativação do DKIM no portal do Defender e atualizar o SPF para refletir todas as origens que ainda enviam correio — sem esquecer os emissores externos do inventário (faturação, CRM, site)
    • Enquanto os dois sistemas enviarem em simultâneo, o SPF deve autorizar temporariamente ambos — sempre num único registo SPF; o sistema antigo sai do registo quando deixar de enviar

    A explicação completa dos três mecanismos, do alinhamento e da ordem de endurecimento está no artigo SPF, DKIM e DMARC: como proteger o email da sua empresa.

  11. Passo 11: Configurar o Outlook e os dispositivos móveis

    Nos computadores, o Outlook deteta a nova caixa automaticamente na maioria dos casos — com o autodiscover no sítio, basta criar o perfil novo, iniciar sessão com a conta Microsoft 365 e concluir a autenticação multifator. Conte com um caso ou outro em que é preciso remover o perfil antigo à mão.

    • Preparar uma instrução simples, com imagens, para quem configura sozinho — computador e telemóvel
    • Nos telemóveis, preferir a aplicação Outlook à aplicação de email nativa: melhor suporte de MFA e de políticas de proteção
    • Remover as configurações antigas (IMAP/POP do sistema anterior) para ninguém continuar a responder pela conta errada
    • Verificar as assinaturas de email — é o dia certo para as uniformizar
  12. Passo 12: Testar envio e receção

    Não se declara vitória sem testar nos dois sentidos e com o exterior:

    • Receber: enviar de um endereço externo (Gmail pessoal, por exemplo) para caixas individuais, aliases e caixas partilhadas
    • Enviar: das caixas novas para o exterior, confirmando que a mensagem não cai em spam e que os cabeçalhos mostram SPF, DKIM e DMARC a passar
    • Responder a uma mensagem antiga migrada, para confirmar que o histórico está utilizável
    • Testar o «enviar como» das caixas partilhadas e os emissores automáticos (faturação, formulários do site)
  13. Passo 13: Validar depois da migração

    Nos dias seguintes, antes de dar o processo por encerrado:

    • Manter os lotes de migração ativos durante o período indicado para o método: nas migrações IMAP e cutover, a Microsoft recomenda esperar pelo menos 72 horas depois da alteração do MX, confirmar que já não entra correio na origem e que ocorreu pelo menos uma sincronização posterior à mudança — só depois concluir ou eliminar os lotes (no IMAP, a sincronização incremental ocorre aproximadamente uma vez por dia)
    • Rever os relatórios finais dos lotes: caixas completas, itens ignorados e porquê
    • Confirmar com os utilizadores os casos sensíveis: histórico, pastas, calendários e contactos onde aplicável
    • Verificar o fluxo de correio no centro de administração do Exchange (rastreio de mensagens) para queixas concretas
    • Manter o sistema antigo acessível em modo só de consulta durante um período definido — e só depois desligar e cancelar
  14. Passo 14: Resolver os problemas mais frequentes

    Os clássicos das primeiras semanas, e por onde começar em cada um:

    • «Há emails que ainda vão parar ao sistema antigo» — propagação do MX ainda a decorrer, ou um registo MX secundário esquecido; confirme no DNS público o que está efetivamente publicado
    • «As nossas mensagens caem em spam» — SPF desatualizado ou DKIM por ativar; verifique os cabeçalhos de uma mensagem de teste
    • «Falta correio antigo» — veja os itens ignorados no relatório do lote (mensagens acima do limite de tamanho são a causa comum); o complemento é a importação de PST
    • «O software de faturação deixou de enviar» — emissor esquecido no inventário; decida entre SMTP AUTH (com prazo, como explica o guia de segurança) e alternativas modernas
    • «O Outlook pede palavra-passe sem parar» — perfil antigo a interferir; remover o perfil e criar de novo resolve a maioria dos casos
  15. Passo 15: Checklist para o dia da mudança

    Para imprimir ou ter aberta ao lado, a sequência condensada do próprio dia:

    • Migração de conteúdo concluída ou em fase final; lote piloto validado
    • Registos DNS antigos copiados e plano de reversão à mão
    • Alterar MX e autodiscover; confirmar a publicação no DNS público
    • Atualizar SPF; ativar DKIM; rever DMARC
    • Confirmar que a sincronização incremental continua ativa; não eliminar os lotes enquanto a propagação e a validação não estiverem concluídas
    • Testes de envio e receção nos dois sentidos, incluindo aliases, caixas partilhadas e emissores automáticos
    • Configurar os clientes prioritários (gerência, faturação, apoio ao cliente) e acompanhar os restantes
    • Deixar o sistema antigo intocado — a rede de segurança fica armada até à validação final
    Passo seguinte natural: com o correio a viver no Microsoft 365, siga o guia de segurança dos primeiros 30 dias — as primeiras 24 horas dele são exatamente o que um ambiente acabado de migrar precisa.

    Fontes e validação

    Este guia baseia-se na documentação oficial da Microsoft, em particular:

    Última validação técnica: 28 de julho de 2026. Os métodos de migração disponíveis, os limites por método e os assistentes dos centros de administração mudam com o tempo. Confirme o estado atual na documentação oficial antes de planear a sua migração.
Partilhar:LinkedInEmail

Tiago Carvalho

Especialista em Microsoft 365, gestão de dispositivos, segurança, identidade e ambientes cloud.

Sobre o autor →

Tecnologia útil, diretamente no seu email.

Receba novos guias e artigos sobre Microsoft 365, segurança e produtividade. Sem spam e sem linguagem comercial agressiva.

Artigos relacionados