Flytta e-posten vid byte av webbhotell: kopiera, testa och byt DNS

Skapa de nya e-postkontona, kopiera gamla mejl och testa att du kan skicka och ta emot innan du byter e-postens DNS-poster. Behåll det gamla kontot och kontrollera båda inkorgarna under övergången. Webguide.se:s råd är att avsluta den gamla tjänsten först när du har verifierat kopieringen och fångat upp nytillkomna mejl. Det minskar risken att tappa mejl när du byter webbhotell.

Den här guiden täcker hela processen: varför mejl riskerar att splittras under DNS-bytet, hur du flyttar historisk e-post via IMAP, vad som inte följer med automatiskt och vad du behöver göra med SPF och DKIM innan din utgående e-post börjar hamna i spam. Du kan kontrollera en domäns SPF, DKIM och DMARC i vårt e-postverktyg. Vill du ha kortversionen först finns vår FAQ om vad som händer med e-posten när du byter webbhotell.

Varför mejl försvinner under ett webbhotellbyte

När du byter webbhotell ändrar du normalt ditt domännamns DNS-poster, bland dem A-posten (som pekar webbplatsen till ny server) och MX-posterna (som styr vart inkommande mejl levereras). Med vår DNS-lookup kan du när som helst slå upp en domäns aktuella poster. Det tar tid för dessa ändringar att spridas ut i internets DNS-infrastruktur, och den tiden kallas propageringstid. Vill du vara säker på att inga poster glöms bort i flytten har vi en checklista över DNS-posterna som är lätta att missa vid ett webbhotellbyte.

Problemet är att olika e-postservrar runt om i världen har cachat dina gamla MX-poster i varierande lång tid. Det innebär att en avsändare vars mejlserver råkar ha din gamla MX-post cachad kommer att leverera till din gamla server, medan en avsändare vars mejlserver precis slagit upp ditt domännamn skickar till den nya. Under övergången kan mejl därför hamna på två servrar. Hur länge det pågår beror bland annat på DNS-posternas cachetid (TTL) och eventuella leveransförsök som redan ligger i kö. Kontrollera båda inkorgarna i stället för att utgå från ett bestämt antal timmar.

Märk att det är avsändarens DNS-cache som avgör, inte din. Du har ingen kontroll över den. Det är det som gör e-postflytt annorlunda mot att bara byta webbhotell för en sajt.

Kontrollera leveransen på båda servrarna

Testa inkommande mejl från flera externa adresser efter bytet och kontrollera vilken inkorg som tar emot dem. Ett lyckat test visar att just den leveransen fungerade; det bevisar inte att alla avsändare använder de nya DNS-posterna.

Stänger du den gamla tjänsten för tidigt kan mejl som fortfarande skickas dit bli fördröjda eller avvisas. SMTP har regler för nya leveransförsök vid tillfälliga fel och felbesked vid misslyckad leverans, men det ersätter inte kontroll av dina inkorgar. Se SMTP-standarden om leveransförsök.

Rätt ordning är det viktigaste du kan göra

Planera webbplatsflytten och e-postflytten som två separata moment. Du behöver inte byta e-postleverantör bara för att du flyttar webbplatsen. Ska även mejlen flyttas, förbered och testa de nya kontona innan du ändrar MX-posterna.

Det praktiska upplägget ser ut så här:

1. Migrera webbplatsens filer och databas till den nya servern.
2. Testa att webbplatsen fungerar på den nya servern (via hosts-filen eller en testdomän).
3. Ändra webbplatsens DNS-poster när sajten är testad. Kontrollera först att e-postens MX-poster och servernamn fortfarande pekar på den gamla mejltjänsten. Om MX pekar på samma namn som webbplatsen kan även ett A- eller AAAA-byte påverka e-posten.
4. Verifiera webbplatsen och att mejlen fortfarande kommer fram. Byter du namnservrar måste hela den gamla DNS-zonen, inklusive e-postens poster, finnas hos den nya DNS-leverantören innan bytet.
5. Kör en fullständig IMAP-synk av din historik (se nästa avsnitt).
6. Byt nu MX-posterna till den nya servern.
7. Behåll gamla serverns e-postkonton under övergången enligt flyttplanen med leverantören. Kontrollera båda inkorgarna och kopiera nytillkomna mejl innan du avslutar tjänsten.
8. Kör en sista IMAP-synk för att fånga mejl som hamnade på gamla servern under propageringen.

Ordningen gör det lättare att upptäcka och felsöka fel i ett moment i taget. Att flytta webbplatsen först förkortar däremot inte i sig e-postens DNS-cachetid. Förberedelserna och kontrollen av båda kontona är det som skyddar mejlen.

