Flytta e-posten utan att tappa mejl vid byte av webbhotell

Att tappa mejl när du byter webbhotell är en mer konkret risk än de flesta inser. Det handlar inte om att något "raderas" utan om att inkommande e-post under en kortare period kan hamna på fel server, och att du aldrig vet om den hamnade rätt. Det felet är enkelt att undvika om du gör saker i rätt ordning.

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. 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). Det tar tid för dessa ändringar att spridas ut i internets DNS-infrastruktur, och den tiden kallas propageringstid.

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 24 till 72 timmar kan du alltså ta emot mejl på två servrar utan att veta om det.

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.

Hur propageringen ser ut i praktiken

Så här brukar ett MX-byte typiskt spela ut tidsmässigt:

• Timme 0: Du byter MX-posterna i DNS. Din gamla server är fortfarande aktiv och tar emot mejl.
• Timme 1 till 6: Mejlservrar med kort TTL eller tömd cache börjar leverera till den nya servern. Mejlservrar med lång cachad TTL levererar fortfarande till den gamla.
• Timme 12 till 48: Majoriteten av avsändare når nu rätt server, men gamla cacher lever kvar hos vissa leverantörer.
• Timme 48 till 72: Praktiskt taget all trafik går till den nya servern. Gamla servern ska helst fortfarande vara aktiv och ta emot som backup.

Konsekvensen om du stänger den gamla servern för tidigt är att mejl som levereras dit avvisas eller försvinner, utan att avsändaren alltid får ett tydligt felmeddelande.

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

Det vanligaste misstaget vi har sett är att byta alla DNS-poster på en gång. Byt MX-posterna sist av allt, inte tillsammans med A-posten.

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. Byt A-posten och CNAME-poster så att webbplatsen pekar på ny server. Låt MX-posterna vara kvar och peka på gamla servern.
4. Vänta 24 till 48 timmar. Webbplatsen är nu på ny server, men e-post levereras fortfarande till gamla servern utan risk för splittring.
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. Håll gamla serverns e-postkonton aktiva i ytterligare 48 till 72 timmar som nät för eftersläntrare.
8. Kör en sista IMAP-synk för att fånga mejl som hamnade på gamla servern under propageringen.

Logiken är enkel: genom att byta MX sist minskar du dramatiskt den tid under vilken inkommande mejl kan splittras. Webbplatsen är redan på plats på den nya servern, men e-posttrafiken är stabil och förutsägbar ända tills du medvetet väljer att flytta den.

Sänk TTL-värdet 24 timmar i förväg

Om du planerar ditt byte i förväg finns en enkel åtgärd som gör stor skillnad: logga in i din DNS-hantering dagen innan och sänk TTL-värdet (Time To Live) på dina MX-poster och mail-relaterade poster till 300 till 600 sekunder, det vill säga 5 till 10 minuter. Som standard brukar TTL ligga på 3600 sekunder (en timme) eller ännu längre.

Låga TTL-värden gör att DNS-cacher runt om i världen uppdaterar sig snabbare när du väl gör bytet. Propageringen kan kortas ner från 24 till 48 timmar till 2 till 6 timmar i de flesta fall. Kom ihåg att höja TTL igen efter att allt är stabilt.

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. Några svenska webbhotell, bland dem Oderland, har egna guider för imapsync-flöden anpassade till deras infrastruktur. Kolla med din nya leverantör om de erbjuder stöd eller dokumentation för detta.

Den kritiska delta-synken

Kör en sista IMAP-synk 24 till 48 timmar efter att du bytt MX-posterna. Under propageringen kan mejl ha hamnat på den gamla servern utan att du märkt det. Delta-synken fångar dessa eftersläntrare och säkerställer att ingenting faller mellan stolarna.

Det är ett litet men viktigt steg som de flesta guider hoppar över.

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

Den vanligaste efterdyningen vi har sett vid webbhotellbyten är att utgående mejl plötsligt hamnar i spam. Ofta märks det inte dag ett utan dag två eller tre, när de gamla DNS-posterna fasats ut och de nya börjat gälla fullt ut.

Orsaken är nästan alltid att SPF-posten och DKIM-posten inte uppdaterats till den nya servern. SPF-posten talar om för mottagande mejlservrar vilka IP-adresser som är auktoriserade att skicka e-post för din domän. Om din gamla servers IP fortfarande finns i SPF-posten efter bytet, men din nya server skickar från ett annat IP, flaggas mejlen som potentiellt förfalskade.

DKIM är en kryptografisk signatur som kräver att rätt nyckel är konfigurerad på den aktiva servern. Byter du server utan att uppdatera DKIM-posten i DNS slutar signaturen att stämma.

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 uppdatera dem i DNS-hanteringen i samband med MX-bytet.

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 styr bara vad din webbläsare ser.

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?
• Är TTL sänkt på MX-posterna sedan 24 timmar?
• Är gamla serverns e-postkonton fortfarande aktiva (inte raderade)?
• Vet du när du ska köra delta-synken, 24 till 48 timmar efter MX-bytet?

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

Det vanligaste misstaget i vår erfarenhet är inte att något tekniskt går fel utan att folk stressar igenom bytet och glömmer delta-synken eller SPF-uppdateringen. Mejl räddar du inte i stundens hetta, utan genom att planera de 48 timmarna efteråt lika noga som de före.