Recriar perfil Outlook: por que as datas mudam

O procedimento de suporte que quebra as datas

Um usuário reclama que o Outlook parou de sincronizar. Os emails não chegam, a pasta Enviados não atualiza, o ícone fica girando sem parar. O técnico diagnostica um perfil corrompido, exclui o arquivo OST, recria o perfil Outlook do zero. Resultado: o Outlook volta a conectar, os emails reaparecem, tudo parece funcionar.

Até a manhã seguinte, quando o usuário abre a caixa e percebe que 8 anos de correspondência exibem a mesma data: hoje.

É exatamente o mesmo sintoma de uma migração IMAP mal feita. E pelas mesmas razões.

O que acontece tecnicamente

Para entender por que recriar um perfil produz esse resultado, é preciso voltar a uma distinção que a maioria dos técnicos conhece mal: a diferença entre o cabeçalho Date: de um email e seu INTERNALDATE IMAP.

Cada email contém nos seus cabeçalhos RFC 2822 um campo Date: que indica quando a mensagem foi enviada. Esse campo é escrito pelo cliente de email do remetente no momento do envio e transportado intacto por todos os servidores até a sua caixa. Ele nunca muda. Um email enviado em 14 de março de 2019 às 09h32 terá sempre esse campo Date: intacto, independentemente do que aconteça depois.

O INTERNALDATE IMAP é outra coisa. É uma metadado gerenciado pelo servidor de email, independente do conteúdo da mensagem. Ele indica quando a mensagem foi "depositada" na caixa. Em condições normais, quando um email chega via SMTP, o servidor registra o horário de recebimento como INTERNALDATE. Um email recebido em 14 de março de 2019 terá, portanto, um INTERNALDATE coerente com sua data de envio.

O Outlook, por padrão, ordena e exibe os emails de acordo com o INTERNALDATE transmitido pelo servidor IMAP, não pelo campo Date: da mensagem em si. (Se você já abriu as propriedades completas de um email no Outlook para ver os cabeçalhos brutos, sabe que não é exatamente uma leitura de lazer.)

O que a exclusão do arquivo OST provoca

Quando o Outlook usa uma conta IMAP, ele mantém um banco de dados local: o arquivo OST (Offline Storage Table). Esse arquivo é um espelho local dos emails armazenados no servidor, com seus metadados, estados de leitura, categorias, etc.

Excluir o arquivo OST equivale a apagar esse espelho local. O Outlook precisa então baixar tudo de novo do servidor IMAP.

O problema? Quando o Outlook baixa uma mensagem via IMAP, ele usa o comando FETCH para recuperar o conteúdo. Mas não usa sistematicamente o comando FETCH INTERNALDATE para recuperar e preservar a data IMAP original. Em algumas configurações e versões do Outlook, o cliente reconstrói seu índice local usando a data em que baixou a mensagem em vez do INTERNALDATE armazenado no servidor.

E aí todos os emails da caixa acabam datados do dia do recarregamento.

Nem todas as versões do Outlook se comportam igual

Correção: esse comportamento não afeta todas as versões do Outlook de forma idêntica, e é aí que o diagnóstico fica complexo.

O Outlook 2016 e 2019 em modo IMAP têm comportamentos documentados de reconstrução incorreta de índice após exclusão do cache. O novo Outlook (baseado na web, implantado progressivamente desde o final de 2023) gerencia o cache de forma diferente e pode produzir resultados variáveis. O Outlook via Exchange/Microsoft 365 com uma conta configurada em modo Exchange é menos exposto a esse problema específico, pois o protocolo MAPI/Exchange gerencia a sincronização de forma diferente do IMAP.

Mas se o seu usuário está em uma conta IMAP configurada no Outlook clássico e um técnico excluiu o arquivo OST ou recriou o perfil: o risco é real.

Como distinguir esse caso de uma migração real

Um administrador de TI que recebe tickets de "minhas datas estão erradas" após uma recriação de perfil pode achar equivocadamente que se trata de um problema de migração. Veja como distinguir os dois casos.

O caso de uma migração IMAP

Em uma migração IMAP (BitTitan, CloudM, imapsync, etc.), a ferramenta copia os emails de um servidor para outro. Para cada mensagem copiada, ela cria uma nova entrada no servidor de destino. Se a ferramenta não especifica explicitamente o INTERNALDATE original, o servidor de destino registra o horário atual como INTERNALDATE. Além disso, algumas ferramentas adicionam um cabeçalho Received: com a data da migração, o que agrava o problema em determinados clientes. Você pode ver os detalhes desse mecanismo no artigo sobre IMAP INTERNALDATE e as datas quebradas.

O caso da recriação de perfil

Aqui, os emails ainda estão no mesmo servidor, com os mesmos INTERNALDATE originais. Nada mudou no lado do servidor. É apenas o cache local do Outlook que foi reconstruído com datas incorretas. O sintoma visível é idêntico (todos os emails exibem a mesma data recente), mas a origem é diferente.