Sänk TTL i förväg, och låt den gamla cachetiden löpa ut

Kontrollera nuvarande TTL, alltså hur länge DNS-poster får sparas i cache. Om leverantören tillåter det kan du sänka TTL på berörda MX-poster och mejlserverns A- och AAAA-poster till exempelvis 300–600 sekunder. Gör det tillräckligt tidigt för att den tidigare, längre cachetiden ska hinna löpa ut före bytet.

En lägre TTL kan få DNS-cacher att hämta ändringar tidigare, men garanterar ingen bestämd tid för hela mejlflytten. Redan cachade poster påverkas inte retroaktivt. Cloudflares TTL-dokumentation förklarar sambandet mellan cachetid och uppdatering. Återställ TTL till leverantörens rekommenderade värde när flytten är verifierad.

Flytta historiska mejl via IMAP

E-post som redan finns i dina inkorgar och mappar på gamla servern följer inte med automatiskt. Den måste du aktivt kopiera över. Det enklaste sättet för de flesta är via en vanlig e-postklient som Mozilla Thunderbird.

Metoden fungerar för alla IMAP-konton och kräver ingen teknisk förkunskap utöver att kunna lägga till ett e-postkonto i en klient.

Steg för steg med Thunderbird

1. Lägg till gamla kontot i Thunderbird via IMAP med din gamla servers inställningar (server, port, inloggning). Kontrollera att alla mappar synkroniseras och att du ser all din historik.
2. Lägg till nya kontot på samma sätt, med den nya serverns IMAP-inställningar. Du bör nu se båda kontona i Thunderbirds vänsterpanel.
3. Markera alla meddelanden i en mapp på gamla kontot (Ctrl+A), högerklicka och välj "Kopiera till" och peka ut motsvarande mapp på det nya kontot. Gör detta för varje mapp: Inkorg, Skickat, Utkast, egna mappar.
4. Vänta och verifiera. Thunderbird laddar upp meddelandena till den nya servern via IMAP. Beroende på mängd mejl kan det ta allt från några minuter till flera timmar. Kolla att antalet mejl stämmer i respektive mapp.

En sak att ha i åtanke: IMAP-synken kopierar meddelanden, den raderar dem inte från gamla servern. Du kan alltid gå tillbaka och kontrollera om något saknas.

imapsync för den som vill automatisera

Det finns ett kommandoradsverktyg som heter imapsync och som kan synkronisera hela postkonton automatiskt, med stöd för mappstruktur, lässtatus och allt däremellan. Det är mer kraftfullt men kräver att du är bekväm med terminalen.

Verktyget passar särskilt bra om du har många konton att flytta, till exempel för ett litet företag med fem till tio mejladresser. Vissa svenska webbhotells kunskapsbaser nämner imapsync som en avancerad DIY-metod, även om supporten sällan omfattar den. Kolla med din nya leverantör om de erbjuder stöd eller dokumentation för detta.

Den kritiska delta-synken

Kontrollera den gamla inkorgen efter MX-bytet och kopiera nytillkomna mejl till det nya kontot. Med imapsync kan du köra en kompletterande synk; kopierar du manuellt ska du hålla reda på vilka meddelanden som redan finns på målkontot. Gör en sista kontroll och kopiering innan den gamla tjänsten avslutas. Ett bestämt timtal är ingen garanti för att allt har följt med.

Jämför mappar och antal meddelanden och öppna några äldre mejl med bilagor på det nya kontot.

Vad som inte följer med vid IMAP-flytten

IMAP-kopiering flyttar bara dina e-postmeddelanden. Allt annat måste hanteras separat, och det är lätt att glömma:

• Kontakter och adressbok: Exportera från gamla servern (ofta som vCard-format, .vcf) och importera till den nya. De flesta e-postklienter och webbmail-gränssnitt stödjer detta.
• Kalenderdata: Om du kör kalender via din gamla webbhosts e-posttjänst, exportera som iCal-format (.ics) och importera till den nya.
• Filterregler och autosvar: Dessa är konfigurerade på servernivå och måste återskapas manuellt i den nya serverns gränssnitt (cPanel, DirectAdmin, Roundcube eller liknande).
• E-postsignaturer: Är oftast sparade i e-postklienten lokalt, men dubbelkolla om de är konfigurerade på servern via webbmail.

En adress du faktiskt kan ta med dig, och en du inte kan

Här är en distinktion som är viktig att förstå tidigt.

Om din e-postadress är kopplad till ett domännamn du äger, till exempel namn@dittforetag.se, kan du flytta den utan problem. Du tar med dig domännamnet och pekar om DNS. Adressen förblir identisk, och mottagare behöver inte ens veta att du bytt leverantör.

