Defaults.Exposed › Opravy › Guides

SPF PermError: Jak opravit „příliš mnoho DNS vyhledávání" bez přerušení e-mailu (2026)

Publikováno 2026-07-08

Údaje k 2026-06-29 · metodologie v7. Souhrnná data ze sčítání napříč 261 miliony ohodnocených domén. Viz jak hodnotíme.

Nejméně 797,263 domén překračuje limit 10 DNS vyhledávání SPF, podle sčítání Defaults.Exposed zahrnujícího 261,086,232 domén — z 139 milionů vydavatelů SPF. Po deseti vyhledáváních se příjemce zastaví a vrátí PermError: vaše SPF je neplatné a DMARC počítá PermError jako selhání.

Oprava má přísné pořadí a většina průvodců ho má pozpátku. Spočítejte vaše skutečná, rozluštěná vyhledávání; odstraňte mrtvé a nepoužívané include — to samo opraví většinu záznamů; přesuňte hromadné odesílatele na subdomény s vlastním SPF rozpočtem; vyrovnávejte pouze jako poslední možnost a pouze s automatizovaným přecerovnáváním, protože statické vyrovnávání shnívá a tiše ničí doručování.

Co znamená „SPF PermError: příliš mnoho DNS vyhledávání”?

RFC 7208 §4.6.4 omezuje každou kontrolu SPF na 10 DNS vyhledávání. Po deseti se příjemce zastaví a vrátí PermError — celý záznam je považován za rozbity, nejen část nad limitem. Stejná sekce přidává méně známý druhý strop: maximálně 2 „prázdná vyhledávání” (dotazy vracející žádnou odpověď nebo NXDOMAIN), takže pár mrtvých záznamů include: pro zrušené služby může samo o sobě zneplatnit vaše SPF.

Důsledek je horší než „žádné SPF”: DMARC považuje PermError za selhání SPF, takže doména, která si sama rozbije SPF, je neautentizovaná na SPF větvi každého vyhodnocení DMARC. Pokud DKIM není nastaveno nebo se v průvozu poruší, pošta nyní selhává DMARC úplně.

Jedno číslo ze sčítání ukazuje, jak krutý tento způsob selhání je: 112,215 domén publikuje přísný záznam -all, který je neplatný kvůli přetečení vyhledávání — z 54,655,923 domén, které vůbec publikují -all. Jejich vlastníci udělali tu těžkou část — zvolili přísné zakončení — a o jeden include navíc celý záznam vypnuli. Vypadají přísně; jsou rozbitiý. Pro celkový datový obraz viz zpráva o SPF PermError.

Proč se mi SPF rozbilo, když jsem nic nezměnil?

Protože rozpočet z velké části utrácejí záznamy jiných lidí. Každý include: se vyhodnocuje rekurzivně a každý vyhledávací mechanismus uvnitř něj se počítá vůči vašim deseti. Jeden řádek ve vašem DNS panelu může stát čtyři nebo pět vyhledávání po rozluštění. Poskytovatel vnestí ještě jeden include a vaše SPF zemře bez jediné změny ve vaší zóně.

Velké platformy nejsou problémem: Google i Microsoft si vyrovnali vlastní SPF — _spf.google.com a spf.protection.outlook.com expandují na prosté IP seznamy stojící nula interních vyhledávání (ověřeno vůči živému DNS, červenec 2026). Skutečné havárie přicházejí z vnořených řetězců include hostingových panelů a z poctivého skládání SaaS — poštovní schránka plus newsletter plus CRM plus helpdesk, každý „pouze jeden include”. Nikdo záměrně nepřidá jedenácté vyhledávání; přijde jako součet rozumných rozhodnutí. Proto je hranice tak přeplněná: 2,119,539 domén stojí přesně na 9–10 rozluštěných vyhledáváních — přibližně 1 z 66 všech vydavatelů SPF, dnes v pořádku, neplatné den, kdy někdo vloží ještě jeden include. 99. percentil SPF záznamu se již rozlušťuje na 9 vyhledávání. Pokud je váš zásobník na SaaS náročný, průvodce SPF selhávajícím pro SaaS nástroje pokrývá verzi dle dodavatele.

Které části SPF záznamu se počítají jako DNS vyhledávání?

Počítejte rozluštěný součet, nikoli viditelné řádky. Čtyři include mohou být čtyři vyhledávání nebo čtrnáct.

Jak opravím „příliš mnoho DNS vyhledávání” bez přerušení e-mailu?

