De datum van een ontvangen e-mail wijzigen: wat kan en wat niet?

Een e-mail heeft drie "datums". Niet één.

Wanneer mensen het hebben over "de ontvangstdatum van een e-mail wijzigen", stellen ze zich voor dat ze ergens een veld aanpassen, zoals de aanmaakdatum van een bestand in Windows. De werkelijkheid is iets ingewikkelder. Een e-mail bevat eigenlijk drie aparte datumlagen, elk met eigen regels, eigen beheerders, en eigen gevolgen als je er aan komt.

Die drie lagen begrijpen betekent begrijpen waarom sommige correcties technisch verantwoord zijn, en andere onmogelijk, of onmiddellijk detecteerbaar als vervalsing.

Laag 1: de IMAP INTERNALDATE

De INTERNALDATE is een metadataveld dat server-side wordt opgeslagen, buiten het bericht zelf. Het maakt geen deel uit van de e-mailinhoud. De IMAP-server stelt de waarde in, en het is dit veld dat de meeste e-mailclients gebruiken om berichten in de lijst te sorteren.

Outlook toont standaard berichten gesorteerd op INTERNALDATE. Gmail doet dit ook, in bepaalde contexten. Als uw INTERNALDATE dus onjuist is, lijken al uw e-mails dezelfde datum te hebben in de interface, ongeacht wat de interne headers van het bericht zeggen.

De INTERNALDATE wordt ingesteld op het moment dat het bericht op de server wordt geplaatst. Via het IMAP-protocol is de enige manier om hem te "wijzigen" indirect: u moet de opdracht APPEND gebruiken om een nieuwe kopie van het bericht te plaatsen met de gewenste datum. Er bestaat geen IMAP-opdracht SETINTERNALDATE. Dit detail wordt zo meteen belangrijk.

Laag 2: de Date:-header (RFC 2822)

Dit is het veld Date: in de ruwe headers van het bericht. Het wordt ingesteld door de e-mailclient op het moment van verzending, en reist mee met het bericht van server naar server. Het is de verzenddatum zoals opgegeven door de afzender.

