SPF ~all ir -all: „softfail" ar „hardfail" — ką pasirinko 139 milijono įrašų (2026)

Q: Kas geriau — SPF ~all ar -all?

Nei vienas visais atvejais. ~all su vykdoma DMARC politika yra modelis, kurį rekomenduoja „Google\" gairės — vienoda apsauga DMARC vertinančiuose gavėjuose nesugadinant persiųsto pašto. -all tinka griežtai kontroliuojamiems siuntėjams. ~all vienas — tokia yra visų, išskyrus 1 iš 11, „softfail\" domenų būklė — yra silpnas variantas.

Q: Ką reiškia SPF „softfail\"?

~all sako gavėjams, kad paštas iš neįrašytų serverių tikriausiai neteisėtas, bet vis tiek turėtų būti priimtas, dažniausiai su įtarumu. Tai tampa realia apsauga tik tuomet, kai DMARC politika reaguoja į nesėkmę; žr. SPF be DMARC.

Paskelbta 2026-07-03

Skaičiai 2026-06-29 būklės · metodika v7. Suvestiniai surašymo duomenys apie 261 milijono įvertintų domenų. Visi skaičiai yra suvestiniai — mes niekada nepublikuojame atskiro verslo įrašo. Žr. kaip vertiname.

Kiekvienas SPF įrašas baigiasi „all” mechanizmu — sprendimu dėl pašto iš bet kur, ko nėra jūsų sąraše — ir internetas įtikinamai pasirinko švelnųjį variantą: 55.8% iš 139 milijono domenų, publikuojančių SPF, baigiasi ~all („softfail”), palyginti su 39.3%, kurie baigiasi -all („hardfail”). Vienas simbolis skiria „atmesk klastotes” nuo „tikriausiai klastotė — vis tiek pristatyk”. Kuris variantas tinka jums, priklauso nuo antrojo nustatymo, kurio dauguma savininkų niekada nesukonfigūruoja.

Ką ~all ir -all iš tikrųjų sako gavėjui?

-all („hardfail”): „Atmesk paštą iš bet kur kitur.” Tvirtas ne.
~all („softfail”): „Paštas iš kitur tikriausiai nėra teisėtas — priimk, galbūt pažymėk.” Gūžtelėjimas pečiais.
?all (neutralus): „Jokios nuomonės.” Pasirinktas 3.0% publikuotojų; apsauga tik pavadinime.
+all: „Bet kas gali siųsti kaip aš.” Publikuotas 36,014 domenų ir blogesnis nei jokio įrašo — „laukiamo kilimėlio” problema turi savo atskirą ataskaitą.

Ar tuomet ~all yra klaida? Tik jei jis vienišas — o taip būna beveik visada

„Softfail” turi pagrįstą šiuolaikinį atvejį: „Google” siuntėjų gairės ir dauguma su jomis susijusios pristatymo praktikos konverguoja į ~all kartu su vykdomą DMARC politiką (p=reject). Šis derinys apsaugo taip pat gerai kaip -all kiekviename DMARC vertinančiame gavėjuje — o dabar tai apima visus pagrindinius pašto dėžučių tiekėjus — netaikant griežto atmetimo teisėtam persiųstam paštui, klasikinei -all aukai. Tokioje konfigūracijoje gūžtelėjimas pečiais turi dantų: DMARC pateikia sprendimą, kurio SPF atsisakė.

Bet derinys ir yra visa esmė, ir štai ką surašymas prideda, ko konfigūravimo vadovai negali: iš 77,484,057 „softfail” įrašų internete tik 7.1 milijono — maždaug 1 iš 11 — už savęs turi vykdomą DMARC politiką. Kitiems 70.4 milijono domenų ~all yra būtent tai, kaip skamba. Jų įrašas identifikuoja klastotę ir praleidžia ją pro šalį.

Argi 2024 m. įpareigojimai to neišsprendė?

