GSMMO ändrade dina e-postdatum? Så fixar du det

GSMMO och datumproblemet som ingen varnar dig för

Google Workspace Migration for Microsoft Outlook (GSMMO) är skrivbordsverktyget som Google tillhandahåller för att migrera PST-filer, Outlook-profiler och lokala e-postarkiv till Gmail. Det är gratis, officiellt stött, och det är den migreringsväg Google rekommenderar när du flyttar ett litet team eller några enskilda e-postlådor från Outlook till Google Workspace.

Verktyget fungerar. E-postmeddelanden anländer i Gmail, mappstrukturen omvandlas till etiketter, kontakter förs över. Men öppna Gmail efteråt och sortera efter datum. Varje e-postmeddelande visar dagens datum. Det förslaget du skickade i januari 2021? April 2026. Fakturan från din revisor i mars 2023? Också april 2026.

GSMMO varnar dig inte för att detta kommer att hända. Migreringsloggen visar lyckat resultat för varje meddelande. Googles egen dokumentation nämner det inte som en känd begränsning. Du upptäcker det först när någon söker efter ett gammalt e-postmeddelande utifrån ett datumintervall och får noll resultat.

Så laddar GSMMO faktiskt upp din e-post

GSMMO läser meddelanden från PST-filen (eller direkt från Outlook-profilen) och laddar upp dem till Gmail via Gmail API (Googles egna versionsanteckningar för verktyget bekräftar det). Det är här datumproblemet uppstår, och det är värt att förstå mekaniken eftersom den förklarar varför lösningen inte är så enkel som att "bara importera igen".

När GSMMO laddar upp ett meddelande via Gmail API lägger Gmail till en ny Received:-header daterad till uppladdningsögonblicket. Och när det ursprungliga datumet inte skickas med meddelandet sätts INTERNALDATE, tidsstämpeln som Gmail använder internt för sortering och visning, till uppladdningsögonblicket i stället för det ursprungliga sändedatumet.

Så här ser headerkedjan ut efter en GSMMO-migrering:

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

Ser du den ursprungliga Date:-headern från september 2019? Den finns kvar, orörd. GSMMO ändrar inte meddelandets innehåll eller ursprungliga headrar. Men Gmail bortser från den vid visning och använder INTERNALDATE i stället, som nu säger april 2026.

GSMMO jämfört med administratörens migreringsverktyg

Här börjar förvirringen ofta. Google har flera migreringsverktyg, och de beter sig inte likadant.

GSMMO (skrivbordsappen) körs på användarens dator. Den läser från Outlook eller en PST-fil och laddar upp e-post via Gmail API. Användaren behöver ett Google Workspace-konto och GSMMO-tillägget installerat i Outlook. Det är ett klientsidesverktyg.

Google Workspace Migration Service (verktyget i administratörskonsolen) är serversidigt. En administratör konfigurerar det i Google Admin-konsolen, pekar det mot en Exchange-server eller en annan Google Workspace-organisation, och migreringen körs i Googles infrastruktur. Det här verktyget hanterar datum något bättre i vissa konfigurationer eftersom det kan sätta INTERNALDATE baserat på källmetadata. Men "något bättre" betyder inte "pålitligt", och många administratörer rapporterar samma datumproblem även med det verktyget.

Den avgörande skillnaden? Med GSMMO finns ingen serversidig intelligens som fattar beslut om datumbevarande. Varje meddelande det laddar upp får samma behandling, oavsett om det är ett färskt e-postmeddelande eller ett tio år gammalt arkiverat meddelande: en Received:-header daterad till uppladdningsdagen. Punkt.

Varför GSMMO:s datumbevarande inte fungerar

Om du har tittat på GSMMO:s inställningar har du kanske märkt att det inte finns något alternativ för att "bevara datum". Det är inget förbiseende. GSMMO förlitar sig på hur Gmail hanterar meddelanden som laddas upp via dess API, och det kan inte åsidosätta det.

Här är den tekniska händelsekedjan:

1. GSMMO läser meddelandet från PST-filen, inklusive dess ursprungliga tidsstämplar
2. GSMMO laddar upp meddelandedata via Gmail API
3. Gmail tar emot uppladdningen och lagrar meddelandet i e-postlådan
4. Gmail lägger till en ny Received:-header daterad till uppladdningsögonblicket (raden gmailapi.google.com i exemplet ovan)
5. När det ursprungliga datumet inte skickas med sätter Gmail INTERNALDATE till uppladdningstidsstämpeln
6. Meddelandet hamnar i Gmail med dagens datum

Steg 4 och 5 är de avgörande. Gmail lägger till den headern på varje meddelande som laddas upp via dess API, oavsett vad verktyget skickar, och GSMMO har ingen inställning för att skicka med eller behålla det ursprungliga datumet. Resultatet är att all din historiska e-post ser ut att ha anlänt idag.

Vissa administratörer har försökt köra GSMMO med specifika Google Workspace-inställningar aktiverade eller justerat GSMMO-profilinställningarna. Inget av detta påverkar datumbeteendet. Received:-headern läggs till på Googles sida, och ingen klientsidig konfiguration ändrar det.

Specifika GSMMO-scenarier som förstör datum

Inte varje GSMMO-migrering slutar i datumkaos, men de flesta gör det. Här är fallen som drabbas:

