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

GSMMO en het datumprobleem waar niemand u 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 is 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-mail daadwerkelijk uploadt

GSMMO leest berichten uit het PST-bestand (of rechtstreeks uit het Outlook-profiel) en uploadt ze naar Gmail via de Gmail API (dat staat zo in Googles eigen release notes voor de tool). Hier ontstaat het datumprobleem, en het is de moeite waard om de werking te begrijpen, want dat verklaart waarom de oplossing niet zo eenvoudig is als "opnieuw importeren".

Wanneer GSMMO een bericht uploadt via de Gmail API, voegt Gmail een nieuwe Received:-header toe, gedateerd op het moment van de upload. En wanneer de oorspronkelijke datum niet wordt meegegeven met het bericht, wordt de INTERNALDATE, het tijdstempel dat Gmail intern gebruikt voor sortering en weergave, 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 die header bij de weergave en gebruikt in plaats daarvan de INTERNALDATE, die nu april 2026 zegt.

GSMMO versus migratietools voor beheerders

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 uploadt e-mails via de Gmail API. De gebruiker heeft een Google Workspace-account nodig en de GSMMO-plugin geïnstalleerd in Outlook. Het is een clientside tool.

Google Workspace Migration Service (de tool in de beheerconsole) werkt aan serverzijde. Een beheerder configureert deze in de Google Admin Console, wijst hem 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 hij de INTERNALDATE kan instellen op basis van de bronmetadata. Maar "iets beter" is niet hetzelfde als "altijd goed", en veel beheerders melden hetzelfde datumprobleem ook met deze tool.

Het belangrijkste verschil? Bij GSMMO is er geen intelligentie aan serverzijde die beslist over het behoud van de datum. Elk bericht dat de tool uploadt krijgt dezelfde behandeling, of het nu een verse e-mail is of een 10 jaar oud archiefbericht: een Received:-header gedateerd op de dag van de upload. Punt.

Waarom GSMMO's datumbehoud niet werkt

Als u de instellingen van GSMMO hebt bekeken, is u misschien opgevallen dat er geen optie "datums behouden" bestaat. Dat is geen vergissing. GSMMO is afhankelijk van hoe Gmail berichten behandelt die via zijn API worden geüpload, en kan dat niet omzeilen.

Dit is de technische keten van gebeurtenissen:

1. GSMMO leest het bericht uit het PST-bestand, met inbegrip van de originele tijdstempels
2. GSMMO uploadt de berichtgegevens via de Gmail API
3. Gmail ontvangt de upload en slaat het bericht op in de mailbox
4. Gmail voegt een nieuwe Received:-header toe, gedateerd op het moment van de upload (de regel met gmailapi.google.com in het voorbeeld hierboven)
5. Wanneer de oorspronkelijke datum niet wordt meegegeven, stelt Gmail de INTERNALDATE in op het uploadtijdstip
6. Het bericht belandt in Gmail met de datum van vandaag

Stappen 4 en 5 zijn doorslaggevend. Gmail voegt die header toe aan elk bericht dat via zijn API wordt geüpload, wat de tool ook meestuurt, en GSMMO heeft geen instelling om de oorspronkelijke datum door te geven of te behouden. Het resultaat: al uw historische e-mails lijken alsof ze vandaag zijn binnengekomen.

Sommige beheerders hebben geprobeerd GSMMO uit te voeren met specifieke Google Workspace-instellingen ingeschakeld of het GSMMO-profiel aan te passen. Niets daarvan beïnvloedt het datumgedrag. De Received:-header wordt aan de kant van Google toegevoegd, en geen configuratie aan clientzijde verandert dat.

Specifieke GSMMO-scenario's waarbij de datums verkeerd worden

Niet elke GSMMO-migratie eindigt in datumchaos, maar de meeste wel. Dit zijn de gevallen waar het om gaat:

