Defaults.Exposed › Fikser › Guides

SPF sluttet å fungere etter at du byttet e-postleverandør — Migrasjonens fiks (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

SPF bryter vanligvis etter et e-postleverandørbytte fordi den nye leverandørens post ble lagt til ved siden av den gamle. To v=spf1-poster er en permanent feil — SPF ugyldiggjøres helt. 1,013,416 domener — omtrent én av 138 av de som forsøker SPF — er i den tilstanden, ifølge Defaults.Exposed-sensus over 261 millioner domener. Slå dem sammen til én.

Fiksen tar omtrent ti minutter: skann domenet for å se nøyaktig hva migreringen etterlot, list opp alle SPF-poster på de autoritative navnetjenerne, slå dem sammen til én post som bare inkluderer den nye leverandøren, og bekreft på nytt med dig. Denne veiledningen går gjennom hvert trinn, pluss DKIM- og navnetjener-sjekkene de fleste migreringer glemmer.

Hvorfor brøt SPF rett etter migreringen?

Fordi den nye leverandørens oppsettsveiledning sa «legg til denne TXT-posten» — og du gjorde det, ved siden av den gamle. Det er den ene tingen SPF-standarden ikke tillater. RFC 7208 (§3.2, feilresultat foreskrevet i §4.5) tillater nøyaktig én v=spf1-post per domene; en mottaker som finner to eller flere må returnere PermError i stedet for å gjette hvilken som er autoritativ. PermError betyr at SPF er ugyldig: ikke den gamle posten, ikke den nye, ingen SPF overhodet.

Og det stopper ikke der. DMARC behandler en PermError som en feil på SPF-beinet, slik at e-posten din nå er fullstendig avhengig av DKIM. Hvis den nye leverandørens DKIM heller ikke er satt opp ennå — vanlig midt i en migrering — sender du uautentisert nøyaktig i det øyeblikket du endret infrastruktur, som er da mottakere gransker deg hardest.

Dette er kopier-og-lim-inn som ugyldiggjør beskyttelse når du bytter leverandør, og det er ikke sjeldent: 1,013,416 domener publiserer to eller flere SPF-poster akkurat nå — omtrent én av 138 av de 139 millioner sterke populasjonen som forsøker SPF, ifølge Defaults.Exposed-sensus over 261 millioner domener (data per 2026-06-29). De fulle tallene på to-poster-fellen har sin egen rapport; denne siden er den prosessuelle fiksen.

Hva etterlot migreringen?

Fem rester forårsaker nesten alle SPF-feil etter migrering. Sjekk dem i denne rekkefølgen:

Hvordan fikser jeg det? Migrasjonssjekklisten

1. Kjør den gratis skanningen på defaults.exposed først. Den leser den live DNS-en din og forteller deg om du har flere SPF-poster, en manglende include, eller et DKIM-gap — diagnostiser før du rører noe.

2. List opp alle SPF-poster på de autoritative navnetjenerne. dig +short NS dittdomene.com, og deretter dig +short TXT dittdomene.com @<navnetjener> mot en av dem. Tell strengene som starter v=spf1. Det eneste trygge antallet er 1.

3. Slå sammen til én post. Én post, starter med v=spf1, som inneholder den nye leverandørens include og alle andre sendere du fortsatt bruker (fakturaverktøy, CRM, nyhetsbrevplattform), én terminal -all eller ~all. Eksempel — gammel Google Workspace, ny Microsoft 365, midt i dreneringen:

   Før:   "v=spf1 include:_spf.google.com ~all"
          "v=spf1 include:spf.protection.outlook.com -all"
   
   Etter: "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Siden: "v=spf1 include:spf.protection.outlook.com -all"
   

   Leverandørverdier og DNS-panel-quirks er i oppsettsveiledningene for Google Workspace og Microsoft 365.

4. Slett de ekstra postene. Sammenslåing uten sletting fikser ingenting — PermError kommer fra antallet.

5. Hold den gamle leverandørens include bare mens det gamle systemet fortsatt sender — planlagte rapporter, en gammel CRM-kobling, en glemt postkasse. Når dreneringen er ferdig, fjern den: en gammel include lar den gamle infrastrukturen sende som deg, og hver include koster DNS-oppslag mot SPFs harde grense på 10 — minst 797,263 domener har ugyldiggjort SPF ved å sprenge den grensen (sensus, 2026-06-29).

6. Sett opp den nye leverandørens DKIM — og ikke slett de gamle velgerne ennå. Nye velgere signerer ny e-post; gamle velgere må forbli publisert til alle meldinger signert med dem er levert og eventuelle videresendinger er avgjort. Fullstendig gjennomgang i DKIM feiler etter bytte av e-postverktøy.

7. Hvis du endret navnetjenere også, sjekk begge. DNS-migrasjoner følger ofte med e-postmigrasjoner. Spør det gamle og det nye NS-settet direkte (dig TXT dittdomene.com @gammel-ns og @ny-ns) — til registrar-delegering er fullstendig propagert, spørrer noen mottakere fortsatt de gamle serverne, så den fikset posten må eksistere på hvilket sett enn som svarer.

8. Kjør skanningen på nytt og bekreft at SPF viser én enkelt gyldig post med bestått.

Hvilket domene sjekker SPF faktisk?

Mottakere evaluerer SPF mot Return-Path (RFC5321.MailFrom)-domenet — sprette-adressen — ikke Fra-overskriften mottakerne dine ser. Etter en migrering betyr dette to ganger: den nye leverandøren kan bruke sitt eget sprette-domene til du konfigurerer et egendefinert, og SPF «bestås» på et domene som ikke er ditt vil ikke justere for DMARC. Fiksen for det er den nye leverandørens DKIM, signert med domenet ditt.

Migrerer og ommerker samtidig?

Endret domenet i tillegg til leverandøren? Behandle dem som to jobber. Det nye domenet trenger hele stakken — SPF, DKIM, DMARC — fra dag én; bruk ny-domene-e-postsjekklisten. Det gamle domenet forblir autentisert så lenge videresending eller svare-trafikk kjører gjennom det, og låses eksplisitt ned (ikke bare forlatt) når det er parkert. Et gammelt domene med tilbakeværende, halvødelagt SPF er et forfalskingsmål som bærer ditt tidligere navn.

Ofte stilte spørsmål

Kan jeg beholde to SPF-poster mens jeg migrerer? Nei. Det er ingen nådeperiode i standarden — to v=spf1-poster er en PermError fra det øyeblikket den andre eksisterer, og 1,013,416 domener sitter i den tilstanden per sensus (2026-06-29). Det migreringssikre mønsteret er én post som bærer begge leverandørers includes under overlappet.

Hvor lenge bør jeg beholde den gamle leverandørens include? Til ingenting sender gjennom den gamle leverandøren — typisk lengden på overlappvinduet ditt, dager til noen uker. Se på Return-Path for alt som fortsatt ankommer via det gamle systemet; når den trafikken stopper, fjern include-en og sjekk oppslagstallet ditt på nytt.

Hvorfor viser en kontrollør fortsatt den gamle posten etter at jeg fikset den? DNS-buffer respekterer postens TTL, og hvis navnetjenerne dine endret seg, spørrer noen løsere fortsatt det gamle settet. Bekreft direkte på de autoritative navnetjenerne med dig TXT dittdomene.com @<ns> — hvis svaret er riktig der, er fiksen gjort og buffere vil ta seg opp. Hvis det er feil på ett NS-sett, se «SPF-post ikke funnet» — de reelle årsakene.

Må jeg endre DMARC når jeg bytter leverandør? Vanligvis ikke selve posten — den navngir rapport-postkassen din og policy, ikke leverandøren. Men DMARC-resultatene dine avhenger av SPF og DKIM du nettopp migrerte: forvent et fall i rapporter under innkoplingen, og bekreft at begge ben bestås før du strammer policy. Start på fiks SPF hvis skanningen viser at SPF-beinet fortsatt feiler.

Send eieren rapporten

Hvis du gjør denne migreringen for en klient, avslutt med bevis. Kjør den gratis skanningen på nytt når sammenslåingen er live og videresend den graderte rapporten til bedriftseieren: SPF, DKIM og DMARC bestått på den nye leverandøren, på enkelt norsk, datert. Det er artefakten de arkiverer for fornyelse av cyberforsikring og neste leverandørsikkerhets-spørreskjema — bevis for at migreringen etterlot domenet bedre autentisert enn det startet.

Sjekk domenet ditt → · DKIM feiler etter bytte av e-postverktøy → · «SPF-post ikke funnet» — de reelle årsakene → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.