Leveringen af mail holder under et skifte af mailudbyder, når DNS ændres i en bestemt rækkefølge: først forberedes posterne, så skiftes MX, og den gamle udbyder får lov at køre videre, mens resten af verden opdager ændringen. SPF, DKIM og DMARC skal dække både den gamle og den nye udbyder i overgangen, ellers kan jeres mail blive afvist eller havne i modtagernes spamfilter.
Artiklen er kort og teknisk og skrevet til den, der skal udføre skiftet eller stille krav til den, der gør. Den bygger på standarderne hos RFC Editor og på to udbyderes vejledninger, læst 7. november 2026. Tidsangivelserne er fra kilderne. De er tidsrum og kan variere.
De fire poster med én sætning hver
- MX fortæller andre mailservere, hvor mail til jeres domæne skal leveres.
- SPF er en liste over de servere, der må sende mail fra jeres domæne.
- DKIM er en digital signatur på hver mail, som modtageren kontrollerer med en nøgle, I har lagt i DNS.
- DMARC fortæller modtageren, hvad den skal gøre med mail, der ikke består SPF eller DKIM, og hvor rapporterne skal sendes hen.
Før skiftet: sænk TTL
Alle poster i DNS har en levetid, TTL, som bestemmer, hvor længe andre systemer husker svaret. Microsoft skriver i sin vejledning til flytning af postkasser, at afsendere husker MX-svaret i hele TTL-perioden, og anbefaler at sænke TTL på MX-posten, fx til 3.600 sekunder eller mindre, før flytningen og hæve den igen bagefter. Proton anbefaler 300 sekunder i sin vejledning til eget domæne. Vejledningerne er skrevet til flytning ind til hver deres tjeneste, og mekanismen er den samme den anden vej.
Sænk TTL nogle dage før skiftet, så den gamle, lange værdi er udløbet overalt, når I ændrer MX.
Rækkefølgen
- Bekræft domænet hos den nye udbyder. Det sker typisk med en TXT-post.
- Opret alle brugere og adresser hos den nye udbyder, også delte postkasser og aliaser, før mail kan nå frem.
- Tilføj den nye udbyder til SPF. Et domæne må kun have én SPF-post. Finder modtageren mere end én, er resultatet en fejl efter RFC 7208. Ret derfor den eksisterende post, så den nævner både den gamle og den nye udbyder, i stedet for at lægge en ny ved siden af. Hold øje med grænsen: SPF må højst slå 10 navne op i alt via include og lignende, ellers fejler den også.
- Læg den nye udbyders DKIM-nøgler i DNS. DKIM bruger selectors, altså navne på nøglerne, netop så et domæne kan have flere nøgler samtidig. Efter vores læsning af RFC 6376 kan gammel og ny udbyder signere side om side, så længe de bruger forskellige selectors. Proton beder om tre DKIM-poster.
- Skift MX. Slet de gamle MX-poster, eller giv den nye udbyder det laveste prioritetstal, som Protons vejledning beskriver.
- Lad den gamle udbyder køre. Microsoft skriver, at det kan tage op til 72 timer, før andres systemer ser den nye MX-post, og at den gamle løsning først bør slukkes efter mindst 72 timer. Proton skriver, at nogle platforme husker gamle indstillinger i 1 til 3 dage.
- Ryd op. Når al mail kommer frem hos den nye, fjernes den gamle udbyder fra SPF, og dens DKIM-nøgler kan fjernes.
DMARC: hvad standarden siger, og hvad udbyderen råder til
DMARC er beskrevet i RFC 9989 fra maj 2026, som afløser de tidligere RFC 7489 og 9091. Afsnit 5.1 beskriver en rækkefølge for domæneejeren: SPF, der passer til afsenderdomænet, DKIM-signering med et domæne, der passer, en postkasse til rapporterne og derefter en DMARC-post. Den begynder efter standarden normalt med politikken p=none, en overvågning, hvor intet afvises, så rapporterne kan afsløre glemte servere og andre, der sender i jeres navn. Lovlige mailstrømme, der ikke består, skal rettes, før politikken skærpes, og det kan ifølge standarden tage mange måneder med rapporter, før man er sikker.
Proton anbefaler i sin vejledning p=quarantine for de fleste domæner, altså at mail, der ikke består, lægges til side som mistænkelig.
De to råd peger i hver sin retning, og vi anbefaler ingen af dem. Vores læsning er, at et skifte er det tidspunkt, hvor glemte afsendere er mest sandsynlige: et økonomisystem, en webshop eller en nyhedsbrevstjeneste, der sender i jeres navn. Har I allerede en DMARC-post med en skærpet politik, så tjek rapporterne ekstra grundigt i ugerne omkring skiftet.
Glemte afsendere
Gå listen over systemer, der sender mail fra jeres domæne, igennem før skiftet. For hvert system skal I vide, om det sender gennem jeres mailserver eller direkte fra egen server. Sender det gennem mailserveren, skal det pege på den nye. Sender det direkte, skal det stå i SPF og helst signere med DKIM. Listen hører til tjeklisten i flyt mail, kalender og kontakter.
Hvad det kræver, og hvad det koster at lade være
Selve ændringerne i DNS tager kort tid for den, der har adgang. Tiden går med forberedelse, med at finde glemte afsendere og med at følge rapporterne i ugerne efter. Afsæt tid til at tjekke DMARC-rapporterne i mindst et par uger.
Gøres det i forkert rækkefølge, kan mail gå tabt i overgangen, eller jeres udgående mail kan ende i kundernes spamfilter. Det mærkes som manglende svar og fakturaer, der ikke bliver læst, og det tager tid at finde årsagen bagefter.
Det skal I lade være med
- At lægge en ekstra SPF-post ved siden af den gamle · to poster giver fejl.
- At slukke den gamle udbyder samme dag som MX skifter · vent, til ændringen er slået igennem.
- At skærpe DMARC midt i skiftet · se rapporterne først.
Det skal valget kunne vise
- ☐ TTL sænket i god tid før skiftet.
- ☐ Én SPF-post med begge udbydere i overgangen og under 10 opslag.
- ☐ DKIM-nøgler for den nye udbyder lagt i DNS før MX skifter.
- ☐ En liste over systemer, der sender mail fra domænet.
- ☐ En plan for at følge DMARC-rapporterne efter skiftet.
Kilder
- RFC 7208, SPF, afsnit 4.5 og 4.6.4
- RFC 6376, DKIM, afsnit 3.1
- RFC 9989, DMARC, afsnit 5.1
- Microsoft Learn, Perform a cutover migration
- Proton support, custom domain
Senest gennemgået: november 2026.
Næste skridt
Skriv listen over systemer, der sender mail fra jeres domæne, og find ud af, hvem der har adgang til jeres DNS.
Læs også: Integrationerne, ingen har skrevet ned · Når skiftet går galt
→ Kontakt · Tlf. 70 13 63 23 · Jurisdiktions- og afhængighedsvurdering hos Nielco IT
