Defaults.Exposed

Defaults.Exposed › Ataskaitos

SPF PermError ataskaita: 100× daugiau domenų pažeidžia 10 užklausų ribą, nei rodo paviršiniai skaičiavimai (2026)

Paskelbta 2026-07-03

Skaičiai 2026-06-29 būsenai · metodika v7, plius grandinių kainodaros analizė, atlikta 2026-07-03. Iš 261 milijonų įvertintų domenų census’o mes išsprendėme kiekvieną SPF include: tikslą, minimą 100 ar daugiau kartų — 10,842 tikslų, apimančių 95.2% visų include nuorodų — ir kiekvieno domeno išlaikytą grandinę įkainojome pagal tą žemėlapį. Neišspręsti uodegos tikslai skaičiuoti kaip nulis, o grandinių turinys atspindi sprendimo dieną, tad antraštinis skaičius yra konservatyvus, į grindų pusę pakreiptas apytikslis įvertis: mes sakome „bent”. Tik agreguota; niekada atskiro verslo įrašas. Žr. kaip mes vertiname.

Kiek domenų pažeidžia SPF 10 užklausų ribą?

Bent 797,263 — nes SPF turi į standartą įmontuotą savęs sunaikinimo mechanizmą, o jo paleidiklis slepiasi ten, kur savininkai jo nemato. RFC 7208 §4.6.4 riboja SPF patikrą iki 10 DNS užklausų; peržengęs dešimtį, gavėjas sustoja ir grąžina PermError, o PermError įrašas nieko neapsaugo. Skaičiuok tik pačiame įraše matomas užklausas — kaip daro dauguma įrankių ir kaip iki šios ataskaitos darė mūsų census’as — ir rasi apie 8 000 pažeidėjų (tiksliau, 7,958). Įkainok include: grandines, kurias tie įrašai iš tikrųjų įtraukia, ir skaičius pasiekia 797,263: maždaug 100 kartus daugiau.

Kodėl savininkai negali to numatyti?

Nes biudžetą išleidžia kitų žmonių įrašai. include:onetool.example.com jūsų DNS skydelyje atrodo kaip viena eilutė — bet gavėjas turi parsisiųsti ir tą įrašą, ir rekursyviai suskaičiuoti kiekvieną jame esantį užklausos mechanizmą. Įrašas su trimis include gali kainuoti vienuolika. Jūsų pačių zonoje tą dieną, kai peržengėte ribą, niekas nepasikeitė; tiekėjas įtraukė dar vieną include, ir jūsų SPF mirė be įspėjimo.

Dar blogiau, DMARC laiko PermError SPF pusės nesėkme — tad domenas, kuris taip sulaužė savo SPF, dabar nesėkmingai praeina pusę savo paties autentifikavimo.

Ką atskleidė grandinių kainodara

RadinysDomenai
Viršija 10 užklausų ribą, grandinės įkainotos797,263
Viršija ribą skaičiuojant tik matomus mechanizmus7,958
Viršija ribą baigiantis griežtu -all112,215
Lygiai ties 9–10 užklausų — ties bedugnės kraštu2,119,539

Toje lentelėje dvi istorijos — trečioji, bedugnės kraštas, turi savo skyrių žemiau:

2.1 milijonų domenų yra per vieną įrankį nuo bedugnės

Skaičius, kuris turėtų nerimą kelti skaitytojams, kuriems šiuo metu viskas gerai: 2,119,539 domenų išsisprendžia į lygiai 9 ar 10 užklausų — šiandien žemiau ribos, negyvi tą dieną, kai kas nors prijungs dar vieną platformą. Tai maždaug 1 iš 66 visų SPF publikuotojų, ir tai atitinka pasiskirstymo formą: 99-o procentilio SPF įrašas jau yra ties 9 užklausomis. Užsiregistruok dar vienam rinkodaros įrankiui, įklijuok jo „tiesiog pridėk šį include” eilutę, ir įrašas, kuris pusryčių metu buvo žemiau ribos, iki pietų yra niekinis.