Om din adress däremot är en leverantörsspecifik adress, till exempel en gammal @telia.se-, @comhem.se- eller @spray.se-adress, kan du inte ta med den. Den är knuten till leverantörens infrastruktur och upphör att fungera om du lämnar tjänsten. Det finns inget sätt att "flytta" den till ett nytt webbhotell. Det enda alternativet är att meddela kontakter din nya adress och sätta upp ett autosvar på den gamla under en övergångsperiod, så länge den gamla tjänsten är aktiv.

Det här är skälet till att en egen domän alltid är ett bättre långsiktigt val för affärskommunikation.

SPF och DKIM: glöm inte utgående e-post

Testa också utgående mejl efter flytten, både från e-postklienten och från webbplatsens formulär eller butik. Kontrollera mottagarens inkorg och skräppostmapp. Inkommande mejl kan fungera även om utgående mejl får problem.

Kontrollera SPF och DKIM vid sådana problem, men räkna inte med att de förklarar alla leveransfel. SPF-posten talar om för mottagande mejlservrar vilka IP-adresser som är auktoriserade att skicka e-post för din domän. Om den nya avsändande servern inte omfattas av SPF-posten kan SPF-kontrollen misslyckas. Hur mottagaren sedan hanterar mejlet beror på dess kontroller och policy.

DKIM är en digital signatur. Den publika nyckeln i DNS måste motsvara nyckeln som den avsändande tjänsten använder. En ny leverantör kan ge dig ett nytt namn för nyckeln, en så kallad selector, och en ny DNS-post. Lägg in den enligt leverantörens anvisning före första utskicket.

DNS-poster för e-postsäkerhet är ett eget ämne som vi täcker djupare i en separat genomgång, men grundregeln är: logga in i din nya hosts kontrollpanel och hämta de SPF- och DKIM-värden de anger att du ska använda, och lägg in dem innan den nya tjänsten börjar skicka. Behöver både gamla och nya tjänsten skicka under övergången måste båda vara korrekt auktoriserade. Skapa inte två separata SPF-poster för samma namn; följ leverantörens anvisning för att kombinera tillåtna avsändare.

Ett besläktat fall som lätt glöms vid en flytt är vidarebefordran. Har du en adress som bara skickar vidare till en Gmail- eller Outlook-inkorg går mejlet ett extra hopp, och då kan SPF-kontrollen misslyckas när mottagaren kontrollerar den vidarebefordrande servern mot ursprungsavsändarens SPF-post. Det händer inte alltid: vidarebefordraren kan exempelvis skriva om kuvertavsändaren. En bevarad DKIM-signatur kan hjälpa autentiseringen, men garanterar inte leverans. SPF-standarden beskriver vidarebefordran, och Google beskriver vanliga leveransproblem. Så felsöker du vidarebefordrad e-post som inte kommer fram.

Kan du testa e-post med hosts-filen?

En sak som är värd att förstå: hosts-filen på din dator låter dig testa att en webbplats ser rätt ut på ny server innan du byter DNS. Men hosts-filen påverkar inte MX-poster och inte hur inkommande e-post levereras. Den påverkar datorns lokala uppslagning av servernamn, men inte avsändarnas DNS-uppslagningar.

Det du kan testa med hosts-filen är om webmail-gränssnittet på nya servern är åtkomligt. För att testa att utgående SMTP fungerar kan du däremot konfigurera din e-postklient manuellt och peka den direkt mot den nya serverns SMTP-adress och port, utan att vänta på DNS. Det bekräftar att autentisering och kryptering fungerar som det ska.

Snabbkoll innan du byter MX

Innan du trycker på "spara" på de nya MX-posterna, gå igenom den här listan:

• Är e-postkonton skapade på den nya servern med rätt adresser och lösenord?
• Är IMAP-synken av historiska mejl genomförd och verifierad?
• Är kontakter och filterregler återuppbyggda på den nya servern?
• Har du de nya SPF- och DKIM-värdena redo att klistra in i DNS?
• Har den tidigare TTL-tiden löpt ut efter att du sänkte TTL på berörda poster?
• Är gamla serverns e-postkonton fortfarande aktiva (inte raderade)?
• Har du planerat kontroller och kompletterande kopiering fram till att den gamla tjänsten avslutas?

Är svaret ja på allt det, är du redo. Är det nej på något, lös det först.

Avsluta flytten med en kontroll av gamla och nya inkorgar, skickade mejl och webbplatsens utskick. Säg upp den gamla tjänsten först när du har verifierat resultatet och kopierat de sista meddelandena.