Az SPF PermError-jelentés: 100× több domain lépi túl a 10-lekérdezéses limitet, mint amennyit a felszíni számok mutatnak (2026)

Q: Hogyan csökkentsem az SPF-lekérdezésszámomat?

Távolítsd el a nem használt include-okat és a ptr-t, lapítsd ki a saját infrastruktúrádat ip4:/ip6:-ra, mozgasd a tömeges küldőket aldomainekre, és számolj újra minden új eszköz után. A javítási útmutató végigvezet rajta.

Közzétéve 2026-07-03

Adatok eddig: 2026-06-29 · v7-es módszertan, plusz egy lánc-árazási menet, amelyet ekkor futtattunk: 2026-07-03. A 261 millió osztályozott domain censusából feloldottunk minden olyan SPF include: célt, amelyre 100-szor vagy többször hivatkoztak — 10,842 célt, amelyek az összes include-hivatkozás 95.2%-át fedik le —, és e térkép alapján beáraztuk minden domain megőrzött láncát. A feloldatlan farok-célok nullaként számítottak, a lánctartalmak pedig a feloldás napját tükrözik, így a főszám konzervatív, alulról becsült közelítés: azt mondjuk, „legalább”. Csak aggregált adat; sosem egy adott vállalkozás rekordja. Lásd: hogyan osztályozunk.

Hány domain lépi túl az SPF 10-lekérdezéses limitjét?

Legalább 797,263 — mert az SPF-be egy önmegsemmisítő van beépítve a szabványba, és a kioldó ott rejtőzik, ahol a tulajdonosok nem látják. Az RFC 7208 §4.6.4 legfeljebb 10 DNS-lekérdezésre korlátoz egy SPF-ellenőrzést; a tizedik után a fogadó leáll, és PermError-t ad vissza, egy PermError-rekord pedig semmit sem véd. Ha csak a magában a rekordban látható lekérdezéseket számoljuk — ahogy a legtöbb eszköz teszi, és ahogy a saját censusunk is tette e jelentésig —, akkor nagyjából 8 000 vétkest találunk (pontosan 7,958). Ha beárazzuk azokat az include: láncokat, amelyeket e rekordok valójában behúznak, a szám eléri a 797,263-t: nagyjából 100-szer többet.

Miért nem látják előre a tulajdonosok?

Mert a keretet mások rekordjai költik el. Az include:onetool.example.com egyetlen sorként jelenik meg a DNS-paneleden — de a fogadónak azt a rekordot is le kell kérnie, és rekurzívan meg kell számolnia minden lekérdezési mechanizmust, amit az tartalmaz. Egy három include-ot tartalmazó rekord tizenegybe is kerülhet. A saját zónádban semmi sem változott azon a napon, amikor túllépted a limitet; egy szolgáltató beágyazott még egy include-ot, és az SPF-ed figyelmeztetés nélkül elpusztult.

Ráadásul a DMARC a PermErrort SPF-oldali bukásként kezeli — így egy domain, amely így törte szét az SPF-jét, most a saját hitelesítésének a felében bukik.

Mit talált a lánc-árazás

Megállapítás	Domainek
A 10-lekérdezéses limit felett, láncok beárazva	797,263
A limit felett, csak a látható mechanizmusokat számolva	7,958
A limit felett, miközben szigorú `-all`-lal végződik	112,215
Pontosan 9–10 lekérdezésnél — a szakadék peremén	2,119,539

Két történet van abban a táblázatban — a harmadik, a szakadék pereme, saját szakaszt kap alább:

A felszíni számolás a hiba ~99%-át elmulasztja. A látható mechanizmusok számolása 7,958-t talál; a láncok beárazása 797,263-t. A kár szinte teljes egésze abból öröklődik, amit az include-ok maguk is behúznak.
A szétesett rekordok közül 112,215 -all-lal végződik. Tulajdonosaik mindent jól csináltak — felmásztak a falon, a szigorú lezárást választották —, és egyetlen include-dal több semmisített meg mindent. A szigorúnak tűnő, de szétesett a legkegyetlenebb bukási mód az e-mail-biztonságban.

2.1 millió domain egyetlen eszközre van a szakadéktól

