Novo Outlook: datas erradas após migração, causas reais

Dois Outlook, dois comportamentos para os mesmos emails

Se você migrou caixas de correio para o Microsoft 365 recentemente e alguns usuários reclamam que todos os emails antigos aparecem com a mesma data (a da migração), talvez tenha notado algo estranho: quem usa o Outlook clássico às vezes vê a data correta no painel de leitura, enquanto quem está no novo Outlook para Windows vê sistematicamente a data da migração. Mesma caixa. Mesmos emails. Resultados diferentes.

Não é um bug no sentido estrito. É uma decisão de arquitetura com consequências diretas sobre como as datas são exibidas após uma migração IMAP. Para entender o que acontece, é preciso entrar nos detalhes dos cabeçalhos de email e do protocolo IMAP, o que não é exatamente leitura de praia, mas explica por que nenhuma manipulação do lado do cliente resolve o problema.

O INTERNALDATE IMAP: o verdadeiro culpado

Quando um email é armazenado em um servidor IMAP, ele possui dois tipos de datas que coexistem sem se confundir.

O primeiro é o cabeçalho Date:, definido pela RFC 2822. É a data escrita na própria mensagem, aquela que o remetente registrou no momento do envio. Faz parte do corpo da mensagem e nunca muda, independentemente do caminho que o email percorra depois.

O segundo é o INTERNALDATE, um metadado gerenciado pelo servidor IMAP, externo à mensagem. É a data em que o servidor registrou a mensagem. Em uma migração bem configurada, as ferramentas sérias preservam o INTERNALDATE original. Mas em uma migração mal configurada, ou com certas ferramentas que não tratam corretamente esse metadado, o INTERNALDATE é redefinido para a data do dia da migração. O resultado: todos os emails migrados carregam a mesma data de recebimento aos olhos do servidor.

(Aliás, se você já leu os logs do imapsync ou do MigrationWiz, sabe que existem opções específicas para tentar preservar o INTERNALDATE. Essas opções nem sempre funcionam, e alguns servidores de destino se recusam a respeitá-las.)

Outlook clássico: como ele lê as datas

O Outlook clássico, ou seja, as versões COM instaladas localmente (Outlook 2016, 2019, 2021 e o cliente de desktop do Microsoft 365 Apps), usa um mecanismo um pouco mais complexo para determinar qual data exibir na lista de mensagens.

Para emails na pasta Enviados, ele se baseia no cabeçalho Date:. Para emails recebidos, usa preferencialmente o INTERNALDATE do servidor, mas em certos contextos (especialmente quando o cache OST está envolvido ou no primeiro carregamento no painel de leitura), também pode ler a cadeia de cabeçalhos Received: para reconstruir uma data de origem aproximada.

É por isso que se observa esse comportamento inconsistente: o Outlook clássico pode às vezes exibir a data correta no painel de leitura, porque lê o cabeçalho Date: original da mensagem para o preview detalhado, mesmo que a lista de emails em si use o INTERNALDATE corrompido. Mas atenção: isso não é confiável e não corrige nada. A ordenação continua quebrada, as buscas por data continuam distorcidas.

O novo Outlook: uma arquitetura radicalmente diferente

O novo Outlook para Windows, implantado progressivamente desde o final de 2023, não é mais uma aplicação COM. É essencialmente uma Progressive Web App (PWA) baseada na mesma base de código do Outlook na web (OWA). Essa reformulação tem implicações profundas.

O novo Outlook delega completamente a exibição das datas à API do Microsoft 365. Ele não lê os cabeçalhos Received:, não vasculha a cadeia de cabeçalhos em busca de uma data de origem e não faz nenhuma tentativa de reconstrução no lado do cliente. Exibe simplesmente o que o servidor retorna: o INTERNALDATE.

Resultado: se o INTERNALDATE foi corrompido durante a migração, o novo Outlook não hesita. Exibe a data da migração para cada email afetado, sem exceção, sem nuance. É um comportamento mais consistente e previsível do que o do Outlook clássico, mas torna o problema de migração imediatamente visível e impossível de ignorar.

Um admin que migra 300 caixas numa sexta-feira à noite vai descobrir na segunda-feira de manhã que todos os usuários no novo Outlook veem seus arquivos inteiros datados do fim de semana anterior. Os tickets chegam rápido.

Por que nenhuma solução do lado do cliente funciona

Muitos admins tentam soluções do lado do cliente antes de entender que o problema está nos dados do servidor. Veja as tentativas mais comuns e por que elas falham.

Ordenar por "Data de envio" em vez de "Data de recebimento"

A ordenação por data de envio no Outlook se baseia no cabeçalho Date: da mensagem, que está intacto. Então sim, essa ordenação pode funcionar. Mas é um curativo, não uma solução. As buscas por data continuam quebradas. As regras baseadas em data continuam inutilizáveis. E o usuário precisa reconfigurar manualmente cada pasta, cada caixa. Em 300 caixas, isso é inviável. Ordenar por data de envio não resolve o problema, e os usuários finais não entendem por que precisam mudar seus hábitos.

Limpar o cache do Outlook ou recriar o perfil

