Import PST no Outlook: por que todas as datas mudam

O sintoma: todos os seus emails têm a data de hoje

Você acabou de terminar um import PST no Outlook. A barra de progresso chegou a 100%, tudo correu bem. Aí você abre a caixa de entrada... e cada email importado exibe a data de hoje. Uma mensagem de 2019, outra de 2021, um arquivo de cinco anos: todos com a mesma data. A do dia do import.

Não é um bug de exibição. Não é um problema de fuso horário. É um comportamento perfeitamente documentado, coerente com a forma como o IMAP gerencia os metadados de data. Mas continua sendo um desastre para quem precisa encontrar emails antigos por data.

PST local e IMAP: dois mundos muito diferentes

Antes de explicar por que as datas quebram, é preciso entender o que é um arquivo PST do ponto de vista do gerenciamento de datas.

Um arquivo PST (Personal Storage Table) é um formato proprietário da Microsoft. Ele armazena emails com seus metadados completos: data de envio, data de recebimento, anexos, categorias, indicadores de leitura. Esses metadados são gerenciados diretamente pelo Outlook, fora de qualquer protocolo de mensagens. Quando você consulta um PST no Outlook sem conexão a um servidor, as datas exibidas vêm diretamente dos campos internos do arquivo PST. Até aqui, tudo bem.

O problema aparece quando você tenta transferir esse conteúdo para uma caixa de email hospedada em um servidor IMAP, seja Microsoft 365, Google Workspace ou qualquer outra hospedagem convencional. Aí você sai do mundo PST e entra no mundo IMAP, e as regras mudam radicalmente.

IMAP APPEND e o INTERNALDATE: o coração do problema

No IMAP, cada mensagem armazenada no servidor possui dois tipos de dados de data:

• O cabeçalho Date: (RFC 2822), que faz parte do conteúdo da mensagem em si. É a data inscrita na mensagem pelo remetente.
• O INTERNALDATE, que é um metadado gerenciado pelo servidor IMAP. Representa o momento em que a mensagem foi depositada no servidor. É esse valor que o Outlook usa para ordenar as mensagens na visualização "Data de recebimento".

(Se você já tentou ler os cabeçalhos brutos de um email, sabe que não é exatamente uma leitura relaxante. Mas é lá que tudo acontece.)

Quando um email chega normalmente ao seu servidor, o servidor de mensagens define automaticamente o INTERNALDATE no momento exato do recebimento. Resultado: a data exibida no Outlook corresponde a quando você recebeu a mensagem.

Quando o Outlook importa um arquivo PST para uma caixa IMAP, ele usa o comando IMAP APPEND para enviar cada mensagem ao servidor. O padrão IMAP permite passar um INTERNALDATE explícito durante um APPEND. Mas o Outlook não faz isso. Ele envia as mensagens sem especificar um INTERNALDATE. O servidor IMAP, na ausência de instrução, aplica sua regra padrão: o INTERNALDATE é definido como a hora atual, ou seja, o momento do import.

Resultado: 8.000 emails importados, 8.000 emails com a data de hoje.

Por que o Outlook se comporta assim

Não é um esquecimento da Microsoft. É uma escolha de implementação que provavelmente pareceu razoável na época: no caso de uso original do import PST, o usuário arquiva mensagens localmente e as "importa" para sua caixa atual. A data relevante para ordenação seria a data de recebimento original... mas a Microsoft optou por não propagar o INTERNALDATE durante a operação de import.

Para ser preciso, esse comportamento se refere ao import PST via assistente nativo do Outlook (Arquivo > Abrir e Exportar > Importar/Exportar). Outros métodos de import, como certas ferramentas de terceiros ou migrações pelo Centro de Administração do Exchange, podem se comportar de forma diferente dependendo da implementação do IMAP APPEND.

Esse comportamento é conhecido e documentado nos fóruns da Microsoft há anos. Não mudou com o Outlook 2016, nem com o Outlook 2019, nem com as versões atuais do Microsoft 365. Um usuário que faz um import PST hoje vai encontrar exatamente o mesmo problema de 2015.

O que diferencia isso de uma migração IMAP clássica

É aqui que fica interessante, porque o import PST produz um resultado parecido com uma migração IMAP clássica com datas quebradas, mas por um mecanismo diferente.

Numa migração IMAP típica, por exemplo com BitTitan MigrationWiz ou imapsync, os emails passam de um servidor IMAP de origem para um servidor IMAP de destino. A ferramenta de migração recupera as mensagens e as reinjeta via IMAP APPEND. Algumas ferramentas preservam corretamente o INTERNALDATE, outras não. Mas em todos os casos, as mensagens já têm um cabeçalho Received: com a data da migração adicionado no processo, o que pode perturbar a exibição no Outlook independentemente do INTERNALDATE.

Com um import PST, o mecanismo é mais simples: não há cabeçalho Received: de migração adicionado (os arquivos PST não transitam por um servidor de mensagens intermediário), mas o INTERNALDATE simplesmente nunca é definido com o valor correto. O resultado visível é idêntico; a causa subjacente é ligeiramente diferente.

