GSMMO heeft uw e-maildatums gewijzigd? Zo herstelt u ze

GSMMO en het datumprobleem waar niemand voor waarschuwt

Google Workspace Migration for Microsoft Outlook (GSMMO) is de desktoptool die Google aanbiedt om PST-bestanden, Outlook-profielen en lokale e-mailarchieven naar Gmail te migreren. Het is gratis, officieel ondersteund, en het migratiepad dat Google aanbeveelt wanneer u een klein team of een paar individuele mailboxen verplaatst van Outlook naar Google Workspace.

De tool werkt. E-mails komen aan in Gmail, de mappenstructuur wordt omgezet in labels, contacten worden overgedragen. Maar open Gmail daarna en sorteer op datum. Elke e-mail toont de datum van vandaag. Dat voorstel dat u in januari 2021 verstuurde? April 2026. De factuur van uw accountant van maart 2023? Ook april 2026.

GSMMO waarschuwt niet dat dit gaat gebeuren. Het migratielogboek toont succes voor elk bericht. Googles eigen documentatie vermeldt het niet als bekende beperking. U ontdekt het pas wanneer iemand een oud bericht zoekt op datumbereik en nul resultaten krijgt.

Hoe GSMMO uw e-mails daadwerkelijk uploadt

GSMMO leest berichten uit het PST-bestand (of rechtstreeks uit het Outlook-profiel) en uploadt ze naar Gmail via Googles IMAP-gateway. Hier ontstaat het datumprobleem, en het is de moeite waard om de werking te begrijpen omdat het verklaart waarom de oplossing niet zo eenvoudig is als "opnieuw importeren".

Wanneer GSMMO een bericht uploadt, behandelt Gmails IMAP-gateway het als een zojuist binnengekomen e-mail. Gmail stempelt het bericht met een nieuwe Received:-header die het huidige tijdstempel bevat. De INTERNALDATE, het tijdstempel dat Gmail intern gebruikt voor sortering en weergave, wordt ingesteld op het moment van uploaden in plaats van de oorspronkelijke verzenddatum.

Zo ziet de headerketen eruit na een GSMMO-migratie:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Ziet u die originele Date:-header van september 2019? Die staat er nog, ongewijzigd. GSMMO wijzigt de berichtinhoud of originele headers niet. Maar Gmail negeert het voor de weergave en gebruikt in plaats daarvan de INTERNALDATE, die nu april 2026 zegt.

GSMMO vs. beheerder-migratietools

Hier begint de verwarring vaak. Google heeft meerdere migratietools, en die gedragen zich niet allemaal hetzelfde.

GSMMO (de desktopapp) draait op de computer van de gebruiker. Het leest vanuit Outlook of een PST-bestand en stuurt e-mails via Googles IMAP-interface. De gebruiker heeft een Google Workspace-account nodig en de GSMMO-plugin geinstalleerd in Outlook. Het is een clientside tool, wat betekent dat Googles servers inkomende berichten zien, geen gemigreerde berichten.

Google Workspace Migration Service (de beheerconsoletool) werkt serverside. Een beheerder configureert het in de Google Admin Console, verwijst het naar een Exchange-server of een andere Google Workspace-tenant, en de migratie draait in Googles infrastructuur. Deze tool gaat in sommige configuraties iets beter om met datums omdat het de INTERNALDATE kan instellen op basis van de bronmetadata. Maar "iets beter" betekent niet "betrouwbaar", en veel beheerders melden hetzelfde datumprobleem ook met deze tool.

Het belangrijkste verschil? Bij GSMMO is er geen serverside intelligentie voor datumbehoud. De IMAP-gateway behandelt elk geupload bericht identiek, of het nu een verse e-mail is of een 10 jaar oud archiefbericht. Het stempelt de huidige datum. Punt.

Waarom GSMMO's datumbehoud niet werkt

Als u de GSMMO-instellingen hebt bekeken, is u misschien opgevallen dat er geen optie "datums behouden" bestaat. Dat is geen vergissing. GSMMO vertrouwt op het gedrag van Gmails IMAP-gateway voor datumafhandeling en kan het niet overschrijven.

De technische keten van gebeurtenissen:

1. GSMMO leest het bericht uit het PST-bestand, inclusief de originele tijdstempels
2. GSMMO verbindt met Gmail via IMAP en stuurt een APPEND-commando met de berichtgegevens
3. Gmails IMAP-gateway ontvangt het APPEND en verwerkt het via de interne transportpipeline
4. De transportpipeline voegt een nieuwe Received:-header toe met de huidige datum
5. Gmail stelt de INTERNALDATE in op het uploadtijdstempel
6. Het bericht belandt in Gmail met de datum van vandaag

Stap 3 is de beslissende. Hoewel het IMAP APPEND-protocol technisch het instellen van een aangepaste INTERNALDATE ondersteunt, respecteert Gmails implementatie dit niet altijd, vooral niet via het GSMMO-pad. Het resultaat: al uw historische e-mails zien eruit alsof ze vandaag zijn binnengekomen.

Sommige beheerders hebben geprobeerd GSMMO uit te voeren met specifieke Google Workspace-instellingen of aangepaste GSMMO-profielparameters. Niets daarvan beinvloedt het datumgedrag. De datum wordt serverside gestempeld, en geen clientside configuratie verandert dat.

GSMMO-scenario's die datums beschadigen

Niet elke GSMMO-migratie eindigt in datumchaos, maar de meeste wel. Dit zijn de getroffen gevallen:

• PST-bestand naar Gmail: Datums worden beschadigd. Dit is het meest voorkomende GSMMO-gebruiksscenario en het meest getroffen.
• Outlook-profiel naar Gmail: Datums worden beschadigd. Hetzelfde IMAP-gatewaygedrag als bij PST-import.
• Exchange Online (Microsoft 365) naar Gmail via GSMMO: Datums worden beschadigd. GSMMO leest van de Exchange-server en uploadt via Gmails IMAP-gateway.
• On-premises Exchange naar Gmail via GSMMO: Datums worden beschadigd. Hetzelfde mechanisme.
• Gmail naar Gmail (herimport van PST-export): Datums worden beschadigd. Zelfs als de originele e-mails correcte datums hadden in het PST, worden ze bij herimport opnieuw gestempeld.

Het patroon is duidelijk. Elk pad dat via Gmails IMAP-gateway loopt tijdens het uploaden, overschrijft de datums. GSMMO gebruikt altijd dit pad.

Wat dit bijzonder frustrerend maakt: het GSMMO-migratierapport toont alles als geslaagd. Geen waarschuwingen over datums, geen fouten, geen signalen. U zou tijdstempels voor en na de migratie handmatig moeten vergelijken om het te ontdekken, en de meeste beheerders doen dat pas wanneer een gebruiker klaagt.

De impact gaat ver voorbij sorteren

Verkeerde datums na een GSMMO-migratie veroorzaken echte problemen die verder gaan dan een rommelige inbox.

Stel u bent accountant en net gemigreerd naar Google Workspace. U moet alle clientcorrespondentie uit Q3 2024 vinden voor een belastingaangifte. U zoekt in Gmail op datumbereik: juli tot september 2024. Nul resultaten. Elke e-mail uit die periode toont nu de migratiedatum, dus Gmails datumfilter kan ze niet vinden. U zit vast aan het scrollen door duizenden berichten of het zoeken op trefwoord in de hoop de juiste termen te herinneren.

Voor gereguleerde sectoren is dit erger dan vervelend. E-mailtijdstempels dienen als juridisch bewijs. Een financieel adviseur die moet bewijzen een openbaarmaking te hebben verstuurd voor een transactiedatum kan dat niet wanneer de e-mail april 2026 toont in plaats van februari 2023. Compliance-audits onder de AVG vertrouwen op nauwkeurige communicatietijdstempels, en verkeerde datums betekenen mislukte audits.

En dan is er het threadingprobleem. Gmail groepeert conversaties op datum en onderwerp. Wanneer elk bericht in een thread dezelfde datum toont, wordt de conversatieweergave chaotisch. Antwoorden verschijnen voor het originele bericht. De hele threadstructuur stort in tot een hoop identiek gedateerde e-mails.

GSMMO-datums herstellen met Redate.io

Het goede nieuws: die originele Date:-header zit nog intact in elke gemigreerde e-mail. GSMMO wijzigt de berichtinhoud niet. De juiste datum is er, maar wordt genegeerd door Gmails weergavelogica omdat de INTERNALDATE en de bovenste Received-header naar de migratiedatum wijzen.

Redate.io verbindt met de Google Workspace-mailbox, scant op e-mails die getroffen zijn door de GSMMO-migratie, en corrigeert de datummetadata via een eigen engine voor headerketenanalyse en datumreconstructie. De correctie herkent GSMMO-specifieke patronen in de Received-headerketen (de gmailapi.google.com-signatuur en lokale IMAP-gateway-identificatoren) en voert gerichte metadatacorrectie uit zonder berichtinhoud, bijlagen of threading te wijzigen.

Elke gecorrigeerde e-mail doorloopt individuele verificatie: berichtintegriteit, behoud van bijlagen, labeltoewijzing en threadconsistentie. Originelen blijven 30 dagen in een zichtbare map Redate.io - Originals.

Zou u dit zelf met een script kunnen oplossen? Het probleem begrijpen is een ding. 12.000 e-mails corrigeren zonder S/MIME-handtekeningen te breken, geneste MIME-delen te beschadigen of RFC 2047-gecodeerde headers in een productiemailbox te vernielen is iets heel anders. Hoe gaat u om met de e-mail met een bijlage van 38 MB en een beschadigde MIME-boundary die GSMMO heeft geimporteerd maar amper bij elkaar hield? Eerlijk gezegd, een script dat werkt op 20 testberichten in een lab overleeft geen echte mailbox met 8 jaar correspondentie.

Platformspecifieke handleidingen voor GSMMO

Aangezien GSMMO specifiek naar Google Workspace migreert, vindt de correctie plaats op Gmail-niveau. Maar de getroffen e-mails zijn zichtbaar in elke client die verbonden is met dat Gmail-account:

• GSMMO-migratiedatums in Gmail herstellen
• GSMMO-migratiedatums in Outlook herstellen (verbonden met Google Workspace)
• GSMMO-migratiedatums in Apple Mail herstellen

Al maanden geleden gemigreerd? De originele Date-header degradeert niet in de loop van de tijd. Redate.io kan GSMMO-getroffen e-mails corrigeren ongeacht of de migratie vorige week plaatsvond of drie jaar geleden.

GSMMO-migratie heeft uw e-mails met verkeerde datums achtergelaten? Start een gratis scan om het exacte aantal getroffen e-mails en de correctiekosten te zien, voordat u zich vastlegt.