Isso não afeta o INTERNALDATE no servidor. Após recriar o perfil, o Outlook ressincroniza os emails do servidor e recupera exatamente os mesmos metadados corrompidos. O cache não é o problema.

Usar o OWA no lugar

O OWA e o novo Outlook compartilham a mesma base de dados. Se o INTERNALDATE está corrompido no servidor Exchange Online, o OWA exibe exatamente a mesma data errada. Trocar de cliente não muda os dados.

O problema está no servidor, nos metadados de cada mensagem. Nenhuma ação do lado do cliente pode corrigir dados armazenados no servidor.

A armadilha dos cabeçalhos Received: por que eles complicam tudo

Quando uma ferramenta de migração copia um email de um servidor para outro via IMAP, o servidor de destino adiciona automaticamente um cabeçalho Received: no topo da cadeia, com a data e hora da inserção. É o comportamento normal de servidores SMTP e IMAP conformes às RFC.

Esses cabeçalhos se acumulam na ordem inversa do caminho percorrido pelo email. O mais recente fica no topo. Alguns clientes de email leem o primeiro Received: para estimar a data de recebimento, o que resulta na data da migração em vez da data original.

Para ser preciso: esse comportamento não é exclusivo de uma única ferramenta. BitTitan MigrationWiz, CloudM, imapsync, GSMMO e até uma cópia manual IMAP entre dois clientes Thunderbird produzem o mesmo resultado. O cabeçalho Date: original permanece intacto na mensagem. É precisamente isso que torna a correção tecnicamente possível. Mas o INTERNALDATE é um metadado distinto gerenciado pelo servidor e não pode ser corrigido simplesmente manipulando os cabeçalhos da mensagem no lado do cliente.

Para aprofundar esse mecanismo, o artigo sobre IMAP INTERNALDATE e as datas quebradas detalha como esse metadado é gerenciado conforme o servidor.

Quais ferramentas de migração causam esse problema no Microsoft 365

A pergunta aparece com frequência: todas as ferramentas de migração causam esse problema?

A resposta curta é que depende da configuração e da plataforma de destino. No Exchange Online / Microsoft 365, o servidor é particularmente rigoroso no gerenciamento do INTERNALDATE. Mesmo ferramentas que tentam preservá-lo às vezes falham, pois a API Graph e o EWS (Exchange Web Services) têm comportamentos diferentes dependendo do caminho de inserção utilizado.

O BitTitan MigrationWiz é uma das ferramentas mais usadas para migrações para o Microsoft 365 e também uma daquelas cujos problemas de datas estão melhor documentados. A página dedicada corrigir datas do BitTitan no Microsoft 365 cobre as configurações específicas a monitorar. O CloudM e o imapsync têm suas próprias particularidades, documentadas respectivamente em corrigir datas do CloudM no Microsoft 365 e corrigir datas do imapsync no Microsoft 365.

O que é comum a todas essas ferramentas: o cabeçalho Date: original sobrevive à migração. É a base sobre a qual uma correção é possível.

Por que um script caseiro é uma má ideia aqui

Entender o problema às vezes cria a ilusão de que a solução é simples. Não é, não em escala de produção.

Modificar os metadados de emails armazenados no Exchange Online não é trivial. A API Graph da Microsoft impõe limites de taxa rigorosos (o erro 429 Too Many Requests em um batch noturno chega rápido). O tratamento de emails assinados com S/MIME ou criptografados com PGP exige atenção especial para não invalidar as assinaturas. Estruturas multipart com anexos volumosos adicionam restrições de timeout de rede. E principalmente: como verificar, email por email, que a correção funcionou sem alterar o conteúdo ou os anexos?

Um script que funciona bem em 50 emails de teste não vai se comportar da mesma forma numa caixa com 40.000 mensagens e 8 anos de histórico. A probabilidade de um caso limite quebrar alguma coisa aumenta a cada milhar de mensagens adicional. E sem mecanismo de rollback, um erro no meio do processo deixa a caixa num estado inconsistente.

Veja também: corrigir datas de email após migração no Microsoft 365 para uma visão completa das opções disponíveis.

O que o Redate.io faz na prática

Cada pessoa inicia sessão com a sua própria conta Microsoft, e o Redate.io abre apenas essa caixa de correio com o acesso que essa sessão concede, sem portal e sem aplicação a registar. O Redate.io analisa gratuitamente os emails com datas incorretas e aplica um motor de correção proprietário nas mensagens identificadas. O pipeline de análise em múltiplos estágios realiza correspondência em centenas de assinaturas de ferramentas de migração conhecidas, validação de conformidade RFC e análise da cadeia de cabeçalhos para reconstruir os metadados de data corretos.

Cada email corrigido é verificado individualmente. As mensagens originais ficam disponíveis numa pasta de backup visível na sua própria caixa de correio, até que as elimine. O modelo de preços é um pagamento único por caixa de correio, sem assinatura.

O novo Outlook passa então a exibir as datas corretas, porque os dados do servidor foram corrigidos, não mascarados.

Você tem caixas afetadas no novo Outlook? Lance um scan gratuito no Redate.io para identificar exatamente quantos emails estão envolvidos antes de decidir o que fazer.