Antidatar um e-mail: o que é possível e detectável

Antidatar um e-mail: do que estamos falando exatamente?

A pergunta aparece com frequência em fóruns de administração de sistemas e grupos Slack de MSPs: é possível modificar a data de um e-mail após o envio? A resposta curta é sim, tecnicamente. Mas a resposta completa é bem menos tranquilizadora para quem quiser fazer isso com intenções duvidosas.

Um e-mail não é um arquivo monolítico. É uma coleção de cabeçalhos textuais seguidos de um corpo de mensagem. Entre esses cabeçalhos, vários carregam informações de data. E alguns são mais fáceis de modificar do que outros.

Três camadas de datação coexistem em cada e-mail:

• O cabeçalho Date: (RFC 2822), escrito pelo cliente de e-mail no momento do envio
• Os cabeçalhos Received:, adicionados por cada servidor que retransmite a mensagem
• O INTERNALDATE IMAP, um metadado armazenado no lado do servidor, independente do conteúdo da mensagem

Cada uma dessas camadas pode ser modificada. Nenhuma delas pode ser alterada sem deixar rastros.

Modificar o cabeçalho Date:: a manipulação mais óbvia

O cabeçalho Date: é texto simples no arquivo .eml. Tecnicamente, qualquer editor hexadecimal ou script Python consegue reescrevê-lo em segundos. Se você já abriu os cabeçalhos brutos de um e-mail no Gmail (aquele pequeno menu "Mostrar original"), sabe que qualquer pessoa consegue ler isso.

O problema? Desde 2004, a grande maioria dos servidores de e-mail assina as mensagens enviadas com DKIM (DomainKeys Identified Mail). Essa assinatura criptográfica cobre explicitamente vários cabeçalhos, incluindo Date:, From:, Subject: e o corpo da mensagem. A assinatura fica armazenada no cabeçalho DKIM-Signature:.

Modificar o Date: após a assinatura invalida mecanicamente a verificação DKIM. Qualquer servidor receptor pode verificar a assinatura buscando a chave pública no DNS do domínio remetente. Se a assinatura não corresponder mais, a mensagem é marcada como alterada. Gmail, Outlook.com e todos os grandes provedores fazem essa verificação automaticamente.

(Aliás, se quiser ver uma assinatura DKIM na prática, abra os cabeçalhos brutos de um e-mail recebido do Gmail ou do Office 365: você vai encontrar uma linha DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... que parece ruído aleatório, mas é na verdade um hash criptográfico de toda a mensagem.)

Resultado: modificar o Date: em um e-mail assinado com DKIM é quebrar o selo. A alteração fica visível para qualquer administrador que saiba onde procurar.

Reescrever os cabeçalhos Received:: uma cadeia difícil de falsificar

Os cabeçalhos Received: rastreiam o caminho percorrido por um e-mail entre o remetente e o destinatário. Cada servidor SMTP que toca a mensagem adiciona um deles, com seu nome, endereço IP e um carimbo de data e hora. Um e-mail que passa por dois ou três relays contém dois ou três cabeçalhos Received: empilhados.

É possível modificá-los? Tecnicamente, sim, na sua própria cópia da mensagem. Mas aqui está a armadilha: o destinatário também tem uma cópia. E o servidor dele adicionou seu próprio cabeçalho Received: por último. Esse cabeçalho está sob o controle do destinatário, não do remetente. É impossível falsificá-lo de fora.

A coerência da cadeia é verificável. Se os timestamps dos Received: sucessivos forem inconsistentes (um relay intermediário teria recebido a mensagem antes de o remetente tê-la enviado, por exemplo), isso é imediatamente suspeito. Ferramentas de análise forense de e-mail como MXToolbox ou as ferramentas internas das equipes de segurança verificam exatamente isso.

Na verdade, não é bem correto dizer que os Received: são totalmente impossíveis de falsificar: um atacante que controla sua própria infraestrutura de e-mail pode fabricar cabeçalhos críveis para os relays que ele domina. Mas ele nunca controla o último elo: o servidor do destinatário.

O INTERNALDATE IMAP: o caso mais técnico

O INTERNALDATE é um metadado IMAP armazenado no lado do servidor. Não é um cabeçalho dentro da mensagem em si: é um valor que o servidor associa à mensagem em seu banco de dados interno. É esse valor que a maioria dos clientes de e-mail usa para ordenar as mensagens na caixa de entrada.

O comando IMAP APPEND permite depositar uma mensagem num servidor especificando explicitamente um INTERNALDATE. É uma funcionalidade legítima do protocolo, documentada na RFC 3501. As ferramentas de migração utilizam isso constantemente: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... todas depositam e-mails no servidor de destino com um INTERNALDATE especificado.

Teoricamente, alguém com acesso IMAP à própria caixa de e-mail poderia depositar uma mensagem com qualquer INTERNALDATE. Mas essa manipulação não modifica os cabeçalhos da mensagem. O Date: original permanece intacto, os Received: permanecem intactos, a assinatura DKIM permanece intacta. Só o metadado de ordenação no lado do servidor muda.

Para um especialista que examina a mensagem bruta, a discrepância entre o INTERNALDATE e o Date: é imediatamente visível. E se a mensagem estiver assinada com DKIM, a data original está criptograficamente atestada.