Para confirmar: acesse a caixa via webmail (Gmail, Outlook.com ou a interface webmail do seu provedor). Se as datas exibidas no webmail estiverem corretas, o problema é puramente local no Outlook. Se as datas também estiverem erradas no webmail, o problema é no servidor (migração ou alteração dos INTERNALDATE no próprio servidor).

Por que as datas originais ainda podem ser recuperadas

Boa notícia: nos dois casos (migração ou recriação de perfil), as datas originais não são perdidas.

O cabeçalho Date: RFC 2822 é parte integrante da mensagem. É tão imutável quanto o corpo do texto ou os anexos. Um email enviado em 2017 contém no seu texto bruto algo como:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Essa linha está presente na mensagem armazenada no servidor. Não foi alterada. O que o Outlook exibe (incorretamente) é um metadado externo ao conteúdo da mensagem.

É isso que torna a correção possível. O motor do Redate.io analisa a cadeia de cabeçalhos de cada mensagem para extrair a data de origem real, depois realiza uma correção direcionada dos metadados sem alterar o conteúdo da mensagem. O INTERNALDATE visível pelo Outlook é reconstruído a partir dessa informação autêntica, sempre presente na mensagem.

A armadilha da recriação "limpa"

Você acabou de resolver um problema de sincronização para um usuário. O Outlook dele voltou a funcionar, os novos emails chegam. Você fecha o chamado.

Três dias depois, o usuário liga de volta: está procurando um email de um fornecedor do ano passado, mas no Outlook todos os emails de 2023 aparecem como recebidos "ontem". Ele não encontra nada. O arquivamento automático pode ter classificado emails recentes como antigos. E o chefe dele está pedindo uma conversa por email de setembro de 2022 para um processo.

Esse cenário acontece com frequência. Não porque o técnico errou, mas porque esse comportamento do Outlook não está documentado de forma visível nos guias padrão de suporte.

As falsas soluções que não resolvem nada

Ordenar os emails por "Data de envio" em vez de "Data de recebimento" no Outlook é a primeira coisa que os usuários tentam. E parece funcionar... até perceberem que a ordenação por data de envio só está disponível em alguns pastas, que desaparece quando se muda de visualização, e que outros aplicativos (mobile, webmail, regras de ordenação automática) continuam usando o INTERNALDATE incorreto.

Ordenar por data de envio não é uma solução. É um curativo que esconde o sintoma sem tocar no problema real. Explicamos isso em detalhe no artigo Ordenar por data de envio não resolve o problema.

Recriar o perfil uma segunda vez? Não muda nada se o comportamento do Outlook reconstrói seu cache com a data atual.

Exportar e reimportar em PST? Cuidado. Uma exportação PST a partir de um Outlook com datas corrompidas exporta os metadados corrompidos. O arquivo PST conterá as datas erradas. Reimportar esse arquivo não corrige nada e pode até piorar a situação, criando duplicatas com datas inconsistentes. Esse assunto é tratado separadamente no artigo sobre importar PST no Outlook e as datas que vão para o dia de hoje.

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

Seja o problema de uma migração IMAP ou de uma recriação de perfil Outlook, o resultado no lado do servidor é similar: emails com metadados de data inconsistentes com seu conteúdo real.

O Redate.io conecta diretamente à caixa de email (Google Workspace, Microsoft 365 ou IMAP direto), verifica todas as mensagens para identificar aquelas com metadados incorretos e aplica seu pipeline de análise multi-etapas para corrigir cada email individualmente. Cada correção é verificada. As mensagens originais são mantidas numa pasta visível até serem eliminadas manualmente.

O processo trata os casos limite que scripts caseiros erram sistematicamente: mensagens assinadas com S/MIME, emails com codificações não-ASCII nos cabeçalhos (RFC 2047), estruturas multipart complexas, cabeçalhos Date: com fusos horários não padrão ou malformados. Um script que roda corretamente em 50 emails de teste em uma caixa de desenvolvimento pode corromper irremediavelmente 2.000 mensagens em produção. Não existe rollback nativo em IMAP depois que uma mensagem é substituída sem backup prévio.

Para casos relacionados ao Outlook especificamente, a página de correção corrigir datas de cópia IMAP manual no Outlook detalha os passos para conectar sua caixa e iniciar a análise.

Prevenir o problema nas próximas intervenções

Se você é técnico ou administrador de TI e intervém regularmente em perfis Outlook, alguns hábitos ajudam a evitar essa situação.

Antes de excluir um arquivo OST ou recriar um perfil, verifique as datas exibidas no webmail. Se estiverem corretas, registre isso no seu chamado. Após a recriação, acesse novamente o webmail e compare as datas exibidas com as do Outlook. Se aparecer alguma diferença, o problema fica identificado imediatamente, antes que o usuário reclame três dias depois.

Para migrações planejadas, o checklist de migração de email lista as verificações a fazer antes e depois para detectar esse tipo de problema logo ao final da operação.

Você recriou um perfil Outlook e agora todas as datas da sua caixa estão erradas? Inicie um scan gratuito no Redate.io para identificar os emails afetados e corrigir os metadados sem tocar no conteúdo das suas mensagens.