Antidater un email : ce qui est possible et détectable

Antidater un email : de quoi parle-t-on exactement ?

La question revient régulièrement dans les forums d'administration système et les groupes Slack de MSPs : est-il possible de modifier la date d'un email après envoi ? La réponse courte est oui, techniquement. Mais la réponse complète est beaucoup moins rassurante pour quiconque voudrait le faire à des fins douteuses.

Un email n'est pas un fichier monolithique. C'est une collection d'en-têtes textuels suivis d'un corps de message. Parmi ces en-têtes, plusieurs portent des informations de date. Et certains sont plus faciles à modifier que d'autres.

Trois couches de datation coexistent dans chaque email :

• L'en-tête Date: (RFC 2822), écrit par le client mail au moment de l'envoi
• Les en-têtes Received:, ajoutés par chaque serveur qui relaie le message
• L'INTERNALDATE IMAP, une métadonnée stockée côté serveur, indépendante du contenu du message

Chacune de ces couches est modifiable. Aucune ne l'est sans laisser de traces.

Modifier l'en-tête Date: : la manipulation la plus évidente

L'en-tête Date: est du texte brut dans le fichier .eml. Techniquement, n'importe quel éditeur hexadécimal ou script Python peut le réécrire en quelques secondes. Si vous avez déjà ouvert les en-têtes bruts d'un email dans Gmail (le petit menu "Afficher l'original"), vous savez que c'est lisible par n'importe qui.

Le problème ? Depuis 2004, la grande majorité des serveurs mail signent les emails sortants avec DKIM (DomainKeys Identified Mail). Cette signature cryptographique couvre explicitement plusieurs en-têtes, dont Date:, From:, Subject:, et le corps du message. La signature est stockée dans l'en-tête DKIM-Signature:.

Modifier le Date: après signature invalide mécaniquement la vérification DKIM. N'importe quel serveur de réception peut vérifier la signature en récupérant la clé publique dans le DNS du domaine expéditeur. Si la signature ne correspond plus, le message est marqué comme altéré. Gmail, Outlook.com et tous les grands fournisseurs font cette vérification automatiquement.

