Defaults.Exposed › Zprávy

Proč selhává můj SPF? Problém 10 DNS dotazů v prostředí SaaS pro odesílatele z UK a EU (2026)

Publikováno 2026-07-09

Údaje k 2026-06-29 · metodologie v7. Agregovaná data ze sčítání přes 261 milionů hodnocených domén. Viz jak hodnotíme.

Pokud SPF selhává u firmy využívající SaaS nástroje v UK nebo EU, nejpravděpodobnější příčinou je jedno pravidlo RFC, o kterém jste nikdy nemuseli přemýšlet: po překročení 10 DNS dotazů SPF nevrátí „fail” — vrátí PermError, což znamená, že záznam je zpracováván, jako by neexistoval. Nejméně 797,263 domén již tuto hranici překročilo. Dalších 2,119,539 se nachází přesně na 9–10 dotazech — jeden nový nástroj je dělí od stejného propadu.

Proč SPF selže, když přidáte SaaS nástroj?

SPF funguje tak, že vypisuje poštovní servery oprávněné odesílat zprávy jménem vaší domény. Moderní firmy neprovozují vlastní poštovní servery — používají Google Workspace pro interní e-mail, Mailchimp pro kampaně, HubSpot pro prodejní sekvence, Pipedrive pro CRM outreach. Každá platforma vám poskytuje řádek include:, který vložíte do DNS.

Problém: každé include: je samo o sobě DNS dotaz. A každý záznam uvnitř tohoto include může rekurzivně spustit další dotazy. RFC 7208 §4.6.4 stanoví pevný limit desíti. Po jeho překročení přijímající poštovní server přestane vyhodnocovat a vrátí PermError — a PermError není mírné selhání, které skončí ve spamu. Znamená to, že váš SPF záznam je považován za neexistující. Ověřování e-mailu selhává na části SPF.

Toto neuvidíte ve svém DNS panelu. Čítač se spouští pouze při živém vyhodnocení. Můžete mít tři řádky include: ve viditelném záznamu a stále být dvanáct dotazů hluboko, protože SPF záznam každého dodavatele načítá své vlastní pod-include.

Kolik domén již překročilo limit?

Nejméně 797,263. To je počet po vyřešení každého SPF include: cíle odkazovaného 100krát nebo více — 10,842 odlišných cílů pokrývajících 95.2% všech odkazů na include — a ocenění celého řetězce každé domény. Povrchový počet (co byste nalezli počítáním pouze viditelných řádků v záznamu) najde přibližně 7,958. Řetězcem oceněné číslo je 100krát větší, protože téměř veškeré škody jsou neviditelné uvnitř cílů include.

Situace, která nejčastěji postihuje evropskou firmu:

Evropští poskytovatelé hostingu a slabá výchozí nastavení SPF

Záleží na tom, od kterého poskytovatele hostingu jste začali — protože někteří nastavují výchozí SPF, která již spotřebují několik z vašich desíti dotazů dříve, než připojíte jediný SaaS nástroj.

Mezi největšími poskytovateli hostingu používanými evropskými doménami v našem sčítání:

IONOS vyniká: 1.0% domén hostovaných u IONOS má vynucující DMARC, což znamená, že drtivá většina nemá žádné smysluplné ověřování odesílatele vůbec. Domény OVH si vedou lépe u přísného nastavení SPF (43.7%), ale přesto klesají na 2.2% u vynucování DMARC — samotný SPF bez DMARC, které by ho svázalo s hlavičkou From:, chrání pouze obálku, nikoli to, co příjemce vidí.

Microsoft 365 je výjimkou v dobrém smyslu: 85.0% domén hostovaných u Microsoftu používá přísný SPF, zejména proto, že průvodce poštovním tokem Microsoftu nastavuje -all jako výchozí. Google Workspace nastavuje ~all (softfail) jako výchozí, což ponechává 92% jeho domén bez přísné ochrany.

Jak diagnostikovat selhání SPF za méně než 60 sekund

Nejrychlejší kontrola je bezplatný nástroj, který vyhodnocuje celý řetězec dotazů — nikoli jen viditelný záznam. Spusťte nslookup -type=TXT vasadomena.com v příkazovém řádku a spočítejte každé include:, které vidíte. Poté vyhledejte každý z těchto záznamů a spočítejte jejich. Pokud vám dojdou prsty dříve, než dojdou include, jste v nebezpečné zóně.

Spolehlivější přístup: zkontrolujte svou doménu zde — skener vyhodnocuje celý vyřešený řetězec, označí PermError a ukáže vám, které mechanismy spotřebovávají váš rozpočet dotazů.

Tři diagnostické výsledky:

• PermError — již jste překročili deset. Každý e-mail, který odešlete, selže v SPF kontrole u příjemce.
• Na 9–10 dotazech — jste na okraji. Další integrace SaaS vás překlene přes hranici.
• Softfail (~all) místo hardfail (-all) — jste pod limitem, ale záznam je nastaven příliš volně na to, aby poskytoval skutečnou ochranu. Viz zpráva o nesprávné konfiguraci SPF pro úplný přehled o -all vs ~all.

Jak opravit SPF při použití více SaaS nástrojů

Existují tři přístupy, v pořadí dle trvalosti:

1. Audit a prořezávání. Začněte výpisem každého include: ve svém aktuálním záznamu. Odstraňte jakoukoliv platformu, kterou již nepoužíváte — staré ESP, CRM nástroje z předchozích smluv, platformy, které jste testovali, ale opustili. To je zdarma a často obnoví několik dotazů. Každé odstraněné include: může eliminovat 1–3 pod-dotazy.

2. Sloučení SPF záznamu. Sloučení SPF vyřeší všechny include: cíle do jejich základních IP rozsahů a zapíše je přímo do záznamu jako ip4: a ip6: mechanismy. IP mechanismy nespouštějí dotazy, takže sloučený záznam může vypisovat desítky odesílacích zdrojů a stále být na nule dotazů. Nevýhoda: je nutné znovu sloučit pokaždé, když dodavatel aktualizuje své odesílací IP adresy, což se děje bez upozornění. Většina organizací používá placenou službu sloučení SPF (PowerDMARC, EasyDMARC, Dmarcian a další to nabízejí) nebo si buduje monitorovací pracovní postup.

3. Použití SPF maker. Makra RFC 7208 vám umožňují vytvářet záznamy, které provádějí jeden DNS dotaz na kontrolu a odpovídají dynamicky, místo řetězce include. Makra vyžadují podporu DNS hostingu a určité úsilí při implementaci, ale jsou architektonicky čistým řešením pro organizace s mnoha odesílateli SaaS.

Po opravě SPF ho spojte s vynucováním DMARC — SPF bez DMARC ověřuje pouze odesílatele obálky, nikoli adresu From: v záhlaví, kterou příjemci vidí.

Nejčastěji kladené otázky

Proč můj SPF záznam projde mým DNS nástrojem, ale stále selhává v záhlavích e-mailů? Většina nástrojů pro vyhledávání DNS počítá pouze mechanismy viditelné ve vašem vlastním záznamu, nikoli pod-dotazy, které tyto mechanismy spouštějí. Můžete mít dva řádky include: a stále být nad limitem, pokud záznam každého dodavatele obsahuje ještě několik dalších. Pouze nástroj pro ocenění řetězce (nebo přijímající poštovní server) počítá celou hloubku. Zkontrolujte svou doménu abyste viděli skutečný počet v řetězci.

Znamená selhání SPF, že moje e-maily putují do spamu? PermError (příliš mnoho dotazů) znamená, že část SPF ověřování vrátí výsledek bez závěru — fakticky neexistující. DMARC vyhodnocuje jak SPF, tak DKIM; pokud DKIM projde, DMARC může stále projít i přes SPF PermError. Pokud žádný z nich neprojde, DMARC selže a výsledek závisí na vaší politice DMARC. Při p=none se e-mail stále doručuje, ale selhání je zaznamenáno. Při p=quarantine nebo p=reject je e-mail filtrován nebo odmítnut. Opravte SPF, abyste nespoléhali pouze na DKIM.

Kolik dotazů typický zásobník SaaS využívá? Záznam SPF p99 v našem sčítání již dosahuje 9 dotazů — přímo na limitu — než je cokoliv přidáno. Záznam Google Workspace přidává 3–4 dotazy; Mailchimp přidává 1–2; HubSpot přidává 1–3 v závislosti na jejich aktuální konfiguraci. Tři běžné nástroje plus výchozí nastavení vašeho poskytovatele hostingu jsou často dostatečné pro překročení desíti.

Je sloučení SPF bezpečné? Ano, pokud ho udržujete aktuální. Sloučení převádí řetězce include: na statické IP rozsahy — pokud dodavatel obmění své odesílací IP adresy a vy znovu nesloučíte, začnete odmítat jejich poštu. Většina organizací používá spravovanou službu sloučení, která monitoruje změny IP, místo aby ji udržovala ručně.

Můj SPF byl takto nastavený léta — proč teď najednou selhává? Protože vaši dodavatelé aktualizovali své SPF záznamy, nikoli váš. Pokaždé, když platforma SaaS přidá nový rozsah odesílacích IP adres nebo vneste další include, náklady řetězce rostou bez jakékoli změny na vaší straně. Limit 10 dotazů je vyhodnocován živě při příjmu zprávy, takže změna dodavatele v úterý ráno může zničit váš SPF v úterý odpoledne.

Zlepší oprava SPF doručitelnost e-mailů? Odstraní zdroj selhání ověřování, což je předpokladem pro konzistentní doručování — zejména proto, že Google a Yahoo nyní vynucují soulad DMARC pro hromadné odesílatele. Samotný SPF není celý obraz: spojte ho s DKIM a DMARC pro úplné ověřování e-mailů.

Zkontrolujte svůj SPF zdarma

Pokud si nejste jisti, zda váš SPF záznam překračuje limit dotazů — nebo je nastaven příliš slabě na ochranu vaší domény — proveďte bezplatnou kontrolu. Vyhodnotí celý vyřešený řetězec a ukáže vám přesně, kde je rozpočet využíván.

Zkontrolujte svou doménu → · Opravte SPF → · Zpráva SPF PermError → · Zpráva o nesprávné konfiguraci SPF → · Model vyspělosti přijetí SPF → · Opravte DMARC → · Pouze agregovaná data. Data uložena a zpracována v EU.