Defaults.Exposed › Ataskaitos

Kodėl mano SPF nepavyksta? SaaS 10 užklausų problema JK ir ES siuntėjams (2026)

Paskelbta 2026-07-09

Skaičiai nuo 2026-06-29 · metodika v7. Suvestiniai surašymo duomenys apie 261 mln. įvertintų domenų. Žiūrėkite, kaip mes vertiname.

Kai SPF nepavyksta JK ar ES esančiai įmonei, naudojančiai SaaS įrankius, labiausiai tikėtina priežastis yra viena RFC taisyklė, apie kurią niekada neturėjote galvoti: viršijus 10 DNS užklausų, SPF negrąžina „klaidos” — jis grąžina PermError, o tai reiškia, kad įrašas laikomas neegzistuojančiu. Mažiausiai 797,263 domenų jau peržengė šią ribą. Dar 2,119,539 stovi ties lygiai 9–10 užklausomis — vienas naujas įrankis pakanka, kad juos nustumtų nuo to paties skardžio.

Kodėl SPF subyra, kai pridedate SaaS įrankį?

SPF veikia išvardindamas el. pašto serverius, kuriems suteikta teisė siųsti jūsų domeno vardu. Šiuolaikinės įmonės paprastai nenaudoja savo el. pašto serverių — jos naudoja Google Workspace vidiniam el. paštui, Mailchimp kampanijoms, HubSpot pardavimų sekoms, Pipedrive CRM komunikacijai. Kiekviena platforma suteikia include: eilutę, kurią reikia įklijuoti į DNS.

Problema tokia: kiekvienas include: pats savaime yra DNS užklausa. Ir kiekvienas įrašas to include viduje gali rekursyviai sukelti daugiau užklausų. RFC 7208 §4.6.4 nustato griežtą dešimties viršutinę ribą. Ją viršijus, priimantis el. pašto serveris sustabdo vertinimą ir grąžina PermError — tai nėra minkšta klaida, kuri baigiasi šlamštu. Tai reiškia, kad jūsų SPF įrašas laikomas neegzistuojančiu. El. pašto autentifikavimas nepavyksta SPF dalyje.

To nematysite DNS valdymo skydelyje. Skaitiklis veikia tik tikrojo vertinimo metu. Jūsų matomame įraše gali būti trys include: eilutės, o vis tiek esate dvylikos užklausų gylyje, nes kiekvieno tiekėjo SPF įrašas traukia savus sub-include.

Kiek domenų jau viršijo ribą?

Mažiausiai 797,263. Tai skaičius po to, kai išsprendėme kiekvieną SPF include: tikslą, kuris nurodytas 100 ar daugiau kartų — 10,842 skirtingi taikiniai, apimantys 95.2% visų include nuorodų — ir kainodaros kiekvienam domenui pilną grandinę. Paviršinis skaičiavimas (tai, ką rastumėte skaičiuodami tik matomus įrašo eilutes) randa maždaug 7,958. Grandinės kainodaros skaičius yra 100 kartų didesnis, nes beveik visi nuostoliai yra nematomi include tikslų viduje.

Situacija, kuri labiausiai tikėtina paveikti Europos įmonę:

Europos prieglobstos teikėjai ir silpni SPF numatytieji nustatymai

Prieglobstos teikėjas, su kuriuo pradėjote, yra svarbus — nes kai kurie nustato SPF numatytuosius parametrus, kurie jau sunaudoja kelis iš jūsų dešimties užklausų, prieš prijungiant vieną SaaS įrankį.

Tarp didžiausių prieglobstos teikėjų, kuriuos naudoja Europos domenai mūsų surašyme:

IONOS išsiskiria: tik 1.0% IONOS laikomų domenų turi vykdantį DMARC, o tai reiškia, kad didžioji dauguma iš viso neturi prasmingo siuntėjo autentifikavimo. OVH domenai geriau veikia pagal griežtą SPF nustatymą (43.7%), tačiau krenta iki 2.2% pagal DMARC vykdymą — SPF vienas, be DMARC, kuris susieja jį su From: antrašte, saugo tik voką, o ne tai, ką mato gavėjas.