• PST-bestand naar Gmail: de datums kloppen niet meer. Dit is het meest voorkomende gebruiksscenario van GSMMO en het meest getroffen.
• Outlook-profiel naar Gmail: de datums kloppen niet meer. Dezelfde upload via de Gmail API als bij de PST-import.
• Exchange Online (Microsoft 365) naar Gmail via GSMMO: de datums kloppen niet meer. GSMMO leest van de Exchange-server en uploadt via de Gmail API.
• On-premises Exchange naar Gmail via GSMMO: de datums kloppen niet meer. Hetzelfde mechanisme.
• Gmail naar Gmail (herimport van een PST-export): de datums kloppen niet meer. Zelfs als de originele e-mails correcte datums hadden in de PST, krijgen ze bij de herimport een nieuw tijdstempel.

Het patroon is duidelijk. Elk bericht dat via de Gmail API wordt geüpload, krijgt een Received:-header gedateerd op de dag van de upload. GSMMO gebruikt altijd dit pad.

Wat dit bijzonder frustrerend maakt: het migratierapport van GSMMO toont alles als geslaagd. Geen waarschuwingen over datums, geen fouten, geen signalen. U zou de 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 verder dan sorteren

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

Stel dat u accountant bent en net gemigreerd naar Google Workspace. U moet alle correspondentie met klanten 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 dat u de juiste termen nog weet.

Voor gereguleerde sectoren is dit erger dan lastig. E-mailtijdstempels dienen als juridisch bewijs. Een financieel adviseur die moet aantonen dat hij een openbaarmaking heeft verstuurd vóór een transactiedatum, kan dat niet wanneer de e-mail april 2026 toont in plaats van februari 2023. Compliance-audits onder SOX of HIPAA steunen op nauwkeurige tijdstempels van communicatie, en verkeerde datums betekenen mislukte audits.

En dan is er nog het threadingprobleem. Gmail groepeert conversaties op datum en onderwerp. Wanneer elk bericht in een thread dezelfde datum toont, wordt de conversatieweergave rommelig. Antwoorden verschijnen vóór het originele bericht. De hele threadstructuur stort in tot een stapel 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 staat er, maar wordt genegeerd door Gmails weergavelogica, omdat de INTERNALDATE en de bovenste Received-header naar de migratiedatum wijzen.

Redate.io maakt verbinding met de Google Workspace-mailbox, scant op e-mails die getroffen zijn door de GSMMO-migratie, en herstelt de datummetadata met een eigen engine voor headerketenanalyse en datumreconstructie. Redate hoeft niet te weten welke tool de migratie heeft uitgevoerd: het vindt de e-mails waarvan de weergegeven datum niet overeenkomt met de oorspronkelijke datum, en herstelt ze zonder de berichtinhoud, bijlagen of threading te wijzigen.

Elke herstelde e-mail doorloopt individuele verificatie: berichtintegriteit, behoud van bijlagen, labeltoewijzing en threadconsistentie. Originelen blijven zichtbaar in een back-upmap Redate.io - Originals van uw eigen mailbox, tot u ze zelf verwijdert.

Zou u dit zelf met een script kunnen oplossen? Het probleem begrijpen is één ding. 12.000 e-mails herstellen 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-grens, die GSMMO heeft geïmporteerd maar amper bij elkaar hield? Hoe verifieert u dat elk afzonderlijk bericht intact is aangekomen? Eerlijk gezegd, een script dat werkt op 20 testberichten in een lab overleeft geen echte mailbox met 8 jaar correspondentie.

Platformspecifieke handleidingen voor GSMMO

Omdat GSMMO specifiek naar Google Workspace migreert, vindt het herstel plaats op het niveau van Gmail. 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 verliest zijn waarde niet in de loop van de tijd. Redate.io kan e-mails die door GSMMO zijn getroffen herstellen, of de migratie nu vorige week plaatsvond of drie jaar geleden.

Heeft de GSMMO-migratie uw e-mails met verkeerde datums achtergelaten? Start een gratis analyse om het exacte aantal getroffen e-mails en de kosten van het herstel te zien, voordat u zich ergens aan verbindt.