DNS-posterna du glömmer vid byte av webbhotell (checklista)
Det brukar gå bra. Sajten laddar, mejlet fungerar, allting verkar klart. Sedan, två dagar senare, börjar kunder rapportera att deras mejl studsar. Eller så tappar du Search Console-verifieringen. Eller SSL-certifikatet vägrar att utfärdas på nya servern av en anledning du inte förstår.
Det är så ett webbhotellbyte kan ta slut när man bara byter A-posten och tror att det är klart. DNS är mer än en rad i ett formulär, och de poster folk glömmer är sällan de uppenbara. Den här guiden listar dem alla, förklarar vad som faktiskt går sönder och i vilken ordning du bör göra bytena.
Inventera dina poster INNAN du rör något
Det viktigaste steget sker innan du loggar in hos det nya webbhotellet överhuvudtaget. Du behöver en fullständig bild av hur din DNS ser ut just nu, för det finns poster där som du glömt att du lade till för tre år sedan.
Gå till dnschecker.org eller mxtoolbox.com och slå upp din domän. Kolla specifikt efter TXT-poster, CNAME-poster och eventuella SRV-poster, inte bara A och MX. Exportera eller kopiera hela listan till ett kalkylblad. Det tar tio minuter och kan spara dig timmar av felsökning senare.
Kontrollera också vad din nuvarande DNS-zon faktiskt innehåller. Loggade du in i webbhotellets kontrollpanel och kollar zonfilen direkt får du den fullständiga bilden, inklusive poster som aldrig syns i de flesta "enklare" DNS-verktyg. Det är i den filen du hittar alla selektorer för DKIM, alla verifierings-TXT:ar och eventuella CAA-poster.
Komplett checklista: DNS-poster vid webbhotellbyte
Tabellen nedan täcker samtliga posttyper du behöver gå igenom. Kolumnen "Vad som går sönder" beskriver konsekvensen av att glömma posten, och det är den kolumnen de flesta guider aldrig visar.
| Post | Vad den gör | Vad som går sönder om du glömmer den |
|---|---|---|
| A | Pekar din domän (t.ex. example.com) till serverns IP-adress. | Sajten laddas inte alls, eller laddar gamla servern. Vanligtvis det första man byter, men glöm inte subdomäner med egna A-poster. |
| AAAA | Samma som A men för IPv6-adresser. | Besökare med enbart IPv6 (ovanligt men förekommer) når inte sajten. Och om nya servern inte har IPv6, ta bort gamla AAAA-posten, annars kan den ta över. |
| CNAME (www) | Pekar www.example.com till example.com eller direkt till ny server. | Besökare som skriver www framför domänen hamnar på gamla servern, eller får ett felmeddelande. Ofta förbisedd post. |
| CNAME (övriga) | Subdomäner som shop., mail., app. eller liknande med egna CNAME-pekare. | Tjänster på subdomäner slutar fungera. Exakt vilka beror på vad du kör, och det är här inventering i förväg är nödvändig. |
| MX | Anger vilka servrar som tar emot e-post till din domän. | Inkommande e-post försvinner eller studsar. MX är den post du bör byta sist och med stor omsorg. Se vår separata guide om att flytta e-posten utan att tappa mejl. |
| SPF (TXT) | Listar vilka servrar som är auktoriserade att skicka e-post i ditt domännamns namn. | Utgående e-post hamnar i skräppost hos mottagarna. Syns inte dag 1 utan dag 2-3 när gamla serverns IP inte längre är din primära. Se djupdyket nedan. |
| DKIM (TXT) | En kryptografisk nyckel som signerar utgående e-post och bevisar att den kom från din server. | Signaturen matchar inte. I kombination med DMARC kan detta innebära att legitima mejl blockeras hos mottagaren. Nyckeln är unik per server, du kan inte flytta den utan att generera en ny. |
| DMARC (TXT) | Anger vad mottagarens server ska göra med mejl som misslyckas SPF- eller DKIM-kontrollen (none/quarantine/reject) samt var rapporter ska skickas. | Med policy quarantine eller reject blockeras legitima mejl om SPF och DKIM inte stämmer. Glöm inte att uppdatera rua/ruf-adressen om den pekar mot en gammal inkorg. |
| CAA | Anger vilka certifikatutfärdare (CA) som får utfärda SSL-certifikat för din domän. | Om den gamla servern hade en CAA-post som bara tillät, säg, Sectigo, och nya servern använder Let's Encrypt kan SSL-utfärdandet misslyckas. Sajten är nere med certifikatfel tills du löser det. |
| autodiscover / autoconfig | Hjälper e-postklienter som Outlook och Thunderbird att konfigurera sig automatiskt mot rätt server. | Ingen omedelbar synlig effekt för befintliga användare, men nya klienter som ska konfigureras hittar fel server eller inget alls. Irriterande supportärende i efterhand. |
| SRV | Pekar specifika tjänster (t.ex. VoIP, XMPP, vissa Microsoft 365-funktioner) till rätt server och port. | Beror helt på vilka tjänster du kör. Många glömmer SRV-poster för att de lades till av en systemintegratör och sedan aldrig tänkts på igen. |
| Verifierings-TXT | TXT-poster som Google Search Console, Microsoft 365, Mailchimp m.fl. använder för att bevisa att du äger domänen. | Du tappar verifieringsstatusen. Search Console visar domänen som "ej verifierad" och du förlorar tillgång till data. Microsoft 365-tenant kan tappa sin domänkoppling. |
Varför SPF, DKIM och DMARC är de mest lömska posterna
Det speciella med e-postposter är att de inte slutar fungera omedelbart. När du byter webbhotell och A-posten propagerar klart fungerar sajten. Mejl verkar också funka, för de mejl som skickas de första timmarna går via gamla servern eller passerar med gammal SPF-record fortfarande cachad hos mottagarens resolver.
Problemen börjar dag 2 eller 3, när TTL:erna löpt ut och gamla poster inte längre är i cache. Då pekar SPF-posten plötsligt mot fel IP-adress, nämligen den gamla serverns, och utgående mejl från nya servern misslyckas SPF-kontrollen hos mottagaren.
DKIM gör det hela värre. DKIM-nyckeln är genererad specifikt för den server du kör e-post ifrån. Den privata nyckeln ligger på servern, den publika nyckeln finns i DNS som en TXT-post med en selektor (t.ex. mail._domainkey.example.com). Byter du server utan att:
- Generera ett nytt nyckelpar på nya servern
- Lägga till den nya offentliga nyckeln i DNS
- Aktivera signeringen på nya servern
skickar du mejl som antingen saknar DKIM-signatur eller har en signatur som inte matchar DNS-posten. Mottagarens server ser diskrepansen.
Och om din DMARC-policy är satt till p=quarantine eller p=reject, vilket du bör ha om du kör e-post seriöst, hanteras mejl som misslyckas båda kontrollerna hårt. Quarantine innebär skräppost. Reject innebär att de kastas bort tyst utan studsmeddelande till dig.
Märk att detta är ett scenario där du inte nödvändigtvis märker problemet själv. Du skickar från din klient, ser inget fel, men mottagaren får aldrig mejlet. Det är den sortens fördröjda, osynliga effekt som gör e-postposter extra farliga vid flytt.
CAA-fällan som blockerar ditt SSL-certifikat
CAA-posten (Certification Authority Authorization) är en DNS-post som specificerar vilka certifikatutfärdare som är tillåtna att utfärda SSL-certifikat för din domän. Exempel på en CAA-post som bara tillåter Let's Encrypt ser ut ungefär såhär:
example.com. CAA 0 issue "letsencrypt.org"
Problemet uppstår när gamla webbhotellet använde en annan CA, t.ex. Sectigo eller DigiCert, och du lade till en CAA-post som reflekterade det. Nu byter du till ett webbhotell som automatiskt utfärdar via Let's Encrypt. Eftersom CAA-posten inte listar letsencrypt.org vägrar Let's Encrypt att utfärda, och sajten hamnar med ett ogiltigt certifikat eller inget alls.
Lösningen är enkel: kontrollera om du har en CAA-post och uppdatera den innan du byter. Om du inte vet vilken CA nya servern använder, kontrollera det i förväg. Har du ingen CAA-post alls är det inget problem, alla CA:er är då tillåtna per default.
Verifierings-TXT:ar som tyst försvinner ur listan
Google Search Console, Microsoft 365, Mailchimp, Postmark och ett dussintal andra tjänster verifierar domänägarskap via en TXT-post i DNS. De flesta av dessa poster ser ut ungefär såhär:
google-site-verification=abc123...
Posten sitter kvar i DNS och skadar ingenting efter verifiering. Men om du byter DNS-leverantör (vilket sker om du också byter var din domän pekar namnservrar) och glömmer att återskapa alla TXT-poster, kan verifieringen hävas. Google Search Console visar då "domänen är inte längre verifierad" och du förlorar historisk data och tillgång.
Det här händer framför allt vid DNS-leverantörsbyte. Byter du bara webbhotell men behåller samma DNS-zon förblir TXT-posterna orörda. Men byter du också namnservrar, t.ex. för att nya webbhotellet vill att du pekar till deras DNS, måste du kopiera alla befintliga TXT-poster manuellt.
Inventera dem i förväg. Skriv ned varje TXT-post du hittar i zonen och lägg till dem alla på nya DNS-leverantören innan du byter namnservrar.
Timing och ordning: sänk TTL och byt MX sist
DNS-propagering är inte momentan. Posterna cachas hos resolvers runt om i världen under den tid som TTL-värdet anger, vanligtvis 3600 sekunder (en timme) eller mer. Det innebär att dina ändringar kan ta en till 48 timmar att slå igenom fullt ut, beroende på utgångsvärden och vilka resolvers dina besökare använder.
Det finns ett konkret sätt att minska den osäkerhetszonen: sänk TTL till 300 sekunder (fem minuter) ett dygn innan du börjar flytta. Då cachas posterna kortare tid och dina ändringar slår igenom snabbare. Glöm inte att höja tillbaka TTL efter att allt är klart, låg TTL belastar DNS-infrastrukturen i onödan och ger lite sämre prestanda på sikt.
Ordningen på bytena spelar roll. En rimlig prioritering ser ut så här:
- Sänk TTL på alla poster (ett dygn innan)
- Lägg upp sajten och verifiera att den fungerar på nya servern (via hosts-fil eller stagning-URL)
- Uppdatera A-poster och CNAME för sajten
- Uppdatera SPF till nya serverns IP (lägg gärna till ny server i befintlig SPF-post under en dag innan du tar bort gammal)
- Generera och publicera ny DKIM-post för nya servern
- Uppdatera CAA om tillämpligt
- Återskapa verifierings-TXT:ar
- Byt MX sist, när e-post på nya servern är konfigurerad och testad
MX bör vara sist för att minimera risken för förlorad e-post under övergången. Vår guide om att flytta e-posten utan driftstopp går igenom den processen mer detaljerat, inklusive hur du kör båda servarna parallellt under bytesdygnet.
autodiscover och autoconfig: de ofta bortglömda e-postklientposterna
När en användare konfigurerar Outlook eller Thunderbird för din domän försöker klienten hitta rätt serverinställningar automatiskt. Det sker via en CNAME-post som pekar autodiscover.example.com (Outlook) eller autoconfig.example.com (Thunderbird/Mozilla) till en konfigurationsfil på rätt server.
Befintliga konfigurerade klienter märker ingenting, inställningarna är redan sparade lokalt. Men nästa gång någon ska sätta upp e-posten på en ny dator eller telefon pekar autodiscover fel. Det ger konstiga felmeddelanden och supportärenden som är svåra att spåra till rätt orsak.
Kontrollera om du har dessa poster, uppdatera dem till nya servern och spara dig problemet.
En sista kontroll när du tror att allt är klart
Att byta webbhotell och sedan bara titta på sajten och tycka att det ser bra ut räcker inte. Gör den här kontrollen när propagering verkar klar:
- Skicka ett testmejl till en Gmail-adress och öppna det. Klicka på "Visa original" och kontrollera att SPF och DKIM står som "PASS" i headern.
- Kontrollera att SSL-certifikatet utfärdats korrekt och att certifikatkedjan är komplett (ssllabs.com/ssltest är ett bra verktyg).
- Logga in i Google Search Console och verifiera att domänen fortfarande är verifierad.
- Slå upp din domän på mxtoolbox.com och kontrollera "MX Lookup" samt "TXT".
- Om du använder Microsoft 365 eller liknande, kontrollera att domänstatusen i adminpanelen är grön.
Det är de kontrollerna som avgör om flytten verkligen gick bra, inte bara att sajten laddar.