O Message-ID: uma impressão digital difícil de falsificar

Cada e-mail gera um identificador único, o cabeçalho Message-ID:. Esse identificador é construído pelo servidor SMTP remetente no momento do envio, combinando geralmente um timestamp, um identificador aleatório e o nome de domínio do servidor.

Um Message-ID típico parece com isso: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. O timestamp muitas vezes está codificado diretamente no identificador. Modificar a data da mensagem deixando um Message-ID com um timestamp incompatível cria uma inconsistência imediatamente detectável.

Além disso, os Message-IDs são indexados pelos grandes sistemas de mensageria. Google, Microsoft e outros players mantêm logs que permitem rastrear quando uma mensagem realmente circulou em suas infraestruturas. Em um contexto jurídico ou forense, esses logs são acessíveis via procedimentos judiciais.

Na prática: quem pode detectar uma tentativa de manipulação?

Vamos colocar a pergunta de forma concreta. Você recebe um e-mail cuja data você suspeita ter sido modificada. O que um administrador de TI ou um advogado com algum conhecimento técnico pode fazer?

• Verificação DKIM: no Gmail, o menu "Mostrar original" exibe diretamente o resultado da verificação DKIM no topo da página. Um "PASS" confirma a integridade da mensagem desde o envio. Um "FAIL" ou "SOFTFAIL" sinaliza uma alteração.
• Análise dos cabeçalhos: ferramentas como MXToolbox Header Analyzer ou o Google Admin Toolbox analisam automaticamente a cadeia dos Received: e apontam inconsistências temporais.
• Coerência entre Message-ID e Date: um analista pode comparar o timestamp codificado no Message-ID com o valor do Date: declarado.
• Logs do servidor: se o e-mail passou por um servidor do qual você é administrador, os logs SMTP contêm a data e hora reais de aceitação da mensagem, independentemente de qualquer cabeçalho.

Bom, as ferramentas de detecção são acessíveis, gratuitas e não exigem perícia forense avançada. Um admin de TI um pouco curioso consegue verificar a integridade de um e-mail em menos de dois minutos.

O único caso legítimo de modificação massiva de datas: a migração IMAP

Existe um cenário em que centenas de milhares de e-mails acabam com datas incorretas sem nenhuma intenção maliciosa: a migração IMAP.

Você acabou de terminar a migração de 150 caixas Exchange para o Google Workspace. Na segunda-feira de manhã, os tickets começam a chegar. Os usuários relatam que todos os e-mails antigos aparecem com a mesma data, a do fim de semana de migração. As caixas de entrada ficaram ilegíveis.

O que aconteceu é documentado e previsível: a ferramenta de migração (BitTitan, CloudM, imapsync, tanto faz) depositou os e-mails no Google Workspace via IMAP APPEND. Ela especificou um INTERNALDATE correspondente à data de migração, não à data original do e-mail. Resultado: o Outlook, que ordena por INTERNALDATE por padrão, exibe a data de migração para todas as mensagens. Por que seus emails mostram a data errada explica esse mecanismo em detalhes.

O cabeçalho Date: original está intacto em cada mensagem. As assinaturas DKIM estão intactas. O conteúdo não foi alterado. É apenas o INTERNALDATE no lado do servidor que está incorreto.

Esse problema afeta BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO e todas as ferramentas que usam IMAP APPEND sem preservar corretamente o INTERNALDATE. O artigo dedicado ao BitTitan MigrationWiz cobre as particularidades dessa ferramenta. O checklist de migração de e-mail lista os pontos a verificar antes e depois de uma migração para evitar esse tipo de problema.

A diferença entre corrigir e falsificar

A correção que o Redate.io realiza é o oposto de uma tentativa de falsificação. O motor de correção proprietário analisa a cadeia de cabeçalhos de cada mensagem, identifica a data original codificada no cabeçalho Date: (RFC 2822) que nunca foi alterado, e corrige os metadados de data para alinhá-los com essa informação autêntica já presente na mensagem.

O cabeçalho Date: é a fonte da verdade. Foi escrito pelo cliente de e-mail do remetente no momento do envio. Está coberto pela assinatura DKIM. O Redate.io não o modifica. O que é corrigido é a discrepância introduzida pela ferramenta de migração, não a data original.

Corrigir 47.000 e-mails após uma migração malfeita sem perder nenhum, sem quebrar as conversas, sem corromper anexos, sem disparar erro 429 às 3h da manhã na API do Google: isso é um pipeline de análise multi-etapas com tratamento de casos extremos (S/MIME, PGP, codificações não-ASCII conforme RFC 2047, estruturas multipart complexas). Um script Python de cinco linhas não sobreviveria à primeira caixa de produção. É possível corrigir as datas dos emails após migração? detalha por que o DIY é arriscado em volumes reais.

O Redate.io escaneia as caixas de e-mail gratuitamente, identifica as mensagens com datas incorretas e corrige via pipeline de validação que verifica cada mensagem individualmente. Os originais são mantidos em uma pasta de backup visível por 30 dias. Se algo der errado, o rollback é possível.

Sua migração deslocou as datas dos seus e-mails? Faça um scan gratuito no Redate.io para medir a extensão do problema antes de decidir o que fazer.