Flyt virksomhedens email uden at miste beskeder

Kort svar: Flyt virksomhedens email i denne rækkefølge: opret postkasserne på den nye platform, kopiér alt indhold via IMAP, verificér at mapper og beskeder er komplette, og skift først derefter MX-records. Sænk TTL i god tid, hold den gamle platform aktiv under overgangen, og kør en sidste synkronisering bagefter. Så går ingen beskeder tabt.

Fagligt gennemgået: 2. oktober 2026

Når en virksomhed vil flytte sin email til en ny platform, er det sjældent selve flytningen, der skaber problemer. Det er rækkefølgen, der gør forskellen.

Mange mister ikke mails, fordi systemerne er dårlige. De mister mails, fordi maildata ikke er kopieret færdigt, før mailflowet bliver sendt et nyt sted hen. Ændres MX-records for tidligt, kan nye beskeder begynde at lande på den nye platform, mens gamle beskeder stadig ligger på den gamle. Resultatet bliver hurtigt rod i mapper, usikre brugere og en supportopgave, der kunne være undgået.

Den sikre tilgang er enkel: migrér først indholdet, kontrollér at synkroniseringen er korrekt, og skift derefter MX-records. Den model går igen i officielle vejledninger fra blandt andet Microsoft og passer godt til den måde, virksomheder typisk arbejder med email i praksis.

Hvorfor mailflytning ofte skaber tabte beskeder

Virksomhedens email er sjældent kun én postkasse. Der er ofte flere brugere, historiske mapper, gamle arkiver, mobile enheder og mailprogrammer, der er sat op forskelligt. Når der opstår datatab ved en flytning, handler det tit om én af to ting: enten er der brugt den forkerte migreringsmetode, eller også er DNS blevet ændret, før nogen reelt har tjekket resultatet.

En anden klassisk fejl er at antage, at alle mails ligger på serveren. Det gør de ikke altid. Har enkelte brugere i årevis hentet mail via POP, kan en del af historikken ligge lokalt på en computer i stedet for på den gamle mailserver. Så kan en ellers velplanlagt flytning stadig ende med manglende beskeder.

Mailflytning er også et godt eksempel på, at hjemmeside og email skal behandles som to forskellige ting. En virksomhed kan sagtens flytte sit webhotel, sin WordPress-løsning eller sin WooCommerce-shop uden at skifte email samme dag. Det giver ofte mere ro at holde de to processer adskilt. Se flyt mail og web hver for sig.

IMAP eller POP ved flytning af virksomhedens email

Når målet er at flytte virksomhedens email uden at miste beskeder, er forskellen mellem IMAP og POP helt central. IMAP arbejder med mails, der ligger på serveren, mens POP typisk henter mails ned lokalt og i nogle opsætninger sletter dem fra serveren bagefter.

Det er en af grundene til, at IMAP normalt er det rigtige udgangspunkt for en sikker mailmigrering. Microsoft anbefaler også IMAP til migrering, når kildesystemet understøtter det. Bruger flere medarbejdere både mobil, laptop og desktop, passer IMAP også bedre til den daglige drift efter flytningen. Læs mere om IMAP, POP3 og webmail.

Punkt	IMAP	POP
Hvor ligger hovedkopien af mailen?	På serveren	Ofte lokalt i mailprogrammet
Egnet til flere enheder	Ja	Begrænset
Velegnet til migrering	Ja, som hovedregel	Ofte risikabelt
Risiko for skjult lokal historik	Lavere	Højere
Typisk problem ved flytning	Mapper skal verificeres	Gamle mails findes kun på én pc

Før du sætter en migrering i gang, er det derfor klogt at undersøge, om der er gamle POP-opsætninger i omløb. Det gælder især ældre Outlook-profiler og maskiner, som ingen rigtigt har rørt i flere år. Kig efter:

• Lokale mailarkiver i Outlook (PST-filer)
• Ældre POP-konti på enkeltbrugeres pc’er
• Gamle Apple Mail-profiler med lokale postkasser
• Mails, der kun findes på én enhed
• Uklare forskelle mellem serverindhold og lokal historik

Finder du lokal historik, kan den typisk lægges op på den nye server ved at trække mapperne fra den lokale konto over i den nye IMAP-konto i mailprogrammet, når den nye konto er sat op.

Den sikre rækkefølge for emailmigrering med IMAP og MX-records

Selve arbejdsgangen behøver ikke være kompliceret, men den skal være disciplineret. Start med at kopiere mailindholdet fra den gamle platform til den nye via IMAP. Derefter skal synkroniseringen kontrolleres grundigt. Først når det er bekræftet, at postkasserne er flyttet korrekt, giver det mening at ændre MX-records.

Den rækkefølge mindsker risikoen for, at der opstår et hul mellem gammelt og nyt system. Nye mails bliver ved med at komme ind det gamle sted, indtil mailflowet aktivt peges om. Det giver tid til at kontrollere, om mapper, datoer og indhold ser rigtige ud.

