Exchange IMAP-import: darfor aendras e-postdatum

Exchanges transportpipeline och dina e-postdatum

Exchange Online har en transportpipeline. Varje meddelande som kommer in i en brevlaada, oavsett om det anlaender fraan internet, flyttas mellan mappar eller importeras via IMAP, passerar genom denna pipeline. Och pipelinen goer vad pipelines goer: den staemplar meddelandet med metadata. Inklusive en ny Received:-header med dagens datum.

Detta aer grundorsaken till datumkorruption vid Exchange IMAP-importer. Inte en bugg. Inte en felkonfiguration. Ett medvetet arkitekturbeslut fraan Microsoft som behandlar varje meddelande som kommer in i en brevlaada som en "ny leverans", aeven naer meddelandet faktiskt aer 7 aar gammalt.

Resultatet? Du importerar 4 000 e-postmeddelanden fraan en gammal IMAP-server till Exchange Online, och varenda en visar importdatumet. E-post fraan 2018, 2020, 2023, alla staemplade med dagens datum. Dina anvaendare oeppnar Outlook paa maandagsmorgonen och ser en vaegg av identiskt daterade meddelanden.

Hur EAC-migreringsguiden fungerar

Exchange Admin Center (EAC) innehaaller en inbyggd migreringsguide foer IMAP-importer. Det aer det grafiska graenssnittet som de flesta Exchange-administratoerer tar till foerst: du gaar till Mottagare, sedan Migrering, skapar en ny batch, vaeljer "Migrera till Exchange Online", vaeljer IMAP som kaella, laddar upp en CSV med brevlaademappningar och startar batchen.

Bakom kulisserna skapar EAC-migreringsguiden en New-MigrationBatch med endpointtypen instaelld paa IMAP. Exchange ansluter till din kaell-IMAP-server, laeser varje meddelande och skriver det till maal-Exchange Online-brevlaadan. Enkelt paa pappret.

Men haer aer vad som haender paa transportnivaa. Naer Exchange Online tar emot meddelandet fraan IMAP-kaellan bearbetar det det genom samma transportpipeline som hanterar vanlig e-postleverans. Pipelinen laegger till en Received:-header med aktuell tidstaempel. Den saetter meddelandets interna leveransdatum till nu. Och Outlook, OWA och varje annan klient ansluten till den brevlaadan anvaender detta leveransdatum foer visning och sortering.

Den ursprungliga Date:-headern fraan 2019? Fortfarande daer, begravd i meddelandeheadrarna. Men Exchange anvaender den inte foer sorteringsordningen i din inkorg.

Received: from source-imap.oldserver.com (10.0.0.5) by
    AM6PR04MB5127.eurprd04.prod.outlook.com (2603:10a6:20b:f3::12)
    with Microsoft SMTP Server; Thu, 2 Apr 2026 08:44:19 +0000
Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest och samma problem

Administratoerer som foeredrar kommandoraden vaender sig ofta till New-MailboxImportRequest foer att importera PST-filer, eller New-MigrationBatch med IMAP-endpoints foer server-till-server-migreringar. Foervaentningen aer att PowerShell ger mer kontroll. Och det goer det, foer vissa saker. Inte foer datum.

New-MailboxImportRequest importerar PST-filer till Exchange Online-brevlaador. PST-filen innehaaller de ursprungliga tidstaemplarna foer varje meddelande. Men naer Exchange Online bearbetar importen staemplar transportpipelinen fortfarande varje meddelande med ett nytt leveransdatum. PowerShell-cmdleten har ingen parameter foer att aavsidosaetta detta beteende. Det finns ingen -PreserveDates-flagga (och tro mig, administratoerer har soekt efter en).

New-MigrationBatch -SourceEndpoint med en IMAP-endpoint fungerar paa liknande saett som EAC-guiden, bara utan det grafiska graenssnittet. Samma IMAP-anslutning, samma transportpipelinebearbetning, samma datumoverskrivning. Cmdleten erbjuder parametrar foer filtrering efter datumintervall (-StartAfter, -CompleteAfter) och foer att utesluta mappar, men inget som styr hur Exchange hanterar det inkommande meddelandets tidstaempel.

Foer att vara exakt paaverkar detta fraeemst visningsdatumet och sorteringsordningen. Meddelandeinnehaallt, inklusive den ursprungliga Date-headern, anlaender intakt. Exchange lindar det helt enkelt i sina egna transportmetadata och anvaender dem foer allt som aer synligt foer anvaendaren.

Direkt IMAP-import vs. tredjepartsverktyg

Spelar det naagon roll om du anvaender Exchanges inbyggda IMAP-import eller ett tredjepartsverktyg som BitTitan MigrationWiz eller CloudM? Det korta svaret: datumproblemet uppstaar oavsett, men av lite olika orsaker.

Med Exchanges inbyggda IMAP-import (EAC-guide eller PowerShell) ansluter Exchange sjaelv till kaell-IMAP-servern och haemtar meddelandena. Transportpipelinen bearbetar varje meddelande vid ankomst. En pipeline, en uppsaettning tillagda headrar.

Med tredjepartsverktyg agerar migreringsverktyget som mellanhand. Det laeser fraan kaellan, transformerar potentiellt meddelandet och skriver till Exchange Online. Exchanges transportpipeline bearbetar fortfarande det inkommande meddelandet, men tredjepartsverktyget kan oeksaa ha lagt till sin egen Received:-header under relaen. Du kan alltsaa hamna med tvaa lager av felaktiga datummetadata: ett fraan verktygets bearbetning och ett fraan Exchanges transportpipeline.

