Datas erradas após migração do Zoho para Microsoft 365

O que aconteceu com sua caixa de e-mail

Você acabou de finalizar a migração do seu domínio do Zoho Mail para o Microsoft 365. A infraestrutura do Exchange Online está no lugar, as caixas foram provisionadas, os registros MX atualizados. E aí, na segunda de manhã, um usuário abre o Outlook e percebe que todos os e-mails de 2021 estão mostrando a data de hoje. Outro nota que mensagens do ano passado aparecem no topo da caixa de entrada, como se tivessem acabado de chegar. Os chamados começam a pipocar.

Não é um bug do Outlook. Também não é um problema específico do Zoho. É o comportamento esperado, mas mal documentado, de qualquer migração IMAP para o Exchange Online. Entender exatamente por que isso acontece é o primeiro passo para corrigir de forma adequada.

A causa técnica: INTERNALDATE e cabeçalhos Received

Um e-mail armazenado em um servidor IMAP é composto de duas coisas distintas: o conteúdo bruto da mensagem (os cabeçalhos RFC 2822, o corpo, os anexos) e os metadados de armazenamento gerenciados pelo servidor IMAP, entre eles o INTERNALDATE. É essa metadado que os clientes de e-mail consultam para exibir e ordenar as mensagens.

O cabeçalho Date: definido na mensagem bruta (RFC 2822) representa a data em que a mensagem foi composta ou enviada pelo remetente. O INTERNALDATE, por sua vez, é a data em que o servidor IMAP recebeu ou armazenou a mensagem. Em condições normais, num servidor saudável, esses dois valores são próximos. Após uma migração, a história é outra.

Como a migração IMAP corrompe as datas

Quando uma ferramenta de migração (o Zoho Migration Wizard, imapsync, BitTitan ou qualquer outra) transfere uma mensagem do Zoho Mail para o Exchange Online, ela faz isso via protocolo IMAP. A ferramenta se conecta ao Zoho, busca a mensagem e a insere no Exchange Online via um comando IMAP APPEND. E é aí que o problema começa.

O Exchange Online, ao receber cada mensagem, gera um novo cabeçalho Received: que adiciona no início da mensagem. Esse cabeçalho carrega a data e hora exatas da inserção, ou seja, a data da migração. Algumas ferramentas tentam preservar o INTERNALDATE original passando-o como parâmetro do comando APPEND. Outras não fazem isso, ou fazem de forma incorreta, e o Exchange Online atribui automaticamente a data de recebimento como INTERNALDATE.

Resultado: seja um e-mail enviado em 2019 ou em 2022, seu INTERNALDATE agora aponta para a semana da migração. O Outlook lê esse valor com prioridade. A ordenação desmorona.

O comportamento específico do Zoho Migration Wizard

O Zoho oferece sua própria ferramenta de migração para quem quer sair da plataforma: o Zoho Migration Wizard. É prático para migrações simples, mas tem um comportamento bem documentado nos fóruns de administradores: ele nem sempre transmite corretamente o INTERNALDATE original ao inserir mensagens no servidor de destino.

Para ser preciso, o problema afeta principalmente as migrações para servidores que adicionam sistematicamente um cabeçalho Received: a cada mensagem recebida, que é exatamente o comportamento do Exchange Online. Mesmo que o Zoho Migration Wizard passe a data original via parâmetro APPEND, o cabeçalho Received: gerado pelo Exchange Online fica na primeira posição na cadeia de cabeçalhos, e o Outlook o usa para determinar "quando o e-mail chegou".

Administradores que usam ferramentas IMAP genéricas como imapsync para sair do Zoho encontram exatamente o mesmo problema, às vezes de forma ainda mais acentuada, porque a configuração padrão do imapsync não é otimizada para o Exchange Online. (Aliás, se você já passou a madrugada lendo um log do imapsync linha por linha atrás de um erro de sincronização, sabe que é uma ferramenta poderosa, mas não exatamente gentil com casos de borda.)

Por que o Outlook mostra a data errada

O Outlook não usa apenas o cabeçalho Date: para exibir a data de um e-mail. Na maioria das visualizações, é o INTERNALDATE fornecido pelo servidor IMAP/Exchange que é utilizado, especialmente para ordenar a caixa de entrada. O cabeçalho Date: original está presente na mensagem, intacto, mas é ignorado em favor do INTERNALDATE.

É por isso que a opção "Classificar por data de envio" no Outlook não resolve o problema de verdade. Exibe uma data diferente, sim, mas o comportamento de ordenação permanece instável conforme a versão do Outlook e o modo de visualização (conversas agrupadas ou não). Ordenar por data de envio não é uma solução. É um curativo que cai na primeira atualização do cliente.

A dimensão real do problema

Em uma migração de tamanho médio do Zoho para o Microsoft 365, estamos falando facilmente de 50.000 a 500.000 mensagens afetadas, dependendo da antiguidade das caixas e do porte da organização. Cada e-mail transferido durante a janela de migração carrega a mesma data corrompida, o que torna o problema imediatamente visível para os usuários assim que abrem o Outlook pela primeira vez.

