Defaults.Exposed › Raportit

SPF ~all vs -all: Softfail vai Hardfail — minkä 139 miljoonaa tietuetta valitsi (2026)

Julkaistu 2026-07-03

Luvut ajankohdasta 2026-06-29 · metodologia v7. Kokonaisvaltaista väestölaskentadataa 261 miljoonan arvostellun verkkotunnuksen osalta. Kaikki luvut ovat koosteita — emme koskaan julkaise yksittäisen yrityksen tietuetta. Katso miten arvostelemme.

Jokainen SPF-tietue päättyy “all”-mekanismiin — verdiktiin postista, joka tulee mistä tahansa listasi ulkopuolelta — ja internet on ylivoimaisesti valinnut pehmeän vaihtoehdon: 55.8 % niistä 139 miljoonasta verkkotunnuksesta, jotka julkaisevat SPF:n, päättyy ~all-mekanismiin (softfail), kun taas 39.3 % päättyy -all-mekanismiin (hardfail). Yksi merkki erottaa toisistaan “hylkää väärennökset” ja “todennäköisesti väärennös — toimita se silti”. Se, kumpi on oikea sinulle, riippuu toisesta asetuksesta, jota useimmat omistajat eivät koskaan konfiguroi.

Mitä ~all ja -all oikeastaan kertovat vastaanottajalle?

• -all (hardfail): “Hylkää posti mistä tahansa muualta.” Jyrkkä ei.
• ~all (softfail): “Muualta tuleva posti ei todennäköisesti ole aitoa — hyväksy se, ehkä merkitse se.” Olankohautus.
• ?all (neutraali): “Ei mielipidettä.” Tämän on valinnut 3.0 % julkaisijoista; suojaa vain nimeksi.
• +all: “Kuka tahansa saa lähettää minun nimissäni.” Tämän on julkaissut 36,014 verkkotunnusta, ja se on pahempi kuin ei tietuetta ollenkaan — tervetulomatto-ongelmalla on oma raporttinsa.

Onko ~all sitten väärin? Vain jos se on yksin — ja lähes aina se on

Softfailille löytyy puolusteltava moderni peruste: Googlen lähettäjäohjeet, ja niiden mukana suurin osa toimitettavuuskäytännöistä, päätyvät suosittelemaan ~all-mekanismia yhdistettynä pakottavaan DMARC-käytäntöön (p=reject). Yhdistelmä suojaa yhtä hyvin kuin -all jokaisella DMARC:ia arvioivalla vastaanottajalla — joihin nyt kuuluvat kaikki suuret sähköpostilaatikkopalveluntarjoajat — ilman että aitoa edelleen välitettyä postia hylätään kovalla poukamalla, joka on klassinen -all-uhri. Tässä kokoonpanossa olankohautuksella on pontta: DMARC antaa sen verdiktin, jonka SPF jätti antamatta.

Mutta yhdistelmä on koko pointti, ja tässä on se, mitä väestölaskenta lisää ja mitä asennusoppaat eivät voi: internetin 77,484,057 softfail-tietueesta vain 7.1 miljoonalla — noin 1:llä 11:sta — on takanaan pakottava DMARC-käytäntö. Niiden muiden 70.4 miljoonan verkkotunnuksen kohdalla ~all on juuri sitä, miltä se kuulostaa. Niiden tietue tunnistaa väärennöksen ja päästää sen läpi.

Eikö vuoden 2024 vaatimuksia korjannut tätä?