Essa distinção tem uma consequência direta na correção: a abordagem a adotar não é exatamente a mesma dependendo de se você está tratando uma migração IMAP ou um import PST. Veja também por que o INTERNALDATE causa datas quebradas para uma explicação detalhada dos dois casos.

Por que as opções de exibição do Outlook não resolvem nada

A reação habitual ao descobrir o problema é vasculhar as configurações do Outlook. E existe de fato um parâmetro que parece promissor: a possibilidade de ordenar os emails por "Data" em vez de "Data de recebimento".

Ordenar por data de envio não é uma solução. É um curativo.

Aqui está o motivo: mesmo que você mude a ordenação para exibir a coluna "Data" (que corresponde ao cabeçalho Date: da mensagem, ou seja, a data original), vários problemas persistem:

• A pesquisa do Outlook indexa pelo INTERNALDATE. Uma busca por "emails de janeiro de 2020" não vai retornar seus emails importados de janeiro de 2020, porque o INTERNALDATE deles diz que são do dia do import.
• As pastas "Hoje", "Esta semana", "Este mês" na interface do Outlook são baseadas no INTERNALDATE, não no cabeçalho Date:.
• Nas interfaces web (Outlook Web App, Gmail) e nos clientes móveis, a data exibida e o comportamento de ordenação dependem quase sempre do INTERNALDATE do servidor.
• Regras e filtros automáticos aplicados à data de recebimento não vão funcionar corretamente.

Enfim, mudar a exibição resolve o problema de um usuário específico, num cliente específico, numa configuração específica. Não corrige o problema na origem.

A ressincronização do OST também não serve de nada

Outra tentativa clássica: limpar o cache OST e forçar uma ressincronização completa a partir do servidor. A ideia é que o problema talvez venha do cache local do Outlook, não do servidor.

Pista errada. O arquivo OST é um cache local que reflete o estado do servidor IMAP. Se o INTERNALDATE está errado no servidor, vai continuar errado no OST após a ressincronização. Excluir o OST não altera os dados armazenados no servidor Exchange Online ou no Google Workspace. O servidor é quem tem autoridade.

A única forma de corrigir as datas é corrigir os metadados diretamente no lado do servidor, mensagem por mensagem. E é exatamente aí que fica complicado fazer isso manualmente.

O problema de escala: 1 email é trivial. 15.000 é outra história

Tecnicamente, se você entende o problema, pode imaginar escrever um script que percorre a caixa, lê o cabeçalho Date: de cada mensagem e corrige o INTERNALDATE correspondentemente. Entender o problema é uma coisa. Corrigir 15.000 emails sem perder um único é outra completamente diferente.

Algumas realidades de campo:

• As APIs do Microsoft Graph e do Gmail impõem limites de taxa (rate limits). Um script ingênuo vai disparar erros 429 Too Many Requests, interromper a execução no meio de uma correção, e te deixar com uma caixa parcialmente corrigida, sem saber quais emails foram processados e quais não foram.
• Alguns emails num PST podem ter cabeçalhos Date: malformados ou ausentes. Um script sem tratamento desses casos limites pode corromper essas mensagens ou ignorá-las silenciosamente.
• Emails assinados (S/MIME) ou criptografados (PGP) têm restrições adicionais de integridade. Modificar seus metadados sem cuidado pode invalidar a assinatura criptográfica.
• Estruturas multipart/alternative com limites MIME complexos às vezes reagem de forma imprevisível a operações de modificação.
• Nenhum mecanismo de rollback. Se algo der errado no meio do processamento, como voltar ao estado inicial?

Um script que funciona em 10 emails de teste não vai funcionar numa caixa de produção de 50.000 mensagens. No ano passado, um cliente com um arquivo PST de 40 GB tentou corrigir isso com um script Python encontrado no Stack Overflow. Resultado: 3.000 emails duplicados, 200 mensagens com anexos inacessíveis, e duas semanas de limpeza manual.

O que o Redate.io faz nesse caso específico

Redate.io analisa os metadados de cada mensagem na caixa de destino, identifica os emails com datas incorretas (incluindo os provenientes de um import PST), e aplica uma correção via seu motor proprietário. O pipeline de análise multi-etapas compara a cadeia de cabeçalhos de cada mensagem, extrai a data original com validação de conformidade RFC, e realiza uma correção direcionada dos metadados sem alterar o conteúdo da mensagem.

Cada email corrigido é verificado individualmente. Os originais são mantidos numa pasta de backup visível por 30 dias antes de qualquer modificação definitiva. A correção funciona nas três plataformas principais: Microsoft 365 (via Azure AD), Google Workspace (via delegação de domínio), e IMAP direto para hospedagens convencionais.

A varredura inicial é gratuita. Ela permite ver exatamente quantos emails foram afetados e qual é a distribuição das datas incorretas, antes de decidir qualquer coisa.

Veja também:

• Corrigir datas de email após migração Microsoft 365
• Outlook: data recebida IMAP vs data de envio
• É possível corrigir as datas dos emails após migração?

Seu import PST sobrescreveu todas as datas dos seus emails? Faça uma varredura gratuita da sua caixa no Redate.io para medir a extensão do problema antes de agir.