1. Kortlægning: få overblik over brugere, postkasser, aliaser, videresendelser, gamle klienter og eventuelle POP-opsætninger.
2. Sænk TTL: sæt TTL på MX-recorden ned i god tid, så skiftet slår hurtigere igennem.
3. Opret postkasser: opret alle konti og aliaser på den nye platform med samme adresser.
4. IMAP-migrering: kopiér eksisterende mails fra kildesystemet til den nye platform.
5. Verificering: tjek mapper, antal mails, sendte beskeder og stikprøver i flere konti.
6. Skift MX-records: peg først mailflowet til den nye platform, når data er bekræftet, og opdatér SPF, DKIM og DMARC samtidig.
7. Efterkontrol og slutsynkronisering: se, om nye mails lander rigtigt, kør en sidste synkronisering af det, der nåede at lande på den gamle server, og luk først den gamle platform bagefter.

Bruger platformen migrering via batches eller lignende værktøjer, holder du stadig fast i samme princip. Værktøjet kan være forskelligt, men rækkefølgen ændrer sig ikke.

Eksempel: IMAP-kopiering med imapsync

Har du ikke et migreringsværktøj fra den nye udbyder, er det åbne værktøj imapsync en udbredt måde at kopiere en postkasse fra én IMAP-server til en anden. Det kan køres flere gange; anden gang kopieres kun det, der er kommet til siden sidst.

imapsync --host1 imap.gammel-udbyder.dk --user1 [email protected] --passfile1 gammel.txt \
         --host2 imap.ny-udbyder.dk --user2 [email protected] --passfile2 ny.txt

Gem adgangskoderne i filer i stedet for at skrive dem direkte i kommandoen, og slet filerne, når flytningen er færdig.

MX-records og mailflow under skift af mailplatform

En MX-record bestemmer, hvilken mailserver der skal modtage email for domænet. Når den ændres, begynder nye beskeder gradvist at blive sendt til den nye platform i stedet for den gamle. Derfor bør MX-records ikke skiftes først.

MX-records bruger prioritetstal, hvor det laveste tal har højeste prioritet. En MX-record skal pege på et værtsnavn for en mailserver (ikke direkte på en IP-adresse eller et CNAME). Håndteres DNS forkert, kan virksomheden opleve afviste mails eller beskeder, der havner det forkerte sted.

DNS-ændringer kan tage tid om at slå helt igennem. Afhængigt af TTL og cache hos modtagende servere kan overgangen vare op til 72 timer, før alt er konsekvent. I den periode er det ekstra vigtigt at kontrollere, hvor nye beskeder faktisk lander, og at den gamle platform stadig tager imod. Se også TTL forklaret.

Har ingen internt ansvar for DNS, bør ændringen håndteres af den person eller partner, der har det tekniske ejerskab. Det er ikke her, man skal gætte sig frem. Bruger domænet Cloudflare, så husk, at mailrelaterede records ikke må proxies (se mail nede efter Cloudflare).

Glem ikke SPF, DKIM og DMARC

Når mailflowet flytter, skal domænets afsenderregler flytte med. Ellers kan mailen nok modtages på den nye platform, men udgående mails begynder at lande i spam eller blive afvist.

• SPF: tilføj den nye udbyders afsendere til SPF-recorden, og fjern først den gamle, når ingen længere sender derfra. Husk webshop, formularer og nyhedsbrevssystemer, der også sender på domænet.
• DKIM: opret den nye platforms DKIM-nøgle i DNS, og aktivér signering, før MX skiftes.
• DMARC: har du en streng politik (quarantine eller reject), så tjek DMARC-rapporterne de første dage for at fange afsendere, der er blevet glemt.

Læs den samlede forklaring i SPF, DKIM og DMARC forklaret for virksomheder.

Kontrol af synkronisering før virksomheden skifter MX-record

Mange springer denne del over, fordi migreringsværktøjet melder succes. Det er ikke nok. En teknisk vellykket kopi er ikke det samme som en praktisk vellykket flytning.

Det relevante spørgsmål er, om medarbejderne kan finde deres mails, som de forventer. Derfor bør kontrollen ske både på kontoniveau og i rigtige mailprogrammer. Kig ikke kun på indbakken. Kig også på sendte elementer, arkiverede mapper og ældre datoer.

• Mappekontrol: stemmer mappehierarkiet med det gamle system?
• Datakontrol: kan både gamle og helt nye beskeder åbnes uden fejl, og er datoerne bevaret?
• Brugertest: virker login i webmail, mobil og desktopklient?
• Mailflowtest: kan kontoen både sende og modtage eksterne beskeder?
• Sammenligning: giver stikprøver samme resultat i gammel og ny postkasse, og stemmer antallet af mails pr. mappe nogenlunde?

Bed gerne et par nøglebrugere teste deres egne konti, før resten af organisationen flyttes helt. De opdager ofte hurtigere, hvis en vigtig mappe mangler, eller hvis noget ser forkert ud.

