Defaults.Exposed › Åtgärder › Guides

SPF slutade fungera efter byte av e-postleverantör — migreringsåtgärden (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

SPF bryts vanligtvis efter ett e-postleverantörsbyte för att den nya leverantörens post lades till bredvid den gamla. Två v=spf1-poster är ett permanent fel — SPF ogiltigförklaras helt. 1,013,416 domäner — ungefär en av 138 av dem som försöker med SPF — befinner sig i det tillståndet, enligt Defaults.Exposed censusdata för 261 miljoner domäner. Slå ihop dem till en.

Åtgärden tar ungefär tio minuter: scanna domänen för att se exakt vad migreringen lämnade kvar, lista varje SPF-post på dina auktoritativa namnservrar, slå ihop dem till en enda post som bara inkluderar din nya leverantör, och verifiera med dig. Den här guiden går igenom varje steg, plus DKIM- och namnserverskontroller som de flesta migreringar glömmer.

Varför bröt SPF direkt efter migreringen?

Eftersom den nya leverantörens konfigurationsguide sa “lägg till den här TXT-posten” — och det gjorde du, bredvid den gamla. Det är det enda saken SPF-standarden inte tillåter. RFC 7208 (§3.2, felresultat föreskrivet i §4.5) tillåter exakt en v=spf1-post per domän; en mottagare som hittar två eller fler måste returnera PermError snarare än att gissa vilken som är auktoritativ. PermError innebär att SPF är ogiltigt: inte den gamla posten, inte den nya, ingen SPF alls.

Och det stannar inte där. DMARC behandlar ett PermError som ett fel på SPF-benet, så din e-post beror nu helt på DKIM. Om den nya leverantörens DKIM inte heller är konfigurerad — vanligt mitt i en migrering — skickar du oautentiserat exakt i det ögonblick du bytte infrastruktur, vilket är när mottagare granskar dig hårdast.

Det är kopieringen som ogiltigförklarar skyddet när du byter leverantör, och det är inte ovanligt: 1,013,416 domäner publicerar just nu två eller fler SPF-poster — ungefär en av 138 av de 139 miljoner populationen som försöker med SPF, enligt Defaults.Exposed censusdata för 261 miljoner domäner (data per 2026-06-29). Hela siffrorna om tvåpostsfällan har sin egen rapport; den här sidan är den procedurella lösningen.

Vad lämnade migreringen kvar?

Fem kvarlämningar orsakar nästan varje post-migreringsfel med SPF. Kontrollera dem i den här ordningen:

Hur åtgärdar jag det? Migreringscheck­listan

1. Kör den kostnadsfria sökningen på defaults.exposed först. Den läser din aktiva DNS och talar om om du har flera SPF-poster, ett saknat include eller ett DKIM-gap — diagnostisera innan du rör något.

2. Lista varje SPF-post på de auktoritativa namnservrarna. dig +short NS yourdomain.com, sedan dig +short TXT yourdomain.com @<namnserver> mot en av dem. Räkna strängarna som börjar med v=spf1. Det enda säkra antalet är 1.

3. Slå ihop till en enda post. En post, som börjar med v=spf1, innehåller din nya leverantörs include och eventuella andra avsändare du fortfarande använder (faktureringsverktyg, CRM, nyhetsbrevplattform), en terminal -all eller ~all. Exempel — gammal Google Workspace, ny Microsoft 365, mitt i tömning:

   Innan:  "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"
   Senare:  "v=spf1 include:spf.protection.outlook.com -all"
   

   Leverantörsvärden och DNS-panelens egenheter finns i konfigurationsguiderna för Google Workspace och Microsoft 365.

4. Ta bort de extra posterna. Sammanslagning utan borttagning löser ingenting — PermError kommer från antalet.

5. Behåll den gamla leverantörens include bara medan det gamla systemet fortfarande skickar — schemalagda rapporter, en gammal CRM-koppling, en glömd postlåda. När tömningen är klar, ta bort den: ett inaktuellt include låter den gamla infrastrukturen ha tillstånd att skicka som dig, och varje include kostar DNS-uppslag mot SPF:s hårda tak på 10 — minst 797,263 domäner har ogiltigförklarat SPF genom att blåsa det taket (census, 2026-06-29).

6. Konfigurera den nya leverantörens DKIM — och ta inte bort de gamla selektorerna än. Nya selektorer signerar ny e-post; gamla selektorer måste förbli publicerade tills varje meddelande signerat med dem har levererats och eventuella vidarebefordringar är klara. Komplett genomgång i DKIM misslyckas efter byte av e-postverktyg.

7. Om du också bytte namnservrar, kontrollera båda. DNS-migreringar följer ofta med e-postmigreringar. Fråga den gamla och den nya NS-uppsättningen direkt (dig TXT yourdomain.com @old-ns och @new-ns) — tills registrardelegering är fullt genomförd frågar vissa mottagare fortfarande de gamla servrarna, så den åtgärdade posten måste finnas på vilken uppsättning som helst som svarar.

8. Kör sökningen igen och bekräfta att SPF visar en enda giltig post med godkänt resultat.

Vilken domän kontrollerar SPF faktiskt?

Mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen — studs­adressen — inte From-rubriken som dina mottagare ser. Efter en migrering spelar detta roll två gånger: din nya leverantör kan använda sin egen studs­domän tills du konfigurerar en anpassad sådan, och SPF som “godkänns” på en domän som inte är din räknas inte för DMARC-anpassning. Lösningen för det är den nya leverantörens DKIM, signerad med din domän.

Migrerar och byter varumärke samtidigt?

Bytte du domän och leverantör också? Behandla dem som två separata jobb. Den nya domänen behöver hela stacken — SPF, DKIM, DMARC — från dag ett; använd checklistan för ny domäns e-post. Den gamla domänen förblir autentiserad så länge vidarebefordring eller svars­trafik går genom den, och låses uttryckligen (inte bara överges) när den parkeras. En gammal domän med kvarglömd, halvtrasig SPF är ett spoofinsmål med ditt gamla namn.

Vanliga frågor

Kan jag ha två SPF-poster under migreringen? Nej. Det finns ingen karensperiod i standarden — två v=spf1-poster är ett PermError från det ögonblick den andra posten finns, och 1,013,416 domäner sitter i det tillståndet per census (2026-06-29). Det migreringssäkra mönstret är en post som bär båda leverantörernas includes under överlappet.

Hur länge ska jag behålla den gamla leverantörens include? Tills ingenting skickar via den gamla leverantören — vanligtvis längden på ditt överlappsfönster, dagar till några veckor. Titta på Return-Path för allt som fortfarande anländer via det gamla systemet; när den trafiken upphör, ta bort includet och kontrollera ditt uppslags­antal.

Varför visar ett verktyg fortfarande min gamla post efter att jag åtgärdat det? DNS-cachelagring respekterar postens TTL, och om dina namnservrar ändrades frågar vissa resolvrar fortfarande den gamla uppsättningen. Verifiera direkt på de auktoritativa namnservrarna med dig TXT yourdomain.com @<ns> — om svaret är rätt där, är lösningen klar och cacharna kommer att ikapp. Om det är fel på en NS-uppsättning, se SPF-post hittades inte — de verkliga orsakerna.

Behöver jag ändra DMARC när jag byter leverantör? Vanligtvis inte själva posten — den namnger din rapport­postlåda och policy, inte din leverantör. Men dina DMARC-resultat beror på SPF och DKIM som du precis migrerade: räkna med ett dip i rapporter under cutover, och bekräfta att båda benen godkänns innan du skärper policyn. Börja på åtgärda SPF om sökningen visar att SPF-benet fortfarande misslyckas.

Skicka ägaren rapporten

Om du gör den här migreringen för en kund, avsluta med bevis. Kör den kostnadsfria sökningen när sammanslagningen är aktiv och vidarebefordra den graderade rapporten till ägaren: SPF, DKIM och DMARC godkänns på den nya leverantören, på klarspråk, daterad. Det är den artefakt de lämnar in vid förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — bevis på att migreringen lämnade domänen bättre autentiserad än den startade.

Kontrollera din domän → · DKIM misslyckas efter byte av e-postverktyg → · SPF-post hittades inte — de verkliga orsakerna → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.