As pastas de Enviados costumam ser as mais problemáticas. Um vendedor que procura um orçamento enviado em março de 2022 se vê vasculhando centenas de e-mails que exibem todos a data da migração. O impacto operacional é real, não é só cosmético.

E ao contrário do que se pode imaginar, o problema não desaparece com o tempo. O INTERNALDATE é fixado no momento da inserção. Ele não se corrige sozinho. Sem intervenção ativa, os e-mails vão manter suas datas corrompidas indefinidamente.

Por que corrigir isso manualmente é mais arriscado do que parece

A tentação é compreensível: como o cabeçalho Date: original ainda está na mensagem, bastaria... corrigir os metadados. No papel, faz sentido. Na prática, em uma caixa de produção com 80.000 e-mails, é uma operação que pode dar muito errado.

Aqui estão alguns casos de borda que um script caseiro provavelmente não vai tratar bem:

• E-mails assinados com S/MIME, cuja assinatura cobre todos os cabeçalhos. Qualquer alteração na estrutura da mensagem invalida a assinatura criptográfica.
• Mensagens criptografadas com PGP, onde o conteúdo é opaco e qualquer manipulação nos envelopes MIME pode corromper a mensagem.
• Cabeçalhos não-ASCII codificados em RFC 2047 (nomes de remetentes com caracteres especiais), que quebram se o script não tratar a codificação corretamente.
• Anexos codificados em base64 com linhas mal terminadas, limites MIME não padrão ou estruturas multipart aninhadas.
• E-mails sem cabeçalho Date: válido (isso existe, especialmente em exportações antigas do Zoho), onde o script precisa decidir o que fazer.

Um script que funciona em 50 e-mails de teste não vai funcionar em uma caixa de produção do Zoho exportada com anos de histórico. E como verificar, mensagem por mensagem, que cada correção está intacta e que os anexos não foram truncados? A verificação é pelo menos tão complexa quanto a correção em si.

Há também a questão das cotas. A API do Exchange Online, via Microsoft Graph, impõe limites de taxa rígidos (os famosos erros 429 Too Many Requests). Um lote sem controle de throttling em 100.000 mensagens pode provocar bloqueios temporários ou erros silenciosos difíceis de diagnosticar depois. Sem mecanismo de retomada em caso de falha, você recomeça do zero.

Como o Redate.io corrige as datas após migração do Zoho

O Redate.io se conecta ao seu tenant do Microsoft 365 via permissões padrão do Azure AD, sem necessidade de acesso admin global. O scan inicial é gratuito: o Redate.io identifica as caixas afetadas e estima o volume de e-mails com datas incorretas, comparando o INTERNALDATE com os valores presentes na cadeia de cabeçalhos de cada mensagem.

A correção usa um motor proprietário que analisa a cadeia completa de cabeçalhos de cada mensagem, identifica as assinaturas específicas das ferramentas de migração do Zoho (seja o Zoho Migration Wizard ou o imapsync configurado para saída do Zoho) e reconstrói os metadados de data através de um pipeline de validação em múltiplas etapas. Cada e-mail corrigido é verificado individualmente: integridade do conteúdo, preservação dos anexos, conformidade com o RFC. Os originais ficam disponíveis em uma pasta de backup acessível por 30 dias.

Sem re-migração. Sem downtime. Os usuários continuam usando o Outlook enquanto a correção roda em segundo plano.

O preço é um pagamento único baseado no volume, sem assinatura. Os detalhes estão disponíveis diretamente no site.

Cenários relacionados que vale conhecer

Se você gerencia várias migrações em paralelo, ou é um MSP que administra clientes saindo do Zoho, saiba que o mesmo problema ocorre em migrações de outras plataformas para o Exchange Online. A mecânica é idêntica: o cabeçalho Received: gerado pelo Exchange sobrescreve o INTERNALDATE independentemente da origem.

Para migrações a partir do Google Workspace, do Exchange on-premises ou via ferramentas como BitTitan MigrationWiz ou CloudM, os artigos dedicados no blog do Redate.io detalham os comportamentos específicos de cada ferramenta. O artigo sobre datas erradas após migração IMAP para Exchange Online oferece uma visão geral de todos os cenários que afetam esse tenant.

Se sua migração envolve caixas compartilhadas ou recursos do Exchange (salas, equipamentos), o problema é o mesmo, e as mesmas ferramentas de correção se aplicam. Os guias de correção IMAP para Exchange no Outlook no site do Redate.io detalham as etapas de conexão ao seu tenant.

Para as equipes que usam imapsync especificamente para sair do Zoho, o artigo imapsync: datas não preservadas documenta as opções de configuração do imapsync e por que elas não bastam para evitar o problema no Exchange Online.

As datas da sua migração do Zoho ainda aparecem erradas no Outlook? Escaneie suas caixas gratuitamente no Redate.io para medir a dimensão exata do problema antes de decidir como agir.