Flyt mail og web hver for sig – DNS gør det muligt

Kort svar: Du kan godt flytte hjemmesiden uden mail, fordi web og mail styres af hver sine DNS-records: A/AAAA/CNAME peger web, MX peger mail. Du kan derfor flytte hjemmesiden først og mailen senere (eller omvendt) eller permanent have web ét sted og mail et andet. Kravet er, at DNS-zonen sættes præcist: web-records til den ene udbyder, MX og øvrige mail-records til den anden – og en SPF-record, der nævner de rigtige afsendere.

Fagligt gennemgået: 2. oktober 2026

„Kan vi flytte hjemmesiden uden at røre mailen?“ Ja – og det er ofte den klogeste rækkefølge: én ting ad gangen, én risiko ad gangen. Denne guide forklarer mekanikken bag splittet, de to typiske scenarier og de fælder, der får „vi flytter kun web“ til alligevel at vælte mailen.

Før du ændrer noget: Eksportér eller tag skærmbilleder af hele den nuværende DNS-zone, før du rører noget. Den liste er din forsikring: med den kan du altid genskabe mail-records, hvis noget går tabt i skiftet.

Mekanikken: DNS styrer hver sin tjeneste

Dit domænes DNS-zone er en fordelingstavle: A-, AAAA- og CNAME-records sender webtrafik til webserveren, MX-records sender mail til mailserveren – og de to behøver ikke pege samme sted. Splittet er hverken et hack eller en undtagelse; det er præcis, hvad DNS er designet til:

Det er vigtigt at skelne mellem to ting, der ofte blandes sammen: hvor DNS-zonen bor (navneserverne, som domænet er delegeret til) og hvor records peger hen. Du kan flytte hjemmesiden uden at flytte DNS-zonen – så ændrer du bare web-records i den eksisterende zone. Flytter du derimod også zonen til en ny DNS-vært, skal alle records genskabes dér, også dem til mail.

De records, der hører til hver side

Record	Hører til	Typisk eksempel
A/AAAA for domænet	Web	dit-domæne.dk → webserverens IP
CNAME eller A for www	Web	www → domænet eller webserveren
MX	Mail	Mailudbyderens mailservere
A/CNAME for mail, imap, smtp, webmail	Mail	Værtsnavne, mailprogrammer forbinder til
Autodiscover (CNAME eller SRV)	Mail	Automatisk opsætning i Outlook og andre klienter
TXT: SPF	Mail (begge afsendere)	Hvilke servere må sende mail for domænet
TXT eller CNAME: DKIM	Mail (pr. afsender)	Signaturnøgler, fx selector._domainkey
TXT: DMARC	Mail	_dmarc – politik for afviste mails

Øvrige TXT-records – fx verifikationer for Google, Microsoft eller Meta – hører hverken til web eller mail, men skal også med, hvis zonen flyttes. Se guiden om TXT-records til verifikationer.

1. Kortlæg den nuværende zone

Slå de vigtigste records op, så du ved, hvad der skal blive stående. Med dig fra en terminal:

dig +short NS dit-domæne.dk
dig +short A dit-domæne.dk
dig +short MX dit-domæne.dk
dig +short TXT dit-domæne.dk
dig +short TXT _dmarc.dit-domæne.dk
dig +short CNAME autodiscover.dit-domæne.dk
dig +short A mail.dit-domæne.dk

DKIM-records kan ikke listes uden at kende selectoren. Find den i en modtaget mails header (s= i DKIM-Signature) eller i mailudbyderens kontrolpanel. Sammenhold resultatet med zonen i DNS-værtens kontrolpanel, så intet mangler.

2. Scenarie: web først, mail senere

Den anbefalede etapevej ved større flytninger: hjemmesiden migreres og godkendes (fx med gratis migrering), og ved DNS-skiftet ændres kun web-records – MX og mail-relaterede records røres ikke, så mailen fortsætter urørt hos den gamle udbyder. Sænk gerne TTL på web-records et døgn før skiftet, så ændringen slår hurtigt igennem; se TTL forklaret.

Når web er i stabil drift, tages mailflytningen som sit eget projekt efter mail-flytteguiden: konti oprettes, indhold overføres, og MX peges om til sidst. To små flytninger slår én stor – især når mange mailkonti eller travle perioder er i spil.

Husk, at den gamle udbyder skal levere mail, indtil du flytter den. Opsig derfor ikke hele abonnementet, når hjemmesiden er flyttet – opsig kun webdelen, hvis det er muligt, eller vent, til mailen også er flyttet.

