Defaults.Exposed › Korjaukset › Guides

SPF lakkasi toimimasta vaihtaessasi sähköpostipalveluntarjoajaa — Migraatiokorjaus (2026)

Julkaistu 2026-07-08

Luvut päivätty 2026-06-29 · metodologia v7. Aggregoitu väestölaskentadata 261 miljoonan arvioidun verkkotunnuksen yli. Katso miten arvioimme.

SPF hajoaa yleensä sähköpostipalveluntarjoajan vaihdon jälkeen, koska uuden tarjoajan tietue lisättiin vanhan rinnalle. Kaksi v=spf1-tietuetta on pysyvä virhe — SPF mitätöityy kokonaan. 1,013,416 verkkotunnusta — noin yksi 138:sta SPF:ää yrittävistä — on siinä tilassa Defaults.Exposed-palvelun 261 miljoonan verkkotunnuksen väestölaskennan mukaan. Yhdistä ne yhdeksi.

Korjaus kestää noin kymmenen minuuttia: skannaa verkkotunnus nähdäksesi tarkalleen mitä migraatio jätti jälkeensä, listaa kaikki SPF-tietueet auktoritatiivisilta nimipalvelimiltasi, yhdistä ne yhdeksi tietueeksi, joka sisältää vain uuden tarjoajasi, ja varmista uudelleen dig:llä. Tämä opas käy läpi jokaisen vaiheen, sekä DKIM- ja nimipalvelintarkistukset, jotka useimmat migraatiot unohtavat.

Miksi SPF hajosi heti migraation jälkeen?

Koska uuden tarjoajan asennusopas sanoi “lisää tämä TXT-tietue” — ja teit niin, vanhan rinnalle. Se on ainoa asia, jota SPF-standardi ei salli. RFC 7208 (§3.2, §4.5:ssä määrätty virhetulos) sallii täsmälleen yhden v=spf1-tietueen per verkkotunnus; vastaanottaja, joka löytää kaksi tai useampia, must palauttaa PermErrorin eikä arvata kumpi on auktoritatiivinen. PermError tarkoittaa, että SPF on mitätön: ei vanhaa tietuetta, ei uutta, ei SPF:ää lainkaan.

Eikä se pysähdy siihen. DMARC käsittelee PermErrorin SPF-epäonnistumisena, joten postisi nojaa nyt kokonaan DKIMiin. Jos uuden tarjoajan DKIM ei ole asetettu vielä sekään — yleistä migraation keskellä — lähetät todennetonta postia täsmälleen sillä hetkellä kun vaihdoit infrastruktuuria, mikä on se hetki kun vastaanottajat tarkastelevat sinua eniten.

Tämä on copy-paste, joka mitätöi suojan vaihtaessasi tarjoajia, eikä se ole harvinaista: 1,013,416 verkkotunnusta julkaisee kahta tai useampaa SPF-tietuetta juuri nyt — noin yksi 138:sta 139 miljoonan SPF:ää yrittävästä populaatiosta Defaults.Exposed-palvelun 261 miljoonan verkkotunnuksen väestölaskennan mukaan (tiedot päivätty 2026-06-29). Täydelliset luvut kahden tietueen ansasta löytyvät omasta raportistaan; tämä sivu on menettelyllinen korjaus.

Mitä migraatio jätti jälkeensä?

Viisi jäännöstä aiheuttaa lähes kaikki migraation jälkeiset SPF-epäonnistumiset. Tarkista ne tässä järjestyksessä:

Miten korjaan sen? Migraation tarkistuslista

1. Aja ilmainen skannaus osoitteessa defaults.exposed ensin. Se lukee live-DNS:si ja kertoo, onko sinulla useita SPF-tietueita, puuttuva include tai DKIM-aukko — diagnosoi ennen kuin kosket mihinkään.

2. Listaa kaikki SPF-tietueet auktoritatiivisilla nimipalvelimilla. dig +short NS sinunverkkotunnuksesi.com, sitten dig +short TXT sinunverkkotunnuksesi.com @<nimipalvelin> yhdelle niistä. Laske merkkijonot, jotka alkavat v=spf1. Ainoa turvallinen lukumäärä on 1.

3. Yhdistä yhdeksi tietueeksi. Yksi tietue, alkaen v=spf1, sisältäen uuden tarjoajasi includin ja muut edelleen käyttämäsi lähettäjät (laskutusohjelmisto, CRM, uutiskirjoalusta), yksi lopullinen -all tai ~all. Esimerkki — vanha Google Workspace, uusi Microsoft 365, migraation keskellä:

   Ennen:  "v=spf1 include:_spf.google.com ~all"
           "v=spf1 include:spf.protection.outlook.com -all"
   
   Jälkeen: "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Myöhemmin: "v=spf1 include:spf.protection.outlook.com -all"
   

   Tarjoaja-arvot ja DNS-paneelin erityispiirteet ovat asennusoppaissa Google Workspacelle ja Microsoft 365:lle.

4. Poista ylimääräiset tietueet. Yhdistäminen ilman poistamista ei korjaa mitään — PermError tulee lukumäärästä.

5. Pidä vanhan tarjoajan include vain niin kauan kuin vanha järjestelmä lähettää — aikataulutetut raportit, vanha CRM-yhdistin, unohdettu postilaatikko. Kun tyhjennys on valmis, poista se: vanhentunut include jättää vanhan infrastruktuurin oikeutetuksi lähettämään puolestasi, ja jokainen include maksaa DNS-hakuja SPF:n kovaa 10:n kattoa vasten — vähintään 797,263 verkkotunnusta on mitätöinyt SPF:nsä ylittämällä sen rajan (väestölaskenta, 2026-06-29).