Kieno tai kaltė? Vis dažniau — technologijų stack’o

Didžiausi tiekėjai tyliai suplokštino savo SPF — Google _spf.google.com ir Microsoft spf.protection.outlook.com dabar išsiplečia į paprastus IP sąrašus, kainuojančius nulį vidinių užklausų (šios analizės metu patikrinome abu prieš gyvą DNS). Sprogimai kyla iš kitur: hostingo skydelio grandinės, įsigilinančios per tris lygius, regioniniai tiekėjai, kurių include vien pats kainuoja 7–10 užklausų, ir sąžiningas SaaS kaupimas — pašto dėžutė plius naujienlaiškis plius CRM plius pagalbos tarnyba, kiekvienas „tik vienas include”. Beveik niekas nepridedа vienuoliktos užklausos tyčia. Ji atsiranda kaip protingų sprendimų suma.

Kaip patikrinti ir pataisyti savo — nemokamai

  1. Suskaičiuok savo tikrąją sumąmūsų nemokama patikra išsprendžia tavo grandinę, arba naudok bet kurį SPF užklausų skaitiklį.
  2. Pašalink negyvą svorį: įrankius, kurių nustojai naudoti, dubliuojančius include ir pasenusį ptr mechanizmą.
  3. Suplokštink tik tai, ką valdai. Gilaus include pakeitimas jo IP blokais veikia tavo paties infrastruktūrai; trečiųjų šalių IP keičiasi be įspėjimo.
  4. Duok masiniams siuntėjams subdomeną. Naujienlaiškiai iš news.yourdomain.com gauna savo įrašą ir savo 10 užklausų biudžetą.

Dažnai užduodami klausimai

Kas yra SPF 10 DNS užklausų riba? RFC 7208 §4.6.4 leidžia daugiausiai 10 DNS užklausų vienam SPF įrašui įvertinti — skaičiuojant užklausas kiekviename include: rekursyviai. Ją peržengus grąžinama PermError: įrašas laikomas negaliojančiu ir jokios apsaugos neteikia.

Ką reiškia SPF PermError? Nuolatinė vertinimo klaida — gavėjas negalėjo apdoroti tavo įrašo (per daug užklausų, keli įrašai arba sulaužyta sintaksė) ir laiko tavo domeną neturinčiu naudotino SPF. DMARC tai skaičiuoja kaip SPF pusės nesėkmę.

Kiek domenų viršija SPF užklausų ribą? Bent 797,263 iš 139 milijonų SPF publikuotojų, pagal mūsų grandinių kainodaros analizę — apie 100× daugiau nei 7,958, matomi neišsprendus grandinių. Dar 2,119,539 yra ties 9–10 užklausų, per vieną include nuo ribos.

Ar PermError sustabdo mano el. laiškų pristatymą? Paprastai ne — gavėjai tęsia be SPF, o tavo paštas remiasi DKIM ir reputacija. Kas nustoja veikti, yra apsauga: klastotojai nebeatmetami, o kiekviena tavo pašto DMARC patikra praranda savo SPF pusę. Tai nematoma, kol netampa brangu.

Kaip sumažinti savo SPF užklausų skaičių? Pašalink nenaudojamus include ir ptr, suplokštink savo paties infrastruktūrą į ip4:/ip6:, perkelk masinius siuntėjus į subdomenus ir perskaičiuok po kiekvieno naujo įrankio. Taisymo vadovas tai išaiškina žingsnis po žingsnio.

Sužinok savo tikrąjį skaičių

Mechanizmai, kuriuos matai, nėra tavo užklausų skaičius — išspręstas skaičius yra tas, kurį apskaičiuoja gavėjai, ir tai 30 sekundžių patikra.

Patikrink savo domeną → · Pataisyk SPF → · SPF brandos modelis → · Du SPF įrašai = nė vieno → · ptr spąstai → · Tik agreguoti duomenys. Duomenys saugomi ir apdorojami ES.