Defaults.Exposed › Javítások › Guides

SPF PermError: Hogyan javítsa a „Túl sok DNS-keresés" hibát az e-mailek megszakítása nélkül (2026)

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

Adatok: 2026-06-29 · módszertan v7. Összesített cenzusadatok 261 millió értékelt domain alapján. Lásd: hogyan osztályozunk.

Legalább 797,263 domain lépi túl az SPF 10 DNS-keresésből álló korlátját a Defaults.Exposed 261,086,232 domaincenzusza szerint — 139 millió SPF-közzétevőből. Tíz keresés felett a fogadó leállítja és PermError-t ad vissza: az SPF érvénytelen, és a DMARC a PermError-t hibának számítja.

A javításnak szigorú sorrendje van, és a legtöbb útmutató fordítva csinálja. Számba kell venni a valódi, feloldott kereséseket; törölni a halott és nem használt include-okat — ez egyedül a legtöbb rekordot megjavítja; a tömeges küldőket saját SPF-költségvetéssel rendelkező aldomainekre kell helyezni; és csak végső esetben szabad simítani, és csak automatizált újrasimítással, mert a statikus simítás romlik és csendesen tönkreteszi a kézbesítést.

Mit jelent az „SPF PermError: túl sok DNS-keresés”?

Az RFC 7208 §4.6.4 minden SPF-ellenőrzést 10 DNS-keresésre korlátozza. Tízen túl a fogadó leállítja és PermError-t ad vissza — az egész rekordot törttnek tekinti, nem csak a túlköltségvetett részt. Ugyanez a szakasz egy kevésbé ismert második korlátot is megad: legfeljebb 2 „üres keresés” (NXDOMAIN-t vagy választ nem adó lekérdezések), tehát néhány halott include: lemondott szolgáltatásokhoz egymagában is érvénytelenítheti az SPF-et.

A következmény rosszabb, mint a „nincs SPF”: a DMARC a PermError-t SPF-hibaként kezeli, tehát az a domain, amely tönkreteszi a saját SPF-jét, minden DMARC-értékelés SPF-lábán hitelesítetlen. Ha a DKIM nincs beállítva, vagy átvitel közben meghibásodik, a levél most teljes mértékben megbukik DMARC-on.

Egy cenzuszadat mutatja meg, mennyire kegyetlen ez a hibamód: 112,215 domain tesz közzé szigorú -all rekordot, amely keresési túlcsordulás miatt érvénytelen — a -all-t egyáltalán közzétevő 54,655,923 domainből. Tulajdonosaik elvégezték a nehéz részt — a szigorú végzáradékot választották — és egy extra include kikapcsolta az egész rekordot. Szigorúnak látszanak; töröttek. A teljes adatképért lásd: az SPF PermError-jelentés.

Miért romlott el az SPF-em, ha nem változtattam semmit?

Mert a költségvetést nagyrészt mások rekordjai emésztik fel. Minden include: rekurzívan kiértékelődik, és az abban lévő minden keresési mechanizmus a tízes korlát ellen számít. A DNS-panelen egyetlen sor négy-öt keresésbe kerülhet, amint feloldódik. Egy szolgáltató eggyel több include-ot ágyaz be, és az SPF megsérül egyetlen változtatás nélkül a saját zónájában.

A nagy platformok nem a probléma: a Google és a Microsoft egyaránt simította a saját SPF-jét — a _spf.google.com és a spf.protection.outlook.com nulla belső keresést igénylő, egyszerű IP-listákká bővül ki (élő DNS-sel ellenőrizve, 2026 júliusában). A valódi robbanások mélyen egymásba ágyazott tárhelykezőpanel-include-láncokból és becsületes SaaS-halmozásból erednek — postafiók plusz hírlevél plusz CRM plusz helpdesk, mindegyik „csak egy include”. Senki nem szándékosan adja hozzá a tizenegyedik keresést; az ésszerű döntések összegeként érkezik. Ezért olyan zsúfolt a sziklaél: 2,119,539 domain pontosan 9–10 feloldott keresésénél ül — nagyjából 1 a 66 arányban az összes SPF-közzétevőből, ma rendben van, holnap érvénytelen, ha valaki beilleszt még egy include-ot. A 99. percentilis SPF rekord már 9 keresésre oldódik fel. Ha a szoftverhalmaza SaaS-nehéz, a SaaS-eszközöknél meghiúsuló SPF útmutatója szállítónkénti változatot tárgyal.

Az SPF-rekord mely részei számítanak DNS-keresésnek?

A feloldott végösszeget számlálja, nem a látható sorokat. Négy include lehet négy vagy tizennégy keresés.

Hogyan javítsa a „túl sok DNS-keresés” hibát az e-mailek megszakítása nélkül?