6. Aseta uuden tarjoajan DKIM — äläkä poista vanhoja selektoreita vielä. Uudet selektorit allekirjoittavat uuden postin; vanhat selektorit täytyy pitää julkaistuina kunnes kaikki niillä allekirjoitettu viesti on toimitettu ja kaikki edelleenlähetykset selvitetty. Täydellinen ohje: DKIM epäonnistuu vaihtaessasi sähköpostityökaluja.

7. Jos vaihdoit myös nimipalvelimia, tarkista molemmat. DNS-migraatiot kulkevat usein sähköpostimigraatioiden kanssa. Kysy vanhaa ja uutta NS-sarjaa suoraan (dig TXT sinunverkkotunnuksesi.com @vanha-ns ja @uusi-ns) — kunnes rekisterin delegointi leviää kokonaan, jotkut vastaanottajat kysyvät edelleen vanhoilta palvelimilta, joten korjatun tietueen täytyy olla olemassa kummankin vastaavan sarjan kohdalla.

8. Aja skannaus uudelleen ja vahvista, että SPF näyttää yhden kelvollisen tietueen läpäisyllä.

Mitä verkkotunnusta SPF oikeasti tarkistaa?

Vastaanottajat arvioivat SPF:n Return-Path (RFC5321.MailFrom) -verkkotunnusta vastaan — palautusosoitetta — ei From-otsiketta, jonka vastaanottajasi näkevät. Migraation jälkeen tämä on tärkeää kahdesti: uusi tarjoajasi saattaa käyttää omaa palautusosoitettaan kunnes konfiguroi mukautetun sellaisen, ja SPF:n “läpäisy” verkkotunnuksella, joka ei ole sinun, ei linjaudu DMARC:lle. Korjaus siihen on uuden tarjoajan DKIM, allekirjoitettuna verkkotunnuksellasi.

Migraatio ja uudelleenbrändäys samaan aikaan?

Vaihdoitko verkkotunnuksen sekä tarjoajan? Käsittele niitä kahtena työnä. Uusi verkkotunnus tarvitsee koko pinon — SPF, DKIM, DMARC — alusta alkaen; käytä uuden verkkotunnuksen sähköpostin tarkistuslistaa. Vanha verkkotunnus pysyy todennettuna niin kauan kuin edelleenlähetys tai vastausliikenne kulkee sen kautta, ja se lukitaan nimenomaisesti (ei vain hylätä) kun se pysäköidään. Vanha verkkotunnus, jossa on jäljellä puoliksi rikkinäinen SPF, on huijaustavoite entisellä nimelläsi.

Usein kysytyt kysymykset

Voinko pitää kaksi SPF-tietuetta migraation aikana? Ei. Standardissa ei ole siirtymäaikaa — kaksi v=spf1-tietuetta on PermError siitä hetkestä kun toinen on olemassa, ja 1,013,416 verkkotunnusta istuu siinä tilassa väestölaskennan mukaan (2026-06-29). Migraatiota varten turvallinen malli on yksi tietue, joka kantaa molempien tarjoajien includeja siirtymän aikana.

Kuinka kauan minun pitää pitää vanhan tarjoajan include? Kunnes mikään ei enää lähetä vanhan tarjoajan kautta — yleensä siirtymäikkunasi pituinen, päiviä tai muutama viikko. Seuraa kaiken vanhasta järjestelmästä saapuvan Return-Path-osoitetta; kun kyseinen liikenne pysähtyy, poista include ja tarkista hakumääräsi.

Miksi tarkistin näyttää edelleen vanhaa tietuetta korjauksen jälkeen? DNS-välimuisti noudattaa tietueen TTL:ää, ja jos nimipalvelimesi vaihtuivat, jotkut resolverit kyselevät edelleen vanhasta sarjasta. Varmista suoraan auktoritatiivisilta nimipalvelimilta komennolla dig TXT sinunverkkotunnuksesi.com @<ns> — jos vastaus on oikea siellä, korjaus on tehty ja välimuistit päivittyvät. Jos se on väärä yhdessä NS-sarjassa, katso “SPF-tietuetta ei löydy” — todelliset syyt.

Tarvitsenko muuttaa DMARCia vaihtaessani tarjoajaa? Yleensä ei itse tietuetta — se nimeää raportointipostilaatikkosi ja käytäntösi, ei tarjoajasi. Mutta DMARC tuloksesi riippuvat SPF:stä ja DKIMista, jonka juuri migroisit: odota laskua raporteissa siirtymisen aikana, ja varmista, että molemmat jalat läpäisevät ennen käytännön tiukentamista. Aloita kohdasta korjaa SPF jos skannaus näyttää SPF-jalan epäonnistuvan edelleen.

Lähetä omistajalle raportti

Jos teet tätä migraatiota asiakkaalle, viimeistele todisteiden kera. Aja ilmainen skannaus uudelleen kun yhdistäminen on käytössä ja lähetä arvioitu raportti yrityksen omistajalle: SPF, DKIM ja DMARC läpäisevät uudella tarjoajalla, selkokielellä, päivättynä. Se on artefakti, jonka he arkistoivat kyberturvallisuusvakuutuksen uusimiseen ja seuraavaan toimittajan turvallisuuskyselyyn — todiste siitä, että migraatio jätti verkkotunnuksen paremmin todennetuksi kuin alussa.

Tarkista verkkotunnuksesi → · DKIM epäonnistuu vaihtaessasi sähköpostityökaluja → · “SPF-tietuetta ei löydy” — todelliset syyt → · Miten arvioimme → · Vain aggregoitua dataa. Tiedot tallennettu ja käsitelty EU:ssa.