Ne — ir šis skirtumas svarbesnis, nei rodo dauguma aprašymų. „Google” ir „Yahoo” pradėjo reikalauti autentifikacijos iš masinių siuntėjų 2024 m. vasarį, o „Microsoft” prisijungė 2025 m. gegužę: pravažiuojantis, suderintas SPF arba DKIM, plius DMARC įrašas su minimaliai p=none. Įpareigojimai nereikalauja vykdymo — domenas su ~all, p=none įrašu ir suderintu DKIM visiškai atitinka reikalavimus ir lieka visiškai suklastojamas. Įpareigojimai standartizavo popierizmą, o ne apsaugą. Ta nevykdoma vidurio zona — atitinkanti reikalavimus, publikuota, suklastojama — yra būtent ta spraga, kurią matuoja šis surašymas, ir tai yra didžiausia populiacija el. pašto saugume.

Tai kuo turėtų baigtis jūsų įrašas?

Siunčiate paštą, ir persiuntimas svarbus (naujienlaiškiai, adresų sąrašai, slapyvardžiai): ~all su DMARC p=reject už jo — aukščiau rekomenduotas derinys.
Siunčiate paštą iš griežtai kontroliuojamos aplinkos: -all veikia ir nurodo politiką pačiame įraše. Pirmiausia sudarykite savo siuntėjų žemėlapį — griežta pabaiga nesuderintame įraše sugadina realų paštą arba blogiau.
Domenas niekada nesiunčia: -all plius p=reject, jau šiandien. Nėra jokios teisėtos veiklos, kurią reikėtų saugoti, todėl nėra ko sugadinti.

Kad ir kokią pabaigą pasirinktumėte, galioja vienos eilutės surašymo pamoka: kvalifikatorius svarbus tiek, kiek tai, kas jį vykdo. Kur stovite ant tų kopėčių, yra išmatuojama.

Dažnai užduodami klausimai

Kas geriau — SPF ~all ar -all? Nei vienas visais atvejais. ~all su vykdoma DMARC politika yra modelis, kurį rekomenduoja „Google” gairės — vienoda apsauga DMARC vertinančiuose gavėjuose nesugadinant persiųsto pašto. -all tinka griežtai kontroliuojamiems siuntėjams. ~all vienas — tokia yra visų, išskyrus 1 iš 11, „softfail” domenų būklė — yra silpnas variantas.

Ką reiškia SPF „softfail”? ~all sako gavėjams, kad paštas iš neįrašytų serverių tikriausiai neteisėtas, bet vis tiek turėtų būti priimtas, dažniausiai su įtarumu. Tai tampa realia apsauga tik tuomet, kai DMARC politika reaguoja į nesėkmę; žr. SPF be DMARC.

Ar „hardfail” -all sugadins mano persiųstą el. paštą? Gali: persiuntimas iš naujo išsiunčia jūsų paštą iš persiuntėjo serverio, kurio jūsų SPF neįrašo, o „hardfail” kviečia atmesti prieš įsiterpiant DKIM ar DMARC. Būtent dėl tos rizikos ir egzistuoja derinys ~all + p=reject.

Ar „Google” ir „Microsoft” dabar reikalauja -all? Ne. Masinių siuntėjų įpareigojimai reikalauja suderintos, pravažiuojančios autentifikacijos ir DMARC įrašo su minimaliai p=none — jokio vykdymo, jokio konkretaus kvalifikatoriaus. „Google” reikalavimų neatitinkančio masinio pašto atmetimas jau veikia; „Microsoft” nesėkmes meta į šlamštą ir juda link tiesioginio atmetimo. Atitiktis nėra apsauga.

Patikrinkite, kuo baigiasi jūsų įrašas — ir kas už jo stovi

Dvi paieškos nemokamai per 30 sekundžių pasako jums abu dalykus. Jei esate vienas iš 70.4 milijono nevykdomų gūžtelėjimų pečiais, sprendimas yra DNS įrašas, o ne pirkinys.

Patikrinkite savo domeną → · Pataisyti SPF → · Pataisyti DMARC → · SPF brandos modelis → · „+all” žemėlapis → · Tik suvestiniai duomenys. Duomenys saugomi ir apdorojami ES.