Ei — ja ero on tärkeämpi kuin useimmat uutisoinnit antavat ymmärtää. Google ja Yahoo alkoivat vaatia todennusta joukkolähettäjiltä helmikuussa 2024, ja Microsoft seurasi toukokuussa 2025: läpäisevä, linjattu SPF tai DKIM sekä DMARC-tietue vähintään tasolla p=none. Vaatimukset eivät mene niin pitkälle, että vaatisivat pakottamista — verkkotunnus, jolla on ~all, p=none-tietue ja linjattu DKIM, täyttää vaatimukset täysin ja pysyy silti täysin väärennettävissä. Vaatimukset normalisoivat paperityöt, eivät suojaa. Tämä pakottamaton välimaasto — vaatimusten mukainen, julkaistu, väärennettävissä — on juuri se aukko, jonka tämä väestölaskenta mittaa, ja se on suurin populaatio sähköpostiturvallisuudessa.

Mihin tietueesi siis pitäisi päättyä?

1. Lähetät postia ja edelleen välitys on tärkeää (uutiskirjeet, postituslistat, aliakset): ~all DMARC p=reject -käytännön kanssa takanaan — yllä suositeltu yhdistelmä.
2. Lähetät postia tiukasti hallitusta kokoonpanosta: -all toimii ja ilmaisee käytännön itse tietueessa. Kartoita lähettäjäsi ensin — tiukka päätös kartoittamattomassa tietueessa rikkoo aitoa postia, tai pahempaa.
3. Verkkotunnus ei koskaan lähetä: -all plus p=reject, jo tänään. Mitään aitoa ei ole suojattavana, joten mitään ei voi rikkoa.

Riippumatta siitä, minkä päätöksen valitset, väestölaskennan yhden rivin oppitunti pätee: kvalifioija merkitsee vain sen verran kuin se, mikä sitä pakottaa. Se, missä kohtaa tätä tikapuuta olet, on mitattavissa.

Usein kysytyt kysymykset

Onko SPF ~all vai -all parempi? Ei kumpikaan yleispätevästi. ~all pakottavan DMARC-käytännön kanssa on malli, jota Googlen ohjeet suosittelevat — yhtäläinen suoja DMARC:ia arvioivilla vastaanottajilla ilman että edelleen välitetty posti rikkoutuu. -all sopii tiukasti hallituille lähettäjille. Pelkkä ~all — kaikkien paitsi 1:n 11:sta softfail-verkkotunnuksen tila — on heikko vaihtoehto.

Mitä SPF softfail tarkoittaa? ~all kertoo vastaanottajille, että listaamattomilta palvelimilta tuleva posti on todennäköisesti epäaitoa mutta se pitäisi silti hyväksyä, yleensä epäluulolla. Siitä tulee todellista suojaa vasta, kun DMARC-käytäntö reagoi virheeseen; katso SPF ilman DMARC:ia.

Rikkooko hardfail -all edelleen välitetyn sähköpostini? Voi rikkoa: edelleen välitys lähettää postisi uudelleen välittäjän palvelimelta, jota SPF:si ei listaa, ja hardfail kutsuu hylkäystä ennen kuin DKIM tai DMARC punnitaan. Tämä riski on syy siihen, miksi ~all + p=reject -yhdistelmä on olemassa.

Vaativatko Google ja Microsoft nyt -all-mekanismia? Ei. Joukkolähettäjävaatimukset edellyttävät linjattua, läpäisevää todennusta ja DMARC-tietuetta vähintään tasolla p=none — ei pakottamista, ei tiettyä kvalifioijaa. Googlen vaatimusten vastaisen joukkopostin hylkäys on käytössä; Microsoft on siirtänyt virheitä roskapostiin ja etenee kohti suoraa hylkäystä. Vaatimustenmukaisuus ei ole suojaa.

Tarkista, mihin tietueesi päättyy — ja mikä sen takana seisoo

Kaksi hakua kertoo sinulle molemmat, ilmaiseksi, 30 sekunnissa. Jos olet yksi niistä 70.4 miljoonasta pakottamattomasta olankohautuksesta, korjaus on DNS-tietue, ei ostos.

Tarkista verkkotunnuksesi → · Korjaa SPF → · Korjaa DMARC → · SPF-kypsyysmalli → · +all-kartta → · Vain koostedataa. Data tallennetaan ja käsitellään EU:ssa.