1. Futtassa az ingyenes vizsgálatot a DNS megérintése előtt. Feloldja a teljes include-láncot, és megmutatja a valódi keresésszámot, így a tényleges problémát javítja — nem a panelen látható rekordot. (Ha azt mondja, hogy egyáltalán nincs SPF-je, az egy másik hiba — lásd: „SPF-rekord nem található”.)
2. Először törölje a halott és nem használt include-okat. A 2023-ban ejtett eszköz, a régi gazdagép include-ja, amely áttelepítés után megmaradt, duplikátumok, minden ptr mechanizmus. A halott include-ok kétszeresen mérgezők: keresési költségvetést égetnek és ők a szokásos forrásai az üres kereséseknek. A legtöbb túlköltségvetett rekord csak ezzel a lépéssel visszakerül 10 alá. Ha a rekord még mindig tartalmazza egy korábbi szolgáltató mechanizmusait, kövesse a migrációs tisztítási útmutatót.
3. Ellenőrizze, hogy minden megmaradó include csinál-e valamit. A fogadók az SPF-et a Return-Path (RFC5321.MailFrom) domainnel szemben értékelik, nem a From fejléccel — és sok SaaS-eszköz a saját visszapattanó domainjét helyezi a Return-Path-ba, tehát az Ön rekordjában lévő include semmit nem tesz, csak költségvetést költ el. Csak azon szolgáltatások include-jait tartsa meg, amelyek a domainjét használják Return-Path-ként; a többi esetén inkább a szállító egyéni domainű DKIM-jét engedélyezze.
4. Helyezze a tömeges küldőket aldomainekre. Hírlevelek a news.yourdomain.com-ról, tranzakciós levelek a mail.yourdomain.com-ról. Minden aldomain saját SPF-rekordot kap friss 10-keresésű költségvetéssel, és az egyik adatfolyamban fellépő probléma nem vérzik át a többire.
5. Csak ezután fontolja meg a simítást — és csak automatizált simítást. Lásd alább.
6. Szkennelje újra, hogy megerősítse, hogy kényelmesen 10 alatt van — célozzon mozgástérre, ne pontosan 10-re, különben visszacsatlakozik a sziklaélen ülő 2.1 millió domainhez. Majd dolgozzon át mindent, amit a vizsgálat jelez az SPF javítása oldalon.

Simítsam az SPF-rekordomat?

A simítás felváltja az include-okat az alapjukat képező ip4:/ip6: blokkokkal, amelyek nulla keresésbe kerülnek. Működik — és kézzel elvégezve késleltetett kézbesítési leállás.

A szolgáltatók rutinszerűen forgatják a küldő IP-ket, és ezt senkinek nem közlik. Egy statikus IP-lista helyes azon a napon, amikor beilleszti, és csendesen hibás hónapokon belül — és mivel a hiba úgy jelenik meg, hogy mások nem kapják meg az Ön leveleit, Ön késve értesül róla. Ha a tisztítás és az aldomainek a határon belülre hozzák a számot, álljon meg; soha ne másolja kézzel egy harmadik fél IP-blokkjait a saját rekordjába állandó megoldásként.

Gyakran ismételt kérdések

Az SPF PermError azt jelenti, hogy leáll a kézbesítés? Nem azonnal — ez az, ami veszélyessé teszi. A DMARC a PermError-t SPF-hibaként számítja, tehát a kézbesítés teljes mértékben a DKIM-re támaszkodik; ha a DKIM hiányzik vagy átvitel közben meghibásodik, DMARC-on is hibázik. A cenzuszunk 139 millió SPF-közzétevőjéből (2026-06-29 szerint) legalább 797,263 van ebben az állapotban — legtöbbjük anélkül, hogy tudna róla.

A rekordomon csak négy include van — hogyan lehet 10-nél több keresés? Az include-ok rekurzívan számítódnak: minden include-on belüli minden elem (és az azon belüli include-okon belüli elemek) a saját költségvetése terhére számítódik, tehát négy látható sor tizennégy keresésre oldódhat fel. Feloldó eszközzel számoljon, ne szemmel — a láncok feloldása az, ahogy a PermError-jelentésünk ~100× annyi törött domaint talált, mint amennyit a felszíni számlálás mutat.

-all-lal zárom a rekordomat — biztosan védett vagyok? Csak ha a rekord kiértékelődik. A cenzuszunk (2026-06-29) 112,215 domaint talált, amelynek szigorú -all rekordja keresési túlcsordulás miatt érvénytelen. Egy PermError rekordon lévő szigorú záradék semmit nem véd.

A korlát keresésenkénti 10, vagy az egész rekordra vonatkozik? Az egész kiértékelésre: az RFC 7208 §4.6.4 az összes ellenőrzést 10-re, plusz legfeljebb 2 üres keresésre korlátozza. Minden aldomain saját rekorddal és költségvetéssel rendelkezik — ezért működik a 4. lépés.

Számítanak-e az ip4 és ip6 bejegyzések a korlát felé? Nem — az IP-mechanizmusok semmibe sem kerülnek, és pontosan ezért csökkenti a simítás a számot.

Küldje el a tulajdonosnak a jelentést

Ha ezt egy ügyfélnek vagy munkaadójának javítja, fejezze be bizonyítékkal. A módosítások után futtassa újra az ingyenes vizsgálatot, és továbbítsa az értékelt jelentést a cégtulajdonosnak: egyszerű nyelven, dátummal, a PermError eltűnt. Ez az a dokumentum, amelyre a kiberbizosítás megújításakor és a következő vevői biztonsági kérdőívnél szükségük lesz — a különbség „megváltoztattam néhány DNS-rekordot” és egy dokumentált előtte-utána között.

Ellenőrizze domainjét ingyen

Nézze meg a valódi, feloldott keresési számát — és mindent, ami az SPF-et, DKIM-et és DMARC-ot érinti — privát módon, csak a tulajdonos számára.

Ellenőrizze domainjét → · SPF javítása → · SaaS-eszközöknél meghiúsuló SPF → · SPF beállítása GoDaddy-n → · Hogyan osztályozunk → · Csak összesített adatok. Az adatok tárolása és feldolgozása az EU-ban történik.