A szám, amely aggasztania kellene azokat az olvasókat, akik jelenleg rendben vannak: 2,119,539 domain pontosan 9 vagy 10 lekérdezésre oldódik fel — ma a limit alatt, halott azon a napon, amikor valaki még egy platformot bekapcsol. Ez nagyjából minden 66. SPF-közzétevőből egy, és illeszkedik az eloszlás alakjához: a 99. percentilis SPF-rekord már most 9 lekérdezésnél áll. Iratkozz fel még egy marketingeszközre, illeszd be a „csak add hozzá ezt az include-ot” sorát, és egy rekord, amely reggelinél még a limit alatt volt, ebédre érvénytelen.

Kinek a hibája? Egyre inkább a stacké

A legnagyobb szolgáltatók csendben kilapították az SPF-jüket — a Google _spf.google.com-ja és a Microsoft spf.protection.outlook.com-ja most nulla belső lekérdezésbe kerülő, egyszerű IP-listákká bomlik ki (mindkettőt ellenőriztük az élő DNS ellenében ezen elemzés során). A kirobbanások máshonnan jönnek: hosting-panel-láncokból, amelyek három szintbe ágyazódnak, regionális szolgáltatókból, amelyek include-ja önmagában 7–10 lekérdezésbe kerül, és a SaaS őszinte felhalmozódásából — postafiók plusz hírlevél plusz CRM plusz ügyfélszolgálat, mindegyik „csak egy include”. Szinte senki sem adja hozzá a tizenegyedik lekérdezést szándékosan. Az ésszerű döntések összegeként érkezik.

Hogyan ellenőrizd és javítsd a sajátodat — ingyen

Számold ki a valós összeget — az ingyenes ellenőrzésünk feloldja a láncodat, vagy használj bármilyen SPF-lekérdezésszámlálót.
Vágd le a holt terhet: eszközök, amelyeket már nem használsz, duplikált include-ok, és az elavult ptr mechanizmus.
Csak azt lapítsd ki, amit te irányítasz. Egy mély include lecserélése az IP-blokkjaira a saját infrastruktúrádnál működik; a harmadik felek IP-i értesítés nélkül változnak.
Adj a tömeges küldőknek aldomaint. A news.yourdomain.com-ról érkező hírlevelek saját rekordot és saját 10-lekérdezéses keretet kapnak.

Gyakran ismételt kérdések

Mi az SPF 10 DNS-lekérdezéses limitje? Az RFC 7208 §4.6.4 legfeljebb 10 DNS-lekérdezést engedélyez egy SPF-rekord kiértékeléséhez — beleszámítva minden include: belsejében lévő lekérdezéseket, rekurzívan. Túllépése PermErrort ad vissza: a rekord érvénytelennek minősül, és nem nyújt védelmet.

Mit jelent az SPF PermError? Egy állandó kiértékelési hiba — a fogadó nem tudta feldolgozni a rekordodat (túl sok lekérdezés, több rekord vagy hibás szintaxis), és úgy kezeli a domainedet, mintha nem lenne használható SPF-je. A DMARC ezt SPF-oldali bukásként számolja.

Hány domain lépi túl az SPF-lekérdezési limitet? A lánc-árazási menetünk szerint a 139 millió SPF-közzétevőből legalább 797,263 — nagyjából 100× annyi, mint a láncok feloldása nélkül látható 7,958. További 2,119,539 9–10 lekérdezésnél áll, egyetlen include-ra a limittől.

A PermError megakadályozza az e-mailjeim kézbesítését? Általában nem — a fogadók SPF nélkül folytatják, és a leveled a DKIM-en és a reputáción utazik. Ami leáll, az a védelem: a hamisítókat többé nem utasítják el, és a leveled minden DMARC-ellenőrzése elveszíti az SPF-oldalát. Láthatatlan, egészen addig, amíg drágává nem válik.

Hogyan csökkentsem az SPF-lekérdezésszámomat? Távolítsd el a nem használt include-okat és a ptr-t, lapítsd ki a saját infrastruktúrádat ip4:/ip6:-ra, mozgasd a tömeges küldőket aldomainekre, és számolj újra minden új eszköz után. A javítási útmutató végigvezet rajta.

Tudd meg a valós számodat

A mechanizmusok, amelyeket látsz, nem a lekérdezésszámod — a feloldott szám az, amit a fogadók kiszámolnak, és ez egy 30 másodperces ellenőrzés.

Ellenőrizd a domainedet → · SPF javítása → · Az SPF-érettségi modell → · Két SPF-rekord = egy sem → · A ptr-csapda → · Csak aggregált adat. Az adatokat az EU-ban tároljuk és dolgozzuk fel.