Defaults.Exposed › Opravy › Guides

"SPF záznam nenalezen" — a přitom ho máte? 5 skutečných příčin (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.

Pokud nástroj říká „SPF záznam nenalezen”, ale jste si jisti, že jste ho publikovali, záznam je obvykle neviditelný, nikoli chybějící: 1,013,416 domén — přibližně jedna z 138 těch, které se o SPF pokoušejí — publikuje dva nebo více SPF záznamů, tedy PermError (RFC 7208 §3.2), který mnoho nástrojů hlásí jako nenalezeno, podle sčítání Defaults.Exposed zahrnujícího 261 milionů domén.

Existuje pět skutečných příčin, všechny opravitelné během jednoho sezení: špatný hostitel, duplicitní záznam, špatný typ DNS nebo poškozené uvozovky, nekonzistentní nameservery nebo kolize délky/CNAME. Níže: 60sekundový test pro každou z nich, v pořadí, v jakém je kontrolovat, a poté kroky opravy.

Jste si jisti, že záznam skutečně existuje?

Začněte nepříjemnou možností, protože je zdaleka nejčastější: z domén 261,086,232 ohodnocených ve sčítání Defaults.Exposed 121,145,609 — 46.4% — nemá žádný SPF záznam vůbec. Mnoho případů „ale já to nastavil” se ukáže být záznam přidaný do testovací zóny nebo k starému poskytovateli DNS, který již není autoritativní. Zkontrolujte poskytovatele DNS, na kterého vaše nameservery skutečně ukazují (často to není váš registrátor), zda má TXT záznam začínající v=spf1. Pokud tam skutečně není, přeskočte detektivní práci a přejděte přímo na opravit SPF záznam.

Jak správně zkontrolovat SPF záznam?

Webové nástroje dotazují DNS přes vlastní cacheující resolver. Abyste viděli pravdu, ptejte se přímo autoritativního nameserveru vaší domény:

# najít autoritativní nameservery
dig NS vasedomena.cz +short

# zeptat se jednoho z nich přímo na TXT záznamy
dig TXT vasedomena.cz @ns1.vasedns.cz +short

Ve Windows: nslookup -type=TXT vasedomena.cz ns1.vasedns.cz.

Dvě pravidla interpretace. Za prvé, spočítejte řádky začínající v=spf1 — počet je stejně důležitý jako obsah. Za druhé, zkontrolujte, zda jste dotazovali správný název: příjemci vyhodnocují SPF vůči doméně v Return-Path (RFC5321.MailFrom, „obálkový odesílatel”) — nikoli vůči adrese From, kterou příjemci vidí. Pokud váš newsletterový nástroj odesílá poštu přes bounce.vasedomena.cz, dokonalý záznam na apexu není záznam, který příjemci vyhledávají.

Jakých je pět skutečných příčin?

Data k 2026-06-29.

1. Je záznam na špatném hostiteli?

Klasika: SPF přidáno na mail.vasedomena.cz, zatímco pošta tvrdí, že pochází z vasedomena.cz, nebo naopak. SPF nezdědí dolů — záznam na apexu neříká nic o subdoménách a naopak. Publikujte přesně na jméno ve vašem Return-Path. Dodavatel odesílající z vlastní bounce subdomény potřebuje záznam na té subdoméně — obvykle CNAME nebo TXT, které dodavatel poskytuje (průvodce nastavením SPF na GoDaddy ukazuje, kde tato pole jsou).

2. Máte dva SPF záznamy?

Titulní příčina a nejzavádějící chybová zpráva v e-mailové autentizaci. RFC 7208 §3.2 je jednoznačný: doména musí mít přesně jeden SPF záznam. Dva nebo více je PermError — příjemci považují vaše SPF za neplatné. Některé nástroje hlásí tento stav přesně („bylo nalezeno více záznamů”); jiné hlásí čistý výsledek: žádný platný SPF záznam nenalezen. Vidíte záznam ve svém panelu a dojdete k závěru, že nástroj je rozbiten. Není — máte o jeden záznam víc.

Sčítání nalezlo 1,013,416 domén s dvěma nebo více SPF záznamy — přibližně jedna z 138 domén, které se pokoušejí o SPF — každá s prakticky vypnutým SPF. Obvykle se to stane při změně poskytovatele: průvodce nastavením nového poskytovatele přidá nový záznam místo toho, aby upravil starý. Opravou je sloučení, nikdy druhý záznam: zkombinujte vše do jednoho řádku v=spf1 … ~all a zbytek odstraňte. Náš datový report dva SPF záznamy se rovnají žádnému rozebírá, jak se tam milion domén dostaly; pokud to začalo po migraci, viz SPF přestalo fungovat po přechodu k poskytovateli. Při slučování slepě nekombinujte každý include: — každý stojí DNS vyhledávání vůči pevnému limitu SPF 10, čímž vyměníte nenalezeno za PermError: příliš mnoho DNS vyhledávání.

3. Publikovali jste špatný typ záznamu — nebo ho rozhraní pokazilo?

Rané SPF mělo vlastní typ DNS záznamu (typ 99, doslova pojmenovaný „SPF”). Byl zastaralý: RFC 7208 vyžaduje TXT a příjemci typ 99 nedotazují. Některé DNS panely stále nabízejí „SPF” v rozbalovacím menu typů záznamů; vyberte ho a váš záznam je reálný, dobře formátovaný a neviditelný. Zkontrolujte sloupec typu a znovu publikujte jako TXT.

Subtilnější sourozenec je uvozování. Vložení hodnoty obalené uvozovkami do pole, které přidává vlastní uvozovky, produkuje ""v=spf1 …"" — což již nezačíná v=spf1, takže pro ověřovač neexistuje. Váš výstup dig ukazuje pravdu; DNS panel to často kosmeticky skryje.

4. Jde skutečně o „šíření”?

„Dejte mu 24–48 hodin na propagaci” je nejpřepisovanější rada v DNS. Propagace je jen vypršení cache: jakmile uplyne TTL záznamu (typicky 1 hodina, jen výjimečně více než 24), každý resolver může vidět novou odpověď. Stále nenalezeno po 24 hodinách? Propagace není příčina.

Dvě skutečné příčiny: negativní cacheování — resolver, který vás vyhledal před tím, než jste záznam přidali, uloží do cache odpověď „žádný takový záznam” do vypršení negativního TTL — a nekonzistentní nameservery po migraci, kdy doména stále uvádí nameservery starého poskytovatele vedle nových a polovina světa čte zónu, kterou již neupravujete. Dotazujte každý uvedený nameserver přímo; pokud se odpovědi liší, našli jste problém. Opravte NS delegaci registrátora tak, aby autoritativní byl pouze poskytovatel, kterého skutečně upravujete.

5. Je záznam příliš dlouhý nebo blokován CNAME?

Jeden řetězec v TXT záznamu má maximálně 255 znaků. Delší SPF záznamy jsou legální, ale musí být rozděleny do více citovaných řetězců v rámci jednoho záznamu — a rozhraní DNS poskytovatelů to pravidelně kazí: hodnota je zkrácena nebo rozdělena uprostřed mechanismu, takže ji nelze parsovat. Pokud je váš záznam dlouhý, zkontrolujte výstup dig, zda hodnota neskončí náhle.

Samostatně, DNS zakazuje TXT záznam na jménu, které již má CNAME. Pokud mail.vasedomena.cz je CNAME k vašemu poskytovateli, nemůžete tam umístit také SPF — některé panely to přijmou a poté slouží pouze CNAME. Umístěte záznam tam, kam CNAME ukazuje (pokud to ovládáte), nebo přestrukturujte tak, aby odesílací jméno nebylo CNAME. Poskytovatelé s čistým TXT zpracováním obojí usnadňují — viz průvodce nastavením SPF na Cloudflare.

Jak to opravit krok za krokem?

1. Spusťte bezplatnou kontrolu na defaults.exposed — načte vaše živé DNS záznamy a řekne vám, ve kterém ze pěti stavů se nacházíte, než cokoliv změníte.
2. Potvrďte, které nameservery jsou autoritativní (dig NS) a zda se všechny shodují.
3. Dotaz TXT na autoritativní nameserver pro přesnou doménu Return-Path.
4. Spočítejte řádky v=spf1: nula → publikujte jeden; dva nebo více → sloučte do jednoho.
5. Ověřte, že typ je TXT, hodnota začíná přesně v=spf1 a nevnikly žádné zbloudilé uvozovky ani zkrácení.
6. Vyčkejte jedno TTL, poté znovu zkontrolujte, zda se správně rozlušťuje všude.

Nejčastější dotazy

Proč nástroj říká „nenalezeno”, když v DNS panelu záznam vidím? Obvykle příčina 2 nebo 4: druhý záznam v=spf1 způsobí, že oba jsou neplatné — PermError, který některé nástroje hlásí jako nenalezeno, ve stavu, ve kterém je 1,013,416 domén k 2026-06-29 — nebo váš panel není DNS, které je skutečně autoritativní.

Jak dlouho trvá, než nástroje uvidí mou opravu? Jedno TTL — typicky hodinu, maximálně 24. Poté „propagace” není vysvětlení; znovu zkontrolujte pět příčin, počínaje konzistencí nameserverů.

Mám použít typ záznamu „SPF”, který nabízí můj DNS panel? Ne. Typ 99 je zastaralý; RFC 7208 vyžaduje pouze TXT. Záznam typu 99 je pro moderní příjemce neviditelný.

Záznam byl nalezen — proč moje pošta stále selhává SPF? Protože SPF se kontroluje vůči doméně Return-Path, nikoli záhlaví From, a záznam musí skutečně uvádět servery, které za vás odesílají. Nalezeno je krok jedna; průvodce opravou SPF záznamu pokrývá prochání.

Je mít žádný SPF záznam opravdu tak běžné? Ano — 121,145,609 domén, 46.4% z 261,086,232 ohodnocených ve sčítání Defaults.Exposed (k 2026-06-29), nepublikuje žádné SPF vůbec. Nenalezeno je výchozí stav internetu.

Pošlete vlastníkovi zprávu

Jakmile se záznam správně rozlušťuje, spusťte skenování znovu a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi nebo klientovi, jehož doménu to je. Ukazuje srozumitelně, co bylo rozbito, co jste opravili a kde doména nyní stojí — přesně ten důkaz, který budou potřebovat při obnovení kybernetického pojištění a dotaznících bezpečnosti dodavatelů. Zpráva je potvrzením vykonané práce.

Zkontrolujte svůj SPF záznam zdarma

Zjistěte, ve kterém ze pěti stavů „nenalezeno” vaše doména je — soukromě a pouze pro vlastníky.

Zkontrolujte svou doménu → · Opravit SPF → · SPF přestalo fungovat po přechodu k poskytovateli → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.