Den praktiska skillnaden? Naer du fixar datum efter en inbyggd Exchange IMAP-import finns det vanligtvis en migrerings-Received:-header att hantera. Efter en tredjepartsverktygsmigrering till Exchange kan det finnas tvaa eller tre. Det underliggande problemet aer identiskt, men headerkedjan aer roerrigar.

Varfoer Exchange Onlines transportregler goer det vaerre

Haer aer naagot som oeverraskar aeven erfarna Exchange-administratoerer. Exchange Online har transportregler (nu kallade "regler foer meddelandefloeede" i administrationscentret) som kan utloesas paa importerade meddelanden. Om din organisation har regler som laegger till headrar, ansvarsfriskrivningar eller aendrar meddelanden baserat paa villkor, kan dessa regler bearbeta importerade e-postmeddelanden oeksaa.

Det innerbaer att ett e-postmeddelande fraan 2020 inte bara kan faa en ny Received-header med dagens datum, utan oeksaa kan faa en ansvarsfriskrivning bifogad, eller en X-header staemplad av en complianceregel som inte existerade naer det ursprungliga e-postmeddelandet skickades. Datumkorruptionen aer det mest synliga symptomet, men transportregler kan skapa ytterligare ovaentade aendringar.

Kan du inaktivera transportregler under importen? Ja, tillfalligt. Men de flesta administratoerer taenker inte paa det eftersom de inte foervaentar sig att transportpipelinen bearbetar migrerade meddelanden. Naer de inser vad som haent aer importbatchen klar och skadan skedd.

Vad felaktiga datum innbaer i Exchange-miljoeer

Exchange-miljoeer tenderar att vara foeretagsmiljoeer. Advokatbyraer, finansinstitut, vaardorganisationer, myndigheter. Det aer inte personliga Gmail-konton daer ett felaktigt datum aer lindrigt irriterande. Det aer brevlaador daer e-posttidstaemplar har juridisk och regulatorisk betydelse.

En raettslig sparrning i Exchange bevarar e-post baserat paa datumintervall. Om varje importerat e-postmeddelande visar importdatumet istaellet foer det ursprungliga datumet faangar sparrningen fel uppsaettning meddelanden. En eDiscovery-soekning efter "all kommunikation mellan januari och mars 2022" returnerar ingenting eftersom dessa e-postmeddelanden nu visar april 2026.

Bevarandepolicyer har samma problem. En organisation med en 3-aars bevarandepolicy skulle kunna oavsiktligt radera e-postmeddelanden som verkar vara fraan 2026 (och daerfoer "nya") naer de faktiskt aer fraan 2019 och borde bevaras.

Ett scenario fraan slutet av 2025: en MSP migrerade ungefaer 200 brevlaador fraan en hostad Exchange-leverantoer till Microsoft 365 med EAC-migreringsguiden. Tre veckor senare flaggade kundens compliance-ansvarige att kvartalsrapporter foer e-postarkivering visade varje arkiverat meddelande med samma datum. Hela e-postarkivet, som spaende oever 5 aar, sag ut att ha anlaent en enda tisdag i november.

Fixa Exchange IMAP-importdatum

Den ursprungliga Date:-headern oeverlever Exchanges transportpipeline intakt. Microsofts pipeline laegger till metadata runt meddelandet men aendrar inte de ursprungliga RFC 2822-headrarna inuti. Det ursprungliga datumet aer ankarpunkten foer korrigering.

Redate.io ansluter till Exchange Online-brevlaadan (via Microsoft 365-administratoersgodkaend aatkomst), skannar efter meddelanden med datumavvikelser orsakade av IMAP-importen och tillaeempar en proprietaer korrigeringsmotor som utfoer RFC-oeverenstaemmelsevalidering, meddelandestrukturbevarande och riktad metadatarekonstruktion. Motorn kaenner igen Exchange-specifika transportpipelinesignaturer i Received-headerkedjan och skiljer importartefakter fraan legitima leveransheadrar.

Varje korrigerat meddelande verifieras individuellt: innheaallsintegritet, bilagekontrollsummor, mappplacering och konversationstraadning. Original bevaras i en synlig saekerhetskopiamapp i 30 dagar. Om naagot ser fel ut aer aaterstaellning ett klick bort.

Varfoer inte fixa det med ett PowerShell-skript? Foer att foerstaa Received-headerproblemet aer den laetta delen. Att korrigera 8 000 e-postmeddelanden i 50 brevlaador utan att skada S/MIME-signerade meddelanden, bryta naestlade MIME-strukturer, foestroeaa icke-ASCII RFC 2047-headrar eller tappa mappilldelningar, faktiskt, det aer den svaara delen. Hur verifierar du att varje enskilt korrigerat meddelande i en produktionsmiljoe aer intakt? Ett skript som fungerar paa en testbrevlaada med 30 meddelanden klarar inte verklighetens kantfall. Det kontraktet med en 42 MB bilaga och tre inbaeaddade bilder i en multipart/mixed-struktur inuti en multipart/alternative-wrapper? Lycka till.

Plattformsspecifika guider

Datumkorrigeringen tillaeempas paa Exchange Online-brevlaadnivaa, men anvaendare kommer aat sin e-post via olika klienter. Var och en visar datum annorlunda:

• Atgaerda Exchange IMAP-importdatum i Outlook
• Atgaerda Exchange IMAP-importdatum i OWA (Outlook paa webben)

Letar du efter bredare kontext om Microsoft 365-datumproblem med olika migreringsverktyg? Se den fullstaendiga guiden foer att korrigera e-postdatum efter Microsoft 365-migrering.

Exchange IMAP-import laemnade dina brevlaador med felaktiga datum? Boerja med en gratis skanning foer att se hur maanga e-postmeddelanden som paverkas och vad korrigeringen kostar, inget kreditkort kraevs.