SPF ~all vs -all: pehme või kõva tõrge — mida valis 139 miljonit kirjet (2026)

Q: Kumb on parem, SPF ~all või -all?

Kumbki mitte universaalselt. ~all koos jõustava DMARC-poliitikaga on muster, mida Google'i juhised soovitavad — võrdne kaitse DMARC-i hindavate vastuvõtjate juures ilma edastatud posti rikkumata. -all sobib rangelt kontrollitud saatjatele. ~all üksi — mis on kõigi peale 1 igast 11-st pehme tõrke domeeni seisund — on nõrk valik.

Q: Mida tähendab SPF-i pehme tõrge?

~all ütleb vastuvõtjatele, et loetlemata serveritest tulev post on tõenäoliselt ebalegitiimne, kuid tuleks siiski vastu võtta, tavaliselt kahtlusega. See muutub päris kaitseks alles siis, kui DMARC-poliitika tõrke peale tegutseb; vaata SPF ilma DMARC-ita.

Avaldatud 2026-07-03

Arvud seisuga 2026-06-29 · metoodika v7. Koondloendusandmed 261 miljoni hinnatud domeeni kohta. Kõik arvud on koondnäitajad — me ei avalda kunagi ühegi üksiku ettevõtte kirjet. Vaata kuidas me hindame.

Iga SPF-kirje lõpeb “all”-mehhanismiga — otsusega selle posti kohta, mis tuleb ükskõik kust, mida sinu loendis pole — ja internet on ülekaalukalt valinud pehme variandi: 55.8% neist 139 miljonist SPF-i avaldavast domeenist lõpeb ~all-iga (pehme tõrge), vastukaaluks 39.3%-le, mis lõpeb -all-iga (kõva tõrge). Üks tähemärk eristab “lükka võltsingud tagasi” ja “tõenäoliselt võltsing — toimeta kohale nagunii”. See, kumb sulle sobib, sõltub teisest seadest, mida enamik omanikke kunagi ei seadista.

Mida ~all ja -all vastuvõtjale tegelikult ütlevad?

-all (kõva tõrge): “Lükka tagasi post ükskõik kust mujalt.” Kindel ei.
~all (pehme tõrge): “Mujalt tulev post pole tõenäoliselt legitiimne — võta vastu, äkki märgista.” Õlakehitus.
?all (neutraalne): “Ei mingit arvamust.” Selle on valinud 3.0% avaldajatest; kaitse ainult nimeliselt.
+all: “Igaüks võib minuna saata.” Selle on avaldanud 36,014 domeeni ning see on halvem kui üldse kirjeta — tervituskardina probleemil on oma raport.

Kas ~all on siis vale? Ainult siis, kui see on üksi — ja peaaegu alati ongi

Pehmel tõrkel on kaitstav kaasaegne põhjendus: Google’i saatja juhised ja enamik nendega kaasnevast kohaletoimetatavuse praktikast koonduvad ~all-i ümber, mis on paaris jõustava DMARC-poliitikaga (p=reject). See paar kaitseb sama hästi kui -all iga DMARC-i hindava vastuvõtja juures — mis nüüd hõlmab kõiki suuremaid postkastiteenuse pakkujaid — ilma et legitiimne edastatud post kõvasti tagasi põrkaks, mis on klassikaline -all-i ohver. Selles seadistuses on õlakehitusel hambad: DMARC annab otsuse, mille SPF andmata jättis.

Aga paar ongi kogu mõte, ning siin on see, mida loendus lisab ja mida seadistusjuhendid ei suuda: internetis olevast 77,484,057 pehme tõrke kirjest on ainult 7.1 miljonil — umbes 1 igast 11-st — nende taga jõustav DMARC-poliitika. Ülejäänud 70.4 miljoni domeeni jaoks on ~all täpselt see, mille moodi see kõlab. Nende kirje tuvastab võltsingu ja lehvitab selle läbi.

Kas 2024. aasta nõuded ei parandanud seda?