Microsoft 365 yra teigiama išimtis: 85.0% Microsofto laikomų domenų naudoja griežtą SPF, daugiausia todėl, kad Microsofto pašto srauto vedlys pagal numatytuosius nustatymus nustato -all. Google Workspace pagal numatytuosius nustatymus nustato ~all (softfail), palikdamas 92% savo domenų be griežtos apsaugos.

Kaip diagnozuoti SPF gedimą per mažiau nei 60 sekundžių

Greičiausias patikrinimas yra nemokamas įrankis, kuris vertina visą užklausų grandinę, o ne tik matomą įrašą. Komandinėje eilutėje paleiskite nslookup -type=TXT yourdomain.com ir suskaičiuokite visus include:, kuriuos matote. Tada ieškokite kiekvieno iš tų įrašų ir suskaičiuokite jų. Jei pirštai baigiasi prieš pasibaigiant include’ams, esate pavojaus zonoje.

Patikimesnis būdas: patikrinkite savo domeną čia — skaitytuvas įvertina visą išspręstą grandinę, pažymi PermError ir parodo, kurie mechanizmai sunaudoja jūsų užklausų biudžetą.

Trys diagnostikos rezultatai:

• PermError — jau viršijote dešimt. Kiekvienas el. laiškas, kurį siunčiate, nepavyksta SPF patikrinimo gavėjo pusėje.
• Ties 9–10 užklausomis — esate prie skardžio. Kita SaaS integracija jus pastums.
• Softfail (~all) vietoje hardfail (-all) — esate žemiau ribos, bet įrašas nustatytas pernelyg laisvai, kad suteiktų realią apsaugą. Žiūrėkite SPF klaidingos konfigūracijos ataskaitą dėl išsamaus vaizdo apie -all ir ~all.

Kaip pataisyti SPF naudojant kelis SaaS įrankius

Yra trys požiūriai, išvardyti pagal pastovumą:

1. Auditas ir genėjimas. Pradėkite išvardindami kiekvieną include: dabartiniame įraše. Pašalinkite bet kokią platformą, kurios nebenaudiote — senus ESP, CRM įrankius iš ankstesnių sutarčių, platformas, kurias išbandėte, bet atsisakėte. Tai nemokama ir dažnai atgauna kelias užklausas. Kiekvienas pašalintas include: gali pašalinti 1–3 sub-užklausas.

2. SPF įrašo išlyginimas. SPF išlyginimas išsprendžia visus include: tikslus į jų bazines IP sritis ir rašo jas tiesiogiai į jūsų įrašą kaip ip4: ir ip6: mechanizmus. IP mechanizmai nesukelia užklausų, todėl išlygintas įrašas gali išvardyti dešimtis siuntimo šaltinių ir vis tiek būti prie nulio užklausų. Trūkumas: reikia išlyginti iš naujo kiekvieną kartą, kai tiekėjas atnaujina savo siuntimo IP, o tai nutinka be pranešimo. Dauguma organizacijų naudoja mokamą SPF išlyginimo paslaugą (PowerDMARC, EasyDMARC, Dmarcian ir kiti tai siūlo) arba sukuria stebėjimo darbo eigą.

3. SPF makrosų naudojimas. RFC 7208 makrosai leidžia kurti įrašus, kurie atlieka vieną DNS užklausą kiekvienam patikrinimui ir atsako dinamiškai, o ne include grandinę. Makrosams reikalinga DNS prieglobstos palaikymas ir kiek diegimo pastangų, tačiau tai architektūriškai švarus sprendimas organizacijoms su daugeliu SaaS siuntėjų.

Pataisę SPF, suporuokite jį su DMARC vykdymu — SPF be DMARC autentifikuoja tik voko siuntėją, o ne antraštės From: adresą, kurį mato gavėjai.

Dažnai užduodami klausimai

