SPF holdt op med at virke efter skift af e-mailudbyder — migreringsløsningen (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

SPF bryder typisk efter et udbyderskifte, fordi den nye udbyders post blev tilføjet ved siden af den gamle. To v=spf1-poster er en permanent fejl — SPF ugyldiggøres fuldstændigt. 1,013,416 domæner — omtrent ét ud af 138 af dem, der forsøger SPF — befinder sig i denne tilstand, ifølge Defaults.Exposed-census over 261 millioner domæner. Flet dem til én.

Løsningen tager omtrent ti minutter: scan domænet for at se præcis, hvad migreringen efterlod, list alle SPF-poster hos dine autoritative navneservere, flet dem til én enkelt post, der kun inkluderer din nye udbyder, og verificer igen med dig. Denne vejledning gennemgår hvert trin, plus de DKIM- og navneservero-kontroller, de fleste migreringer glemmer.

Hvorfor brød SPF lige efter migreringen?

Fordi den nye udbyders opsætningsvejledning sagde “tilføj denne TXT-post” — og det gjorde du, ved siden af den gamle. Det er præcis det, SPF-standarden ikke tillader. RFC 7208 (§3.2, fejlresultat foreskrevet i §4.5) tillader præcis én v=spf1-post pr. domæne; en modtager, der finder to eller flere, skal returnere PermError i stedet for at gætte, hvilken der er autoritativ. PermError betyder, at SPF er ugyldig: ikke den gamle post, ikke den nye, slet ingen SPF.

Og det stopper ikke der. DMARC behandler en PermError som et fejl på SPF-benet, så din mail nu er fuldstændigt afhængig af DKIM. Er den nye udbyders DKIM heller ikke sat op endnu — et typisk scenario midt i en migrering — sender du ugodkendt post præcis på det tidspunkt, hvor du har ændret infrastrukturen, hvilket er, når modtagere undersøger dig hårdest.

Dette er copy-paste, der ugyldiggør beskyttelse, når du skifter udbyder, og det er ikke sjældent: 1,013,416 domæner udgiver to eller flere SPF-poster lige nu — omtrent ét ud af 138 af de 139 millioner domæner, der forsøger SPF, ifølge Defaults.Exposed-census over 261 millioner domæner (data pr. 2026-06-29). Hele tallene om to-posters-fælden har deres egen rapport; denne side er den praktiske løsning.

Hvad efterlod migreringen?

Fem rester forårsager næsten alle SPF-fejl efter migrering. Kontrollér dem i denne rækkefølge:

Hvad der er efterladt	Hvad du ser	Løsningen
Den gamle SPF-post, stadig i DNS ved siden af den nye (to `v=spf1`-poster)	Kontrollørerne rapporterer “flere SPF-poster” eller PermError; SPF holder helt op med at fungere	Flet til én post, slet resten — trin nedenfor
Den gamle udbyders `include:` inde i din ene post	SPF virker, men du spilder DNS-opslag, og den gamle udbyders servere kan stadig sende som dig	Fjern det, når mailen er færdig med at dræne fra det gamle system
Den nye udbyders `include:` aldrig tilføjet	Mail fra den nye udbyder fejler SPF hos modtagerne	Tilføj det til den eksisterende ene post — aldrig som en ny post
DKIM-selektorer ikke oprettet for den nye udbyder	`dkim=fail` eller signaturer fra udbyderens standarddomæne; DMARC har intet andet ben	Udgiv de nye selektorer — trin 6 nedenfor
Post kun opdateret hos de gamle navneservere	Forskellige svar afhængigt af hvem der spørges; intermitterende fejl	Ret zonen hos de autoritative navneservere; verificer begge sæt under overgangen

Hvordan løser jeg det? Migreringstjeklisten

Kør den gratis scanning på defaults.exposed først. Den læser din live DNS og fortæller dig, om du har flere SPF-poster, et manglende include eller et DKIM-hul — diagnosticér inden du rører noget som helst.
List alle SPF-poster hos de autoritative navneservere. dig +short NS ditdomæne.dk, derefter dig +short TXT ditdomæne.dk @<navneserver> mod én af dem. Tæl de strenge, der starter med v=spf1. Det eneste sikre antal er 1.
Flet til én enkelt post. Én post, der starter med v=spf1, indeholdende din nye udbyders include og alle andre afsendere, du stadig bruger (faktureringsprogram, CRM, nyhedsbrevplatform), én afsluttende -all eller ~all. Eksempel — gammel Google Workspace, ny Microsoft 365, midt i tømningsperioden:
```
Før:  "v=spf1 include:_spf.google.com ~all"
      "v=spf1 include:spf.protection.outlook.com -all"

Efter:  "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Senere: "v=spf1 include:spf.protection.outlook.com -all"
```
Udbyderværdier og DNS-panel-særheder er i opsætningsvejledningerne til Google Workspace og Microsoft 365.
Slet de ekstra poster. At flette uden at slette løser ingenting — PermError’en skyldes antallet.
Behold den gamle udbyders include, kun mens det gamle system stadig sender — planlagte rapporter, en gammel CRM-kobling, en glemt postkasse. Når tømningen er afsluttet, skal du fjerne det: et forældet include lader den gamle infrastruktur sende som dig, og hvert include koster DNS-opslag mod SPFs hårde loft på 10 — mindst 797,263 domæner har ugyldiggjort SPF ved at sprænge det loft (census, 2026-06-29).
Opsæt den nye udbyders DKIM — og slet ikke de gamle selektorer endnu. Nye selektorer signerer ny mail; gamle selektorer skal forblive udgivet, indtil alle meddelelser, der er signeret med dem, er leveret, og eventuelle videresendelser er afklaret. Fuld vejledning i DKIM fejler efter skift af e-mailværktøjer.
Hvis du også har skiftet navneservere, skal du kontrollere begge. DNS-migreringer følger ofte e-mail-migreringer. Forespørg det gamle og det nye NS-sæt direkte (dig TXT ditdomæne.dk @gammel-ns og @ny-ns) — indtil registrarens delegation er fuldt propageret, spørger nogle modtagere stadig de gamle servere, så den rettede post skal eksistere hos det sæt, der svarer.
Kør scanningen igen og bekræft, at SPF viser én enkelt gyldig post med godkendelse.

Hvilket domæne kontrollerer SPF egentlig?

Modtagere evaluerer SPF mod Return-Path (RFC5321.MailFrom) domænet — bounce-adressen — ikke Fra-headeren, som dine modtagere ser. Efter en migrering er dette dobbelt vigtigt: din nye udbyder bruger muligvis sit eget bounce-domæne, indtil du konfigurerer et tilpasset domæne, og en SPF-godkendelse for et domæne, der ikke er dit, vil ikke stemme overens med DMARC. Løsningen er den nye udbyders DKIM, signeret med dit domæne.

Migrerer og rebrander du på samme tid?

Har du også skiftet domæne? Behandl det som to jobs. Det nye domæne skal have hele stakken — SPF, DKIM, DMARC — fra dag ét; brug tjeklisten for e-mail på et nyt domæne. Det gamle domæne forbliver godkendt, så længe videresendelse eller svartrafik løber igennem det, og låses eksplicit ned (ikke blot abandoneres) når det er parkeret. Et gammelt domæne med halvbrækket SPF er et spoofing-mål i dit tidligere navn.

Ofte stillede spørgsmål

Kan jeg beholde to SPF-poster, mens jeg migrerer? Nej. Der er ingen nådeperiode i standarden — to v=spf1-poster er en PermError fra det øjeblik, den anden eksisterer, og 1,013,416 domæner sidder i den tilstand pr. census (2026-06-29). Det migreringssikre mønster er én post, der bærer begge udbyders includes i overlapsperioden.

Hvor længe bør jeg beholde den gamle udbyders include? Indtil ingenting sender via den gamle udbyder — typisk længden af dit overlapsvindue, fra dage til et par uger. Kig på Return-Path for alt, der stadig ankommer via det gamle system; når den trafik stopper, skal du fjerne include’et og kontrollere dit opslags-antal igen.

Hvorfor viser en kontrollør stadig min gamle post, efter jeg har rettet det? DNS-caching respekterer postens TTL, og hvis dine navneservere har skiftet, forespørger nogle resolvere stadig det gamle sæt. Verificer direkte hos de autoritative navneservere med dig TXT ditdomæne.dk @<ns> — er svaret korrekt der, er rettelsen udført, og cacherne vil indhente det. Er det forkert ved ét NS-sæt, se ‘SPF-post ikke fundet’ — de reelle årsager.

Skal jeg ændre DMARC, når jeg skifter udbyder? Normalt ikke selve posten — den angiver din rapport-postkasse og politik, ikke din udbyder. Men dine DMARC-resultater afhænger af den SPF og DKIM, du netop migrerede: forvent et dip i rapporterne under overgangen, og bekræft, at begge ben er godkendt, inden du strammer politikken. Start på ret SPF, hvis scanningen viser, at SPF-benet stadig fejler.

Send ejeren rapporten

Udfører du denne migrering for en klient, så afslut med dokumentation. Kør den gratis scanning igen, når fletningen er live, og videresend den graderede rapport til virksomhedsejeren: SPF, DKIM og DMARC godkendt hos den nye udbyder, på klart sprog, dateret. Det er det artefakt, de arkiverer til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — bevis for, at migreringen efterlod domænet bedre godkendt, end det startede.

Kontrollér dit domæne → · DKIM fejler efter skift af e-mailværktøjer → · ‘SPF-post ikke fundet’ — de reelle årsager → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.