Backup og gendannelse under flytning af email

Selv med en god plan er backup et vigtigt sikkerhedsnet. Ikke fordi fejl er uundgåelige, men fordi email er forretningskritisk. Bliver en konto slettet ved en fejl, synkroniserer en mappe ikke korrekt, eller rydder en bruger op på det forkerte tidspunkt, kan backup være forskellen på et mindre bump og et reelt tab.

Det enkleste sikkerhedsnet er ofte at lade være med at opsige den gamle platform for tidligt. Behold den i nogle uger efter skiftet, så du kan hente noget tilbage, hvis det viser sig at mangle. Vigtige postkasser kan desuden eksporteres til en fil fra mailprogrammet, før flytningen starter.

Skeln også mellem email hosting og andre løsninger. Backup af en WordPress-side eller et webhotel er ikke det samme som gendannelse af en mailkonto. Flytter virksomheden email, bør du sikre dig, at backup og gendannelse dækker netop maildelen, og spørge udbyderen direkte, hvordan en slettet mail eller postkasse kan hentes tilbage.

Outlook og Apple Mail efter flytning af virksomhedens email

Når postkasserne er flyttet, slutter arbejdet ikke nødvendigvis. Mange virksomheder bruger stadig lokale mailprogrammer, hvor kontoen enten skal opdateres eller oprettes på ny. Her opstår en stor del af den forvirring, brugerne oplever efter selve migreringen.

Det vigtigste råd er enkelt: slet ikke den gamle kontoopsætning, før den nye er testet. Har en bruger lokal historik, gamle mapper eller særlige regler, kan de oplysninger være nyttige under kontrollen. Især Outlook-profiler kan gemme på data, der ikke umiddelbart ses i serverens mappeoversigt.

Send en kort vejledning til medarbejderne på forhånd med nyt servernavn, porte og hvornår skiftet sker. Hostious har vejledninger til opsætning af mail i Outlook og Apple Mail og til mailopsætning på iPhone og Android. Beder Outlook om adgangskode igen og igen efter skiftet, så se Outlook beder om adgangskode.

Når mailflytning kræver teknisk hjælp

Nogle mailflytninger er enkle. Andre bør ikke klares mellem to møder en tirsdag formiddag. Har virksomheden mange brugere, uklare gamle opsætninger eller forretningskritiske postkasser, er det klogt at lade en teknisk ansvarlig stå for plan, kontrol og DNS-skift. Det gælder især, når flere forhold optræder samtidig:

• Mange brugere: flere konti øger risikoen for oversete fejl.
• POP i drift: historikken kan være spredt på lokale maskiner.
• Uklart DNS-ejerskab: ingen ved, hvor MX-records administreres.
• Kritiske postkasser: salg, support eller faktura må ikke gå ned.
• Flere enheder pr. bruger: mobil, tablet og desktop skal alle virke efter skiftet.

Overvejer virksomheden samtidig nyt webhotel, WordPress-hosting eller en ny webshop, er det en god idé at planlægge email som et selvstændigt spor. Det giver bedre kontrol og mindre pres på brugerne.

Hos Hostious findes email hosting fra 29 kr./md. ekskl. moms med ubegrænset antal postkasser, IMAP, POP3, SMTP og webmail, spam- og virusfilter og dansk support døgnet rundt. Kontakt os, hvis du vil have hjælp til at planlægge flytningen.

Læs også

• Hub: Migrering og flytning – alle guides om emnet samlet ét sted
• DNS ændring ved migrering: sådan undgår du unødig nedetid
• 9 tegn på at din mailhosting skal opgraderes
• Efter flytningen: tjeklisten, der fanger alt det glemte
• Email hosting hos Hostious – mail på eget domæne med spamfilter og dansk support

Ofte stillede spørgsmål om at flytte virksomhedens email

Hvad er den rigtige rækkefølge, når vi flytter email?

Opret postkasserne på den nye platform, synkronisér alt indhold via IMAP, verificér at det er komplet – og skift først derefter MX-records. Mailflowet må aldrig flyttes før indholdet.

Mister vi mails, mens MX-skiftet slår igennem?

Nej, ikke hvis begge platforme er aktive under overgangen. Nogle afsendere leverer stadig til den gamle server, indtil DNS er opdateret overalt, og fejler en levering, prøver mailservere typisk igen i timevis. Kør en sidste synkronisering bagefter, så går intet tabt.

Skal medarbejderne sætte deres mail op igen?

Ja, mailprogrammerne skal pege på den nye server – typisk bare nyt servernavn og adgangskode i Outlook eller Apple Mail. Send en kort vejledning på forhånd, så tager det få minutter pr. enhed.

Hvad gør vi med mails, der kun ligger lokalt på en pc?

Mails hentet via POP findes ikke på serveren og kommer derfor ikke med i en IMAP-migrering. Opsæt den nye konto som IMAP i mailprogrammet, og træk de lokale mapper over i den, så de bliver lagt op på den nye server.