Kodėl mano SPF įrašas praeina mano DNS įrankį, bet vis tiek nepavyksta el. pašto antraštėse? Dauguma DNS paieškos įrankių skaičiuoja tik jūsų paties įrašo matomus mechanizmus, o ne sub-užklausas, kurias tie mechanizmai sukelia. Galite turėti dvi include: eilutes ir vis tiek viršyti ribą, jei kiekvieno tiekėjo įrašas turi dar kelias. Tik grandinės kainodaros įrankis (arba priimantis el. pašto serveris) suskaičiuoja visą gylį. Patikrinkite savo domeną norėdami pamatyti tikrą grandinės skaičių.

Ar SPF nepavykimas reiškia, kad mano el. laiškai keliaus į šlamštą? PermError (per daug užklausų) reiškia, kad autentifikavimo SPF dalis grąžina ne-rezultatą — faktiškai neegzistuojantį. DMARC vertina tiek SPF, tiek DKIM; jei DKIM praeina, DMARC vis tiek gali praeiti nepaisant SPF PermError. Jei nei vienas nepraeina, DMARC nepavyksta, o rezultatas priklauso nuo jūsų DMARC politikos. Esant p=none, el. laiškas vis tiek pristatomas, bet klaida registruojama žurnale. Esant p=quarantine arba p=reject, el. laiškas filtruojamas arba grąžinamas. Pataisykite SPF, kad nepriklausytumėte tik nuo DKIM.

Kiek užklausų naudoja tipinis SaaS paketas? Mūsų surašymo p99 SPF įrašas jau yra ties 9 užklausomis — tiesiai prie ribos — prieš ką nors pridedant. Google Workspace įrašas prideda 3–4 užklausas; Mailchimp prideda 1–2; HubSpot prideda 1–3, priklausomai nuo jų dabartinės konfigūracijos. Trys pagrindiniai įrankiai ir jūsų prieglobstos teikėjo numatytoji vertė dažnai pakanka viršyti dešimt.

Ar SPF išlyginimas yra saugus? Taip, su sąlyga, kad jį laikote atnaujintą. Išlyginimas konvertuoja include: grandines į statinius IP diapazonus — jei tiekėjas pasuka savo siuntimo IP ir nesulyginate iš naujo, pradėsite atmesti jų paštą. Dauguma organizacijų naudoja valdomą išlyginimo paslaugą, kuri stebi IP pokyčius, o ne prižiūri tai rankiniu būdu.

Mano SPF buvo toks jau daugelį metų — kodėl jis staiga pradeda nepavykti? Nes jūsų tiekėjai atnaujino savo SPF įrašus, o ne jūsiškius. Kiekvieną kartą, kai SaaS platforma prideda naują siuntimo IP diapazoną arba įdeda dar vieną include, jūsų grandinės kaina auga be jokių pokyčių iš jūsų pusės. 10 užklausų limitas vertinamas realiu laiku pranešimo gavimo metu, todėl antradienio ryto tiekėjo pokytis gali sugriauti jūsų SPF antradienio popietę.

Ar SPF taisymas pagerina el. pašto pristatymą? Tai pašalina autentifikavimo klaidos šaltinį, kuris yra nuoseklaus pristatymo išankstinė sąlyga — ypač nuo tada, kai Google ir Yahoo dabar vykdo DMARC suderinimą masiniams siuntėjams. SPF vienas nėra visas vaizdas: suporuokite jį su DKIM ir DMARC pilnam el. pašto autentifikavimui.

Patikrinkite savo SPF nemokamai

Jei nesate tikri, ar jūsų SPF įrašas viršija užklausų limitą — ar nustatytas pernelyg silpnai, kad apsaugotų jūsų domeną — atlikite nemokamą patikrinimą. Tai įvertina visą išspręstą grandinę ir tiksliai parodo, kur biudžetas leidžiamas.

Patikrinkite savo domeną → · Taisykite SPF → · SPF PermError ataskaita → · SPF klaidingos konfigūracijos ataskaita → · SPF diegimo brandos modelis → · Taisykite DMARC → · Tik suvestiniai duomenys. Duomenys saugomi ir tvarkomi ES.