1. Spusťte bezplatnou kontrolu před dotykem DNS. Rozluští váš celý řetězec include a ukáže váš skutečný počet vyhledávání, takže opravíte skutečný problém — nikoli záznam tak, jak se jeví ve vašem panelu. (Pokud říká, že nemáte SPF vůbec, jde o jiné selhání — viz „SPF záznam nenalezen”.)
2. Nejprve odstraňte mrtvé a nepoužívané include. Nástroj, který jste opustili v roce 2023, include starého hostitele, který přežil migraci, duplicity, jakýkoliv mechanismus ptr. Mrtvé include jsou dvojnásob toxické: spalují rozpočet vyhledávání a jsou obvyklým zdrojem prázdných vyhledávání. Většina přetížených záznamů se dostane pod 10 v tomto kroku samotném. Pokud váš záznam stále nese mechanismy předchozího poskytovatele, postupujte dle průvodce čištění po migraci.
3. Zkontrolujte, zda každý zbývající include dělá cokoliv. Příjemci vyhodnocují SPF vůči doméně Return-Path (RFC5321.MailFrom), nikoli záhlaví From — a mnoho SaaS nástrojů vkládá svou vlastní bounce doménu do Return-Path, takže jejich include ve vašem záznamu nedělá nic kromě utrácení rozpočtu. Ponechte include pouze pro služby, které používají vaši doménu jako Return-Path; pro zbytek místo toho povolte DKIM vlastní domény dodavatele.
4. Přesuňte hromadné odesílatele na subdomény. Newslettery z news.vasedomena.cz, transakční pošta z mail.vasedomena.cz. Každá subdoména dostane vlastní SPF záznam s čerstvým rozpočtem 10 vyhledávání a problém v jednom proudu přestane přetékat do ostatních.
5. Teprve poté zvažte vyrovnávání — a pouze automatizované vyrovnávání. Viz níže.
6. Znovu zkontrolujte a potvrďte, že jste pohodlně pod 10 — cílem je headroom, ne přesně 10, jinak jste se právě znovu připojili k 2.1 milionům domén na hraně. Poté propracujte vše ostatní, co kontrola označí, na stránce opravit SPF.

Mám vyrovnat svůj SPF záznam?

Vyrovnávání nahrazuje include jejich podkladovými bloky ip4:/ip6:, které stojí nula vyhledávání. Funguje — a ruční provedení je časovaná bomba výpadku doručování.

Poskytovatelé rutinně rotují odesílací IP adresy a nikoho o tom neinformují. Statický seznam IP je správný v den, kdy ho vložíte, a tiše špatný do několika měsíců — a protože selhání se projevuje jako nedoručování jiným lidem vaší pošty, zjistíte to pozdě. Pokud prořezání a subdomény dostanou váš záznam pod limit, zastavte se tam; nikdy nekopírujte IP bloky třetích stran do svého záznamu jako trvalou opravu.

Nejčastější dotazy

Znamená SPF PermError, že moje e-maily přestanou být doručovány? Nikoliv okamžitě — to je to, co ho dělá nebezpečným. DMARC počítá PermError jako selhání SPF, takže doručování plně závisí na DKIM; pokud DKIM chybí nebo se v průvozu poruší, selhává DMARC. Z 139 milionů vydavatelů SPF v našem sčítání (k 2026-06-29) je nejméně 797,263 v tomto stavu — většina o tom neví.

Můj záznam má pouze čtyři include — jak může být nad 10 vyhledávání? Include se počítají rekurzivně: vše uvnitř každého include (a uvnitř jeho include) se účtuje vašemu rozpočtu, takže čtyři viditelné řádky se mohou rozluštit na čtrnáct vyhledávání. Počítejte pomocí rozlušťovacího nástroje, nikoli od oka — rozluštění řetězců je způsob, jakým naše zpráva o PermError nalezla ~100× více rozbitých domén, než povrchové počty ukazují.

Končím záznam s -all — nejsem tedy chráněn? Pouze pokud se záznam vyhodnotí. Naše sčítání (k 2026-06-29) nalezlo 112,215 domén, jejichž přísné záznamy -all jsou neplatné kvůli přetečení vyhledávání. Přísný kvalifikátor na záznamu PermError nic nechrání.

Je limit 10 vyhledávání per include nebo pro celý záznam? Pro celé vyhodnocení: RFC 7208 §4.6.4 omezuje kompletní kontrolu na 10, plus maximálně 2 prázdná vyhledávání. Každá subdoména má vlastní záznam a rozpočet — proto krok 4 funguje.

Počítají se záznamy ip4 a ip6 vůči limitu? Ne — IP mechanismy nestojí nic, proto vyrovnávání snižuje počet.

Pošlete vlastníkovi zprávu

Pokud toto opravujete pro klienta nebo zaměstnavatele, dokončete práci s důkazem. Znovu spusťte bezplatnou kontrolu po svých změnách a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: srozumitelně, s datem, PermError pryč. To je artefakt, který budou potřebovat pro obnovení kybernetického pojištění a příští dotazník bezpečnosti zákazníka — rozdíl mezi „změnil jsem nějaké DNS záznamy” a zdokumentovaným stavem před a po.

Zkontrolujte svou doménu zdarma

Zjistěte svůj skutečný, rozluštěný počet vyhledávání — a vše ostatní ohledně SPF, DKIM a DMARC — soukromě a pouze pro vlastníky.

Zkontrolujte svou doménu → · Opravit SPF → · SPF selhává pro SaaS nástroje → · Nastavit SPF na GoDaddy → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.