En migrering utan avbrott innebär att varje meddelande som skickas till din domän hamnar i en brevlåda, och att varje anställd kan skriva till sina kontakter samma dag som bytet sker. Den innebär inte att historik, mobiler och vanor byts utan att någon behöver göra något.
Två plattformar lever parallellt.
Det klassiska glappet uppstår när MX byts medan en kopiering är ofullständig, eller när en kopiator, en webbplats eller ett CRM fortfarande skickar med den gamla inloggningen.
MX är en DNS-post: den talar om för avsändande servrar vart posten till din domän ska levereras. Att byta e-posttjänst är i första hand att byta denna leveransadress. Resten (konton, historik, enheter) förbereds runt omkring.
SMTP-protokollet hanterar korta störningar väl. En avsändande server som får ett tillfälligt fel behåller meddelandet i kön och försöker igen senare. En server som tillfälligt inte går att nå leder alltså inte till att post går förlorad. Ett permanent fel (okänd brevlåda, avvisat meddelande) skickar däremot tillbaka meddelandet till avsändaren, och det meddelandet kommer aldrig fram av sig självt. Den största risken vid ett byte är inte ett avbrott, utan att den nya plattformen avvisar en mottagare för att ett alias eller en lista inte har återskapats.
TTL (livslängd) anger hur länge en DNS-resolver får behålla ett svar i minnet. Under den tiden levererar en del avsändare fortfarande till den gamla plattformen. Det är normalt, och det är därför den gamla måste kunna ta emot post under övergången.
Två veckor före. Inventering av brevlådor, alias, listor, delade brevlådor och alla program som skickar e-post. Sänkning av MX-postens DNS-TTL till ett kort värde (ofta 300 sekunder), så att bytet på bytesdagen sprids snabbt. Skapande av målkonton. Första kopieringen av historiken.
TTL sänks tidigt eftersom en resolver som har läst det gamla värdet behåller det tills det löper ut: den korta TTL:en får effekt först när den gamla cachen har gått ut. Den första kopieringen är den som tar längst tid; att starta den tidigt ger tid att upptäcka de brevlådor som ställer till problem.
Några dagar före. Kontroll av ett urval: antal meddelanden, mappar eller etiketter, möten, kontakter. Justering av metoden om urvalet inte godkänns. Förberedelse av instruktioner för mobiler och Outlook. Testutskick från målplattformen till Gmail och Outlook.com, med SPF, DKIM och DMARC redan giltiga på den nya plattformen. Dessa poster kan publiceras före MX.
Konkret: en enda SPF-post som tillåter båda plattformarna under övergången (två separata SPF-poster gör att kontrollen misslyckas), en DKIM-nyckel för den nya plattformen publicerad under en egen selektor, bredvid den gamla, och en genomgången DMARC-policy. DMARC kräver att meddelandet autentiseras med SPF eller DKIM i avsändardomänens namn; om din policy är strikt och målplattformen ännu inte är tillåten avvisar dina kontakter dina meddelanden.
Dagen före. Andra körningen: kopiera bara det som har kommit sedan den första kopieringen. Frys ändringar av alias och listor.
Bytesdagen. Byte av MX. Omedelbar extern kontroll: ett e-postmeddelande som skickas från en privat extern brevlåda ska komma fram till den nya plattformen inom TTL-tiden. Övervakning av kön. Omkonfigurering av de program som skickar e-post. En utsedd intern support, med rätt att återställa MX om ett kritiskt flöde fallerar.
Ändra samtidigt autodiscover-posten om den finns: det är den Outlook frågar för att hitta sin server. Ta också bort sekundära MX-poster som fortfarande skulle peka på den gamla plattformen: en avsändare som inte når den primära MX-servern provar nästa.
Dagarna efter. Den gamla plattformen i läsläge. Rapportering av avvikelser (en saknad mapp, en delad brevlåda). Riktad tredje körning vid behov. Därefter stängs utskick från den gamla, så att ingen anställd längre svarar från två ställen.
Den sista punkten har ett tekniskt skäl. Den gamla plattformen anser sig fortfarande ansvarig för din domän: ett meddelande som skickas därifrån till en kollega levereras lokalt, utan att MX konsulteras. Kollegan kommer aldrig att se det i sin nya brevlåda.
| Risk | Vad som händer | Motåtgärd |
|---|---|---|
| MX bytt för tidigt | Ny post kommer fram, historiken saknas | Byt efter kontroll av urvalet och andra körningen |
| Bortglömt alias eller lista | Målplattformen avvisar dessa meddelanden permanent | Inventering, frysning av alias dagen före, test av gemensamma adresser |
| Ofullständig SPF, DKIM eller DMARC | Dina meddelanden avvisas eller hamnar som skräppost hos mottagarna | Publicera före bytesdagen, kontrollera med ett verkligt meddelande |
| Program som skickar med det gamla kontot | Fakturor, larm eller inskanningar skickas inte längre | Lista över program, ny SMTP-server konfigurerad på bytesdagen |
| Utskick fortfarande öppet på den gamla plattformen | Interna meddelanden blir kvar i det gamla systemet | Stäng utskick så snart urvalet är godkänt |
| Oförberedd återgång | MX återställs, men meddelanden som tagits emot under tiden blir kvar på målplattformen | Skriftlig plan, inklusive hur dessa meddelanden förs över |
Ta, som illustration, en byrå med 40 personer. Den väljer att byta en torsdag i slutet av dagen snarare än en fredag: dagen därpå finns personalen på plats för att hantera avvikelser, och den interna supporten har en hel arbetsdag framför sig. Kopiatorn i receptionen, som skannar till e-post, konfigureras om samma kväll. Om två delade brevlådor rapporterar en saknad mapp kompletterar en riktad körning dem. I det här scenariot går inget meddelande förlorat, men flera anställda måste lägga upp sitt konto på nytt i telefonen: det är den synliga delen som ska kommuniceras i förväg.
De byter server i Outlook eller i mobilen. Den första nedladdningen av en stor brevlåda tar tid. Meddelanden som redan finns i telefonens cache kan dyka upp dubbelt om profilen inte görs om ordentligt. Planera för proceduren ”ta bort kontot och skapa det på nytt” i stället för att lappa och laga i serverinställningarna.
Skälet är detsamma för Outlook: profilen har en lokal cache kopplad till den gamla servern. En ny profil utgår från ett rent läge; en gammal profil som ändrats blandar de två världarna. I mobilen ändras ibland även protokollet (Exchange ActiveSync eller IMAP beroende på målplattform) med plattformen, vilket är ytterligare ett skäl att skapa kontot på nytt.
Serverbaserade regler, centrala signaturer och delegeringsbehörigheter läggs upp på nytt. Informera om det. Det är inget avbrott i posten. Det är administrativt arbete.
Denna vidarebefordran kräver en uttrycklig inställning: den gamla plattformen, som fortfarande tror att den är värd för brevlådorna, måste konfigureras för att reläa till den nya i stället för att leverera lokalt. Annars gör en riktad uppsamlingskörning samma jobb.
Det som är specifikt för varje utgångsläge beskrivs i migrera från Microsoft 365 och migrera från Google Workspace.
Så länge det tar att kontrollera att inget flöde fortfarande använder den gamla, och att rapporterade avvikelser har åtgärdats. Det beror på antalet brevlådor, de program som skickar e-post och takten i omkonfigureringen av datorerna. Att stänga för tidigt gör det omöjligt att rätta till fel; att stänga för sent gör att anställda arbetar i två system.
Nej, om bytet är förberett. Under TTL-tiden levererar en del avsändare fortfarande till den gamla plattformen och andra till den nya. Båda tar emot, och nästa körning för samman de två. Post går bara förlorad om den avvisas, därav vikten av alias och listor.
I regel inte: adresserna ändras inte. Informera däremot de partner som filtrerar dina meddelanden strikt eller som har tilldelat dig en särskild regel, och de som utbyter krypterad post med dig, om nycklarna ändras.
Ja, genom att återställa den gamla MX-posten, förutsatt att den gamla plattformen fortfarande är aktiv. Meddelanden som den nya har tagit emot under tiden måste då kopieras tillbaka eller förbli åtkomliga. Återgångsplanen anger vem som beslutar, inom vilken tid och hur dessa meddelanden tas om hand.
Fråga driftsleverantören vad den garanterar: att meddelandena kommer fram, att historiken förs över, eller båda. Det är olika åtaganden. Be också om återgångsplanen, skriftligt, med den person som har rätt att aktivera den.
En garanti om att meddelandena kommer fram gäller bytesdagen och dagarna efter. En garanti om historiken gäller kopieringen och kontrollen av den. En leverantör kan uppfylla den ena utan den andra; offerten ska ange vilken den tar ansvar för och hur den kontrolleras.
Hos Klytic är råd och förslag för att förbereda migreringen av e-posttjänsten kostnadsfria, och inget e-postmeddelande går förlorat. Migrering som utförs av Klytic sker enligt offert. Abonnemangen finns på sidan Priser och faktureras separat. Kostnadsposterna beskrivs i detalj i vad kostar en migrering från Microsoft 365, och kontrollistan finns i checklistan. För att jämföra målplattformar, se välja en europeisk e-posttjänst.
Den här sidan beskriver en metod. Det faktiska förloppet beror på dina flöden, dina volymer och den plattform du lämnar.
Hämtade i oktober 2026.
Kostnadsfri rådgivning, inget mejl går förlorat. En migrering som Klytic utför offereras efter en inventering.
Välkomsterbjudande
Provperiod utan förpliktelser. En rådgivare ringer upp dig för att förstå dina behov och förbereda din Klytic-miljö.