(D'ailleurs, si vous voulez voir concrètement une signature DKIM, ouvrez les en-têtes bruts d'un email reçu de Gmail ou d'Office 365 : vous y trouverez une ligne DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... qui ressemble à du bruit mais qui est en réalité un hash cryptographique de tout le message.)

Résultat : modifier le Date: sur un email signé DKIM, c'est casser le sceau. La modification est visible par n'importe quel administrateur qui sait chercher.

Réécrire les en-têtes Received: : une chaîne difficile à falsifier

Les en-têtes Received: tracent le chemin parcouru par un email entre l'expéditeur et le destinataire. Chaque serveur SMTP qui touche le message en ajoute un, avec son nom, son adresse IP, et un horodatage. Un email qui passe par deux ou trois relais contient donc deux ou trois en-têtes Received: empilés.

Peut-on les modifier ? Techniquement, oui, sur sa propre copie du message. Mais voici le piège : le destinataire a lui aussi une copie. Et son serveur a ajouté son propre en-tête Received: en dernier. Cet en-tête est sous le contrôle du destinataire, pas de l'expéditeur. Il est impossible à falsifier depuis l'extérieur.

La cohérence de la chaîne est vérifiable. Si les timestamps des Received: successifs sont incohérents (un relais intermédiaire aurait reçu le message avant l'expéditeur l'ait envoyé, par exemple), c'est immédiatement suspect. Les outils d'analyse forensique email comme MXToolbox ou les outils internes des équipes sécurité vérifient exactement ça.

En fait, ce n'est pas tout à fait exact de dire que les Received: sont impossibles à falsifier intégralement : un attaquant qui contrôle sa propre infrastructure mail peut fabriquer des en-têtes crédibles pour les relais qu'il maîtrise. Mais il ne contrôle jamais le dernier maillon : le serveur du destinataire.

L'INTERNALDATE IMAP : le cas le plus technique

L'INTERNALDATE est une métadonnée IMAP stockée côté serveur. Ce n'est pas un en-tête dans le message lui-même : c'est une valeur que le serveur associe au message dans sa base de données interne. C'est cette valeur que la plupart des clients mail utilisent pour trier les messages dans la boîte de réception.

La commande IMAP APPEND permet de déposer un message sur un serveur en spécifiant explicitement une INTERNALDATE. C'est une fonctionnalité légitime du protocole, documentée dans la RFC 3501. Les outils de migration l'utilisent constamment : imapsync, BitTitan MigrationWiz, CloudM, GSMMO... tous déposent des emails sur le serveur de destination avec une INTERNALDATE spécifiée.

Théoriquement, quelqu'un avec un accès IMAP à sa propre boîte mail pourrait déposer un email avec n'importe quelle INTERNALDATE. Mais cette manipulation ne modifie pas les en-têtes du message. Le Date: original reste intact, les Received: restent intacts, la signature DKIM reste intacte. Seule la métadonnée de tri côté serveur change.

Pour un expert qui examine le message brut, la discordance entre l'INTERNALDATE et le Date: est immédiatement visible. Et si le message est signé DKIM, la date originale est cryptographiquement attestée.

Le Message-ID : une empreinte difficilement falsifiable

Chaque email génère un identifiant unique, l'en-tête Message-ID:. Cet identifiant est construit par le serveur SMTP expéditeur au moment de l'envoi, en combinant généralement un timestamp, un identifiant aléatoire, et le nom de domaine du serveur.

Un Message-ID typique ressemble à ça : <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Le timestamp est souvent encodé directement dans l'identifiant. Modifier la date du message en laissant un Message-ID avec un timestamp incompatible crée une incohérence immédiatement repérable.

De plus, les Message-IDs sont indexés par les grands systèmes de messagerie. Google, Microsoft et d'autres acteurs maintiennent des logs qui permettent de retracer quand un message a réellement circulé sur leurs infrastructures. Dans un contexte légal ou forensique, ces logs sont accessibles via des procédures judiciaires.

En pratique : qui peut détecter une tentative de manipulation ?

Posons la question concrètement. Vous recevez un email dont vous suspectez que la date a été modifiée. Que peut faire un administrateur IT ou un avocat avec un minimum de bagage technique ?

• Vérification DKIM : dans Gmail, le menu "Afficher l'original" affiche directement le résultat de la vérification DKIM en haut de page. Un "PASS" confirme l'intégrité du message depuis l'envoi. Un "FAIL" ou un "SOFTFAIL" signale une altération.
• Analyse des en-têtes : des outils comme MXToolbox Header Analyzer ou le Google Admin Toolbox parsent automatiquement la chaîne des Received: et signalent les incohérences temporelles.
• Cohérence Message-ID / Date : un analyste peut comparer le timestamp encodé dans le Message-ID avec la valeur du Date: déclaré.
• Logs serveur : si l'email a transité par un serveur dont vous êtes administrateur, les logs SMTP contiennent la date et l'heure réelles d'acceptation du message, indépendamment de tout en-tête.

Bref, les outils de détection sont accessibles, gratuits, et ne nécessitent pas d'expertise forensique avancée. Un admin IT un peu curieux peut vérifier l'intégrité d'un email en moins de deux minutes.

Le seul cas légitime de modification massive de dates : la migration IMAP

Il existe un scénario où des centaines de milliers d'emails se retrouvent avec des dates incorrectes sans aucune intention malveillante : la migration IMAP.

Vous venez de terminer une migration de 150 boîtes Exchange vers Google Workspace. Lundi matin, les tickets arrivent. Les utilisateurs signalent que tous leurs anciens emails s'affichent avec la même date, celle du week-end de migration. Leurs boîtes de réception sont illisibles.

Ce qui s'est passé est documenté et prévisible : l'outil de migration (BitTitan, CloudM, imapsync, peu importe) a déposé les emails sur Google Workspace via IMAP APPEND. Il a spécifié une INTERNALDATE correspondant à la date de migration, pas à la date originale de l'email. Résultat : Outlook, qui trie par INTERNALDATE par défaut, affiche la date de migration pour tous les messages. Pourquoi les emails ont la mauvaise date après migration explique ce mécanisme en détail.

L'en-tête Date: original est intact dans chaque message. Les signatures DKIM sont intactes. Le contenu n'a pas bougé. C'est uniquement l'INTERNALDATE côté serveur qui est incorrecte.

Ce problème touche BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, et tous les outils qui utilisent IMAP APPEND sans préserver correctement l'INTERNALDATE. L'article dédié à BitTitan MigrationWiz couvre les particularités de cet outil. La checklist migration email liste les points à vérifier avant et après une migration pour éviter ce type de problème.

La différence entre corriger et falsifier

La correction que Redate.io effectue est à l'opposé d'une tentative de falsification. Le moteur de correction propriétaire analyse la chaîne d'en-têtes de chaque message, identifie la date originale encodée dans l'en-tête Date: (RFC 2822) qui n'a jamais bougé, et corrige les métadonnées de date pour les aligner avec cette information authentique déjà présente dans le message.

L'en-tête Date: est la source de vérité. Il a été écrit par le client mail de l'expéditeur au moment de l'envoi. Il est couvert par la signature DKIM. Il n'est pas modifié par Redate.io. Ce qui est corrigé, c'est la discordance introduite par l'outil de migration, pas la date originale.

Corriger 47000 emails après une migration ratée sans en perdre un seul, sans casser les fils de discussion, sans corrompre les pièces jointes, sans déclencher d'erreur 429 à 3h du matin sur l'API Google : c'est un pipeline d'analyse multi-étapes avec gestion des cas limites (S/MIME, PGP, encodages non-ASCII en RFC 2047, structures multipart complexes). Un script Python en cinq lignes ne survivrait pas à la première boîte de production. Peut-on corriger les dates des emails après migration détaille pourquoi le DIY est risqué sur des volumes réels.

Redate.io scanne les boîtes mail gratuitement, identifie les emails avec des dates incorrectes, et corrige via un pipeline de validation qui vérifie chaque message individuellement. Les originaux sont conservés dans un dossier de sauvegarde visible pendant 30 jours. Si quelque chose se passe mal, le rollback est possible.

Votre migration a décalé les dates de vos emails ? Lancez un scan gratuit sur Redate.io pour mesurer l'étendue du problème avant de décider quoi faire.