3. Scenarie: permanent split

Mange kører bevidst delt i årevis: web på WordPress-hosting og mail hos en dedikeret mailløsning eller en kontorplatform som Microsoft 365 eller Google Workspace. Det fungerer fint – kravet er blot præcision i zonen:

• MX til mailudbyderen.
• Webmail- og autodiscover-records efter mailudbyderens anvisning.
• Én samlet SPF-record, der nævner begge verdener: webserveren, hvis sitet sender formular- eller ordremails direkte, og mailudbyderen. Hold øje med grænsen på ti DNS-opslag.
• DKIM-nøgler for hver afsender, så både mailudbyderen og evt. sitets SMTP-tjeneste signerer.
• Bag Cloudflare: mail-records må ikke proxies (grå sky) – se MX-guiden.

Et eksempel på en SPF-record, når webserveren og en mailudbyder begge sender (værdierne er pladsholdere – brug dem, dine udbydere oplyser):

v=spf1 ip4:203.0.113.10 include:spf.mailudbyder.example ~all

Der må kun være én SPF-record pr. domæne. Har du to TXT-records, der begge starter med v=spf1, er SPF ugyldig, og modtagere kan behandle alle dine mails som uautentificerede.

De fire fælder

• Zonen kopieres ikke komplet: ved skift af DNS-vært (fx når domænet delegeres til den nye webudbyders navneservere) skal ALLE mail-records genskabes i den nye zone FØR skiftet – ellers dør mailen, selvom „kun web“ blev flyttet. Det er fælde nummer ét, og den forklarer de fleste sager, hvor webflytningen væltede mailen.
• Mailserveren hænger på web-adressen: peger MX direkte på domænet selv, eller er mail.dit-domæne.dk en CNAME til domænet, flytter mailen med, når du ændrer domænets A-record. Giv mailserveren sit eget værtsnavn med sin egen A-record til den gamle mailserver, før du ændrer web.
• Sitets mails glemmes: WordPress sender fra webserveren – står den ikke i SPF, ryger formular- og ordremails i spam. Løsningen er SMTP med login hos mailudbyderen eller webserveren tilføjet SPF; se guiden om mails fra WordPress i spam.
• Webmail-vanen: brugere, der logger på webmail via den gamle udbyders adresse, skal have den nye vej at vide – ellers „forsvandt mailen“ i deres øjne, selvom alt virker.

4. Verificér splittet

Splittet står korrekt, når:

• web svarer fra den nye server, og mail leveres hos den rigtige udbyder (dig-opslag på A og MX bekræfter begge);
• testmails går igennem både til og fra domænet – også til en ekstern adresse som Gmail;
• sitets egne mails (kontaktformular, ordrebekræftelse) ankommer med SPF og DKIM „pass“ i headeren;
• mailprogrammer på computer og telefon stadig kan hente og sende.

Kør derefter tjeklisten efter flytningen for den del, der flyttede – og notér i én linje i jeres driftsdokument, hvem der har web, mail og DNS. Splittet er robust, men kun så længe alle ved, hvor tingene bor.

Læs også

• Hub: Migrering og flytning
• Flyt virksomhedens email uden at miste beskeder
• DNS-ændring ved migrering: sådan undgår du unødig nedetid
• SPF-fejlen „too many DNS lookups“
• Gratis migrering til Hostious – vi flytter hjemmesiden, og du bestemmer, hvornår mailen følger med

Ofte stillede spørgsmål om split af mail og web

Koster splittet på leveringssikkerheden?

Nej – modtagere ser kun DNS-records, ikke hvor mange udbydere der ligger bag. Med korrekt SPF og DKIM for hver afsender er delt drift lige så troværdig som samlet.

Hvor skal DNS-zonen bo ved permanent split?

Ét sted med godt værktøj og hurtig support – typisk hos webudbyderen eller en dedikeret DNS-vært. Det afgørende er ikke hvor, men at kun ét sted er autoritativt, og at alle ved hvilket.

Kan jeg flytte mailen først i stedet?

Ja – samme mekanik, omvendt rækkefølge: MX og mail-records peges om først, web-records røres ikke. Det vælges typisk, når mailen er den akutte del, fx hvis en udbyder lukker.

Hvorfor stoppede mailen, selvom jeg kun ændrede A-recorden?

Typisk fordi MX eller mailserverens værtsnavn pegede på domænet selv, så mailen fulgte med til den nye webserver. Giv mailserveren sit eget værtsnavn med en A-record til den rigtige mailserver, og ret MX til at pege på det.