Ei — ja see vahe on olulisem, kui enamik käsitlusi laseb aimata. Google ja Yahoo hakkasid 2024. aasta veebruaris nõudma masssaatjatelt autentimist, Microsoft järgnes 2025. aasta mais: läbiv, vastavusse viidud SPF või DKIM, pluss DMARC-kirje vähemalt p=none. Nõuded ei ulatu jõustamise nõudmiseni — domeen, millel on ~all, p=none-kirje ja vastavusse viidud DKIM, vastab täielikult ning jääb täiesti võltsitavaks. Nõuded normaliseerisid paberimajanduse, mitte kaitse. See jõustamata keskosa — nõuetele vastav, avaldatud, võltsitav — on täpselt see lünk, mida see loendus mõõdab, ja see on suurim populatsioon e-posti turvalisuses.

Millega peaks siis sinu kirje lõppema?

Sa saadad posti ja edastamine on oluline (uudiskirjad, meililistid, aliased): ~all koos DMARC p=reject-iga selle taga — ülalpool soovitatud paar.
Sa saadad posti rangelt kontrollitud seadistusest: -all toimib ja sätestab poliitika kirjes endas. Kaardista esmalt oma saatjad — range lõpp kaardistamata kirjel rikub päris posti või hullemat.
Domeen ei saada kunagi posti: -all pluss p=reject, täna. Ei ole midagi legitiimset, mida kaitsta, seega pole midagi rikkuda.

Ükskõik millise lõpu valid, kehtib loenduse üherealine õppetund: kvalifikaator loeb ainult niivõrd, kuivõrd loeb see, mis seda jõustab. See, kus sa sellel redelil seisad, on mõõdetav.

Korduma kippuvad küsimused

Kumb on parem, SPF ~all või -all? Kumbki mitte universaalselt. ~all koos jõustava DMARC-poliitikaga on muster, mida Google’i juhised soovitavad — võrdne kaitse DMARC-i hindavate vastuvõtjate juures ilma edastatud posti rikkumata. -all sobib rangelt kontrollitud saatjatele. ~all üksi — mis on kõigi peale 1 igast 11-st pehme tõrke domeeni seisund — on nõrk valik.

Mida tähendab SPF-i pehme tõrge? ~all ütleb vastuvõtjatele, et loetlemata serveritest tulev post on tõenäoliselt ebalegitiimne, kuid tuleks siiski vastu võtta, tavaliselt kahtlusega. See muutub päris kaitseks alles siis, kui DMARC-poliitika tõrke peale tegutseb; vaata SPF ilma DMARC-ita.

Kas kõva tõrge -all rikub minu edastatud e-posti? Võib küll: edastamine saadab sinu posti uuesti edastaja serverist, mida sinu SPF ei loetle, ja kõva tõrge kutsub tagasilükkamist enne, kui DKIM või DMARC oma sõna sekka ütlevad. Just see risk on põhjus, miks ~all + p=reject paar olemas on.

Kas Google ja Microsoft nõuavad nüüd -all-i? Ei. Masssaatja nõuded nõuavad vastavusse viidud, läbivat autentimist ja DMARC-kirjet vähemalt p=none tasemel — ei mingit jõustamist, ei mingit kindlat kvalifikaatorit. Google lükkab nõuetele mittevastavat masiposti juba praegu tagasi; Microsoft on tõrkeid rämpsu tõstnud ja liigub otsese tagasilükkamise poole. Nõuetele vastavus ei ole kaitse.

Kontrolli, millega su kirje lõpeb — ja mis selle taga seisab

Kaks päringut ütlevad sulle mõlemad, tasuta, 30 sekundiga. Kui sa oled üks neist 70.4 miljonist jõustamata õlakehitusest, on parandus DNS-kirje, mitte ost.

Kontrolli oma domeeni → · Paranda SPF → · Paranda DMARC → · SPF-i küpsusmudel → · +all-i kaart → · Ainult koondandmed. Andmed salvestatakse ja töödeldakse EL-is.