(Als u trouwens nog nooit de ruwe headers van een e-mail hebt bekeken: het is best ontnuchterend. Elk bericht sleept zo'n twintig technische regels mee die 99% van de mensen nooit heeft gezien.)

Technisch gezien staat niets een afzender in de weg om een e-mail te versturen met een geantedateerd of postgedateerd Date:-veld. SMTP-servers valideren dit veld niet. Maar de ontvangende servers noteren het werkelijke aankomsttijdstip in de Received:-headers, wat onmiddellijk een inconsistentie oplevert die zichtbaar is voor elke e-mailclient of analyseprogramma.

Laag 3: de gestapelde Received:-headers

Elke keer dat een SMTP-server een bericht doorstuurt, voegt hij bovenaan de stapel een Received:-header toe met een tijdstempel. Een e-mail die via drie servers is gegaan, heeft drie Received:-headers. Ze worden van onder naar boven gelezen: de oudste staat onderaan, de nieuwste bovenaan.

Precies hier creëren migratietools het probleem. Wanneer BitTitan MigrationWiz, CloudM, imapsync of GSMMO een e-mail migreren, plaatsen ze hem via IMAP opnieuw op de nieuwe server. Die plaatsing genereert een nieuwe Received:-header met het tijdstempel van de migratie. Gevolg: de oudste e-mail in uw mailbox, een bericht uit 2019, heeft plotseling een Received: gedateerd november 2024. En omdat sommige e-mailclients (Outlook voorop) de meest recente Received: gebruiken als weergavedatum...

Daar is het probleem. 15.000 e-mails tonen allemaal dezelfde migratiedatum.

Kunt u deze datums echt "wijzigen"?

Technisch gezien: ja voor de INTERNALDATE (met beperkingen). Technisch mogelijk maar zinloos voor de Date:-header. En voor de Received:-headers verdient het een nadere blik.

Een Received:-header herschrijven is eenvoudig. En onmiddellijk detecteerbaar.

Een Received:-header is niets meer dan een tekstregel in het bericht. U kunt hem bewerken zoals elk tekstbestand. Zo simpel is het inderdaad.

Maar dan komt het.

Eerste probleem: DKIM. De DKIM-handtekening (DomainKeys Identified Mail) wordt berekend over een reeks berichtheaders, soms inclusief de Received:-headers. Een ondertekende header wijzigen maakt de handtekening ongeldig. Elke ontvangende server die DKIM verifieert, ziet onmiddellijk dat het bericht is gewijzigd. Dat is geen subtiele vervalsing, dat is een alarm.

Tweede probleem: interne identifiers. Moderne mailservers (Google Workspace, Microsoft 365) kennen elk bericht een oplopende, unieke interne identifier toe. Die identifiers zijn gekoppeld aan de INTERNALDATE en de ontvangstvolgorde. Een Received:-header wijzigen zonder samenhang met die identifiers creëert inconsistenties die audittools moeiteloos detecteren.

Derde probleem, meer praktisch: zelfs als u de Received:-header in de berichtinhoud aanpast, hebt u de INTERNALDATE niet aangeraakt, die nog steeds die van de IMAP-plaatsing is. De e-mailclient blijft de verkeerde datum tonen bij het sorteren. U hebt het bericht voor niets gewijzigd.

Kortom. Received:-headers herschrijven om een e-maildatum kwaadwillig te vervalsen: technisch triviaal, detecteerbaar in enkele seconden door een expert. Dat is geen serieuze aanpak.

De Date:-header: het verleden op papier veranderen

Dezelfde redenering geldt voor de Date:-header. U kunt hem aanpassen in de berichtinhoud. Maar de Received:-headers die door tussenliggende servers zijn geverifieerd, blijven intact en vertellen een ander verhaal. De tijdlijn klopt niet meer. Elke analist of rechtbank die deze velden vergelijkt, ziet dat onmiddellijk.

Om precies te zijn: sommige e-mailclients tonen de gewijzigde Date:-header wel als ze direct een .eml-bestand openen. Maar in de context van een live mailserver, met authenticatie en logbestanden, is de wijziging volledig transparant.

IMAP-migratie: de enige context waar datumcorrectie zinvol is

Er is één situatie, en slechts één, waarbij het aanpassen van de ontvangstdatum van een e-mail niet alleen mogelijk maar ook technisch gerechtvaardigd is: het herstellen van schade veroorzaakt door een slecht uitgevoerde IMAP-migratie.

De concrete situatie. U hebt net 80 Exchange-mailboxen gemigreerd naar Microsoft 365. De migratie was vrijdagavond afgerond. Maandagochtend komen de eerste tickets binnen: "Al mijn e-mails hebben dezelfde datum", "Ik kan een e-mail van vorig jaar niet meer terugvinden", "Mijn berichtengeschiedenis met die klant is volledig kapot". U hebt 80 geblokkeerde gebruikers en een manager die op een antwoord wacht.

In die context is het probleem gedocumenteerd, identificeerbaar, en de oorzaak is duidelijk: de migratietool heeft een Received:-header toegevoegd gedateerd op de migratiedag, en sommige e-mailclients gebruiken die nieuwe header als weergavedatum. De originele Date:-header staat echter intact in elk bericht. Die is nooit gewijzigd. Hij bevat nog steeds de correcte originele verzenddatum.

De correctie is dus geen vervalsing: het is een herstelactie. U vertrekt van echte gegevens (de originele Date:-header) om consistente metadata te reconstrueren. Dat is fundamenteel anders dan proberen een e-mail uit 2024 te laten doorgaan voor een bericht uit 2019.

Voor meer details over de specifieke mechanismen per tool vindt u concrete gevallen in deze gidsen: BitTitan-datums herstellen in Microsoft 365, CloudM-datums herstellen in Outlook, of imapsync-datums herstellen in Google Workspace.

Waarom zelf een script schrijven riskant is

De basislogica is toegankelijk. Elke IT-beheerder die tijd heeft doorgebracht op IMAP-forums kan de algemene aanpak reconstrueren. Dat is niet het probleem.

Het probleem is de kloof tussen een script dat werkt op 50 teste-mails en een script dat 40.000 berichten in productie verwerkt zonder één e-mail te verliezen, zonder één bijlage te beschadigen, en zonder één conversatiedraad te breken.

Enkele concrete gevallen die zelfgemaakte scripts doorgaans niet afhandelen:

• S/MIME-ondertekende e-mails: de handtekening beslaat de inhoud en headers. Elke wijziging van de berichtstructuur maakt de handtekening ongeldig. Een slecht gecorrigeerde ondertekende e-mail komt aan als "ongeldige handtekening" bij de ontvanger.
• PGP-versleutelde berichten: dezelfde familie van problemen, met mogelijk ernstigere gevolgen afhankelijk van de implementatie.
• Niet-ASCII-codering in headers: RFC 2047 beschrijft de codering van speciale tekens in headers. Een script dat headers manipuleert zonder deze gevallen te behandelen, beschadigt stilzwijgend e-mailonderwerpen met accenten, Japanse tekens of Arabische namen.
• API-tarieflimieten: Google Workspace en Microsoft 365 implementeren agressieve throttling. Om 3 uur 's nachts levert een batch van 10.000 e-mails die een 429 Too Many Requests-fout tegenkomt zonder exponentieel backoff een situatie op waarbij de helft van de mailboxen half gecorrigeerd is.
• Beschadigde MIME-grenzen: multipart-berichten met bijlagen hebben precieze MIME-grenzen. Ze incorrect regenereren maakt bijlagen onleesbaar.

En de vraag die geen enkel zelfgemaakt script oplost: hoe verifieert u dat elke gecorrigeerde e-mail intact is? Een script dat 40.000 berichten wijzigt zonder individuele verificatie is een gok. Een gok op gegevens die gebruikers vaak als onvervangbaar beschouwen.

Een artikel over de beschikbare opties voor het herstellen van datums na migratie bespreekt de verschillende aanpakken, inclusief hun respectieve beperkingen.

Wat Redate.io doet in deze context

Redate.io is specifiek ontworpen voor dit geval: door IMAP-migratie beschadigde datums herstellen, op grote schaal, zonder risico voor de integriteit van de berichten.

De service maakt rechtstreeks verbinding met de getroffen mailboxen (Google Workspace via domeindelegatie, Microsoft 365 via Azure AD, of directe IMAP), scant gratis berichten met onjuiste datums, en past vervolgens een eigen correctiepipeline toe die de hierboven beschreven grensgevallen verwerkt. Elk e-mailbericht wordt na correctie individueel geverifieerd. De originelen blijven 30 dagen zichtbaar in een back-upmap.

De patroonherkenning dekt honderden handtekeningen van bekende migratietools: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, en hun varianten. De detectie is nauwkeurig: Redate.io raakt e-mails met correcte datums niet aan.

Het tariefmodel is eenvoudig: eenmalige betaling per mailbox, zonder abonnement. De diagnostische scan is gratis, zodat u de omvang van de schade kunt meten voordat u een beslissing neemt.

Als u mailboxen beheert die door dit probleem zijn getroffen, beschrijft dit artikel over verkeerde datums in Outlook na migratie de meest voorkomende symptomen en hoe u ze onderscheidt van andere oorzaken.

Wilt u de omvang van het probleem in uw mailboxen meten? Start een gratis scan op Redate.io en zie precies hoeveel e-mails zijn getroffen, voor u ook maar iets corrigeert.