• PST-fil till Gmail: Datum förstörs. Detta är det vanligaste GSMMO-användningsfallet och det mest drabbade.
• Outlook-profil till Gmail: Datum förstörs. Samma uppladdning via Gmail API som vid PST-importen.
• Exchange Online (Microsoft 365) till Gmail via GSMMO: Datum förstörs. GSMMO läser från Exchange-servern och laddar upp via Gmail API.
• Lokal Exchange till Gmail via GSMMO: Datum förstörs. Samma mekanism.
• Gmail till Gmail (återimport av PST-export): Datum förstörs. Även om de ursprungliga e-postmeddelandena hade korrekta datum i PST-filen stämplar återimporten om dem.

Mönstret är tydligt. Varje meddelande som laddas upp via Gmail API får en Received:-header daterad till uppladdningsdagen. GSMMO använder alltid den här vägen.

Det som gör det här särskilt frustrerande är att GSMMO:s migreringsrapport visar allt som lyckat. Inga varningar om datum, inga fel, inga flaggor. Du skulle behöva jämföra tidsstämplar manuellt före och efter migreringen för att upptäcka det, och de flesta administratörer gör inte det förrän en användare klagar.

Konsekvenserna sträcker sig långt bortom sortering

Fel datum efter en GSMMO-migrering skapar verkliga problem som går längre än en rörig inkorg.

Föreställ dig att du är revisor och just har flyttat till Google Workspace. Du behöver hitta all klientkorrespondens från Q3 2024 inför en skattedeklaration. Du söker i Gmail efter datumintervall: juli till september 2024. Noll resultat. Varje e-postmeddelande från den perioden visar nu migreringsdatumet, så Gmails datumfilter kan inte hitta dem. Du sitter fast och bläddrar genom tusentals meddelanden eller söker på nyckelord och hoppas att du minns rätt termer.

För reglerade branscher är det värre än opraktiskt. E-posttidsstämplar fungerar som juridiska bevis. En finansiell rådgivare som behöver bevisa att en upplysning skickades före ett transaktionsdatum kan inte göra det när e-postmeddelandet visar april 2026 istället för februari 2023. Efterlevnadsgranskningar enligt SOX eller HIPAA förlitar sig på korrekta kommunikationstidsstämplar, och fel datum innebär underkända granskningar.

Och sedan finns trådproblemet. Gmail grupperar konversationer efter datum och ämne. När varje meddelande i en tråd visar samma datum blir konversationsvyn rörig. Svar visas före det ursprungliga meddelandet. Hela trådstrukturen kollapsar till en hög identiskt daterade e-postmeddelanden.

Fixa GSMMO-datum med Redate.io

De goda nyheterna: den ursprungliga Date:-headern är fortfarande intakt i varje migrerat e-postmeddelande. GSMMO ändrar inte meddelandeinnehållet. Det korrekta datumet finns där, det ignoreras bara av Gmails visningslogik eftersom INTERNALDATE och den översta Received-headern pekar på migreringsdatumet.

Redate.io ansluter till e-postlådan i Google Workspace, genomsöker efter e-postmeddelanden som påverkats av GSMMO-migreringen, och fixar datummetadata med en egenutvecklad motor för headerkedjeanalys och datumrekonstruktion. Redate behöver inte veta vilket verktyg som utförde migreringen: det hittar de e-postmeddelanden vars visade datum inte stämmer med deras ursprungliga datum, och fixar dem utan att ändra meddelandeinnehåll, bilagor eller trådstruktur.

Varje fixat e-postmeddelande genomgår individuell verifiering: meddelandeintegritet, bevarande av bilagor, etikettmappning och trådkonsekvens. Originalen ligger kvar i en synlig säkerhetskopiemapp med namnet Redate.io - Originals i din egen e-postlåda tills du själv tar bort dem.

Skulle du kunna fixa detta själv med ett skript? Att förstå problemet är en sak. Att fixa 12 000 e-postmeddelanden utan att bryta S/MIME-signaturer, skada nästlade MIME-delar eller förstöra RFC 2047-kodade headrar i en e-postlåda i drift är något helt annat. Hur hanterar du e-postmeddelandet med en bilaga på 38 MB och en skadad MIME-gräns som GSMMO importerade men knappt höll ihop? Hur verifierar du att varje enda meddelande kom igenom intakt? Ett skript som fungerar på 20 testmeddelanden i ett labb överlever inte en verklig e-postlåda med 8 års korrespondens.

Plattformsspecifika guider för GSMMO

Eftersom GSMMO migrerar specifikt till Google Workspace sker fixet på Gmail-nivå. Men de påverkade e-postmeddelandena är synliga i varje klient som är ansluten till det Gmail-kontot:

• Åtgärda GSMMO-migreringsdatum i Gmail
• Åtgärda GSMMO-migreringsdatum i Outlook (anslutet till Google Workspace)
• Åtgärda GSMMO-migreringsdatum i Apple Mail

Redan migrerat för flera månader sedan? Den ursprungliga Date-headern försämras inte med tiden. Redate.io kan fixa GSMMO-påverkad e-post oavsett om migreringen skedde förra veckan eller för tre år sedan.

Lämnade GSMMO-migreringen din e-post med fel datum? Kör en gratis genomsökning för att se det exakta antalet påverkade e-postmeddelanden och kostnaden för att fixa dem, innan du förbinder dig till något.