SPF limit 10 DNS lookupů — jak ho spočítat a vyřešit

Co je limit 10 DNS lookupů

SPF záznam definuje, které servery smějí odesílat e-maily za vaši doménu (podrobně v článku Co je SPF záznam). Při každém doručení e-mailu přijímající server načte SPF záznam z DNS a vyhodnotí ho. Některé mechanismy v záznamu vyžadují další DNS dotazy — a právě ty jsou omezené.

RFC 7208 (sekce 4.6.4) stanoví, že vyhodnocení jednoho SPF záznamu smí vyvolat maximálně 10 DNS dotazů. Limit existuje jako ochrana přijímajících serverů — bez něj by útočník mohl vytvořit SPF záznam s desítkami vnořených include mechanismů a zahlcovat DNS infrastrukturu příjemce.

Překročení limitu způsobí chybu PermError. SPF kontrola selže bez ohledu na to, zda je odesílající server oprávněný. Vaše e-maily mohou skončit ve spamu nebo být odmítnuty.

Které mechanismy se počítají

Ne každý mechanismus v SPF záznamu vyvolává DNS dotaz. Rozlišení je klíčové pro optimalizaci záznamu.

Počítají se do limitu

Nepočítají se

Pozor na vnořené include

Každý include načte SPF záznam cílové domény, který může obsahovat další include mechanismy. Ty se počítají do stejného limitu. Počet vnořených lookupů závisí na aktuální struktuře SPF záznamu dané služby a může se měnit bez vašeho vědomí — proto je důležité počet lookupů pravidelně kontrolovat.

Jak spočítat DNS lookupy

Ruční počítání vnořených include mechanismů je zdlouhavé a náchylné k chybám — vnořené záznamy se navíc mohou měnit bez vašeho vědomí.

Zkontrolujte svůj SPF záznam naším analyzérem — automaticky spočítá všechny DNS lookupy včetně vnořených a upozorní na překročení limitu.

Alternativně v terminálu:

dig firma.cz TXT +short | grep spf

Výstup vám ukáže samotný SPF záznam, ale vnořené include musíte rozbalit ručně — pro každý include opakujte dotaz na cílovou doménu a sečtěte všechny lookupy.

Příklad: kolik lookupů spotřebuje typická doména

Doména firma.cz používá Google Workspace, SendGrid, Freshdesk a vlastní server:

v=spf1 include:_spf.google.com include:sendgrid.net include:email.freshdesk.com a mx -all

Každý include spotřebuje minimálně 1 lookup (plus případné vnořené). Mechanismy a a mx přidávají další dotazy. Celkový počet závisí na aktuální struktuře SPF záznamů jednotlivých služeb — ověřte ho analyzérem.

U domény s pěti a více odesílacími službami se k limitu 10 lookupů dostanete velmi rychle.

Limit 2 void lookupů

RFC 7208 kromě hlavního limitu doporučuje omezit void lookupy na 2 — DNS dotazy, které vrátí prázdnou odpověď (žádný záznam) nebo chybu NXDOMAIN. Většina mailových serverů tento limit vynucuje a při překročení vrátí PermError.

Void lookupy typicky vznikají, když SPF záznam odkazuje include na doménu, která nemá SPF záznam, nebo na neexistující doménu. Nejčastější příčina: zrušená služba, jejíž include v záznamu zůstal.

Jak limit vyřešit

1. Odstraňte nepoužívané mechanismy

Projděte každý include a a/mx mechanismus v záznamu. Pokud služba, na kterou odkazuje, už e-maily z vaší domény neodesílá, odstraňte ho. To je nejčistší a nejbezpečnější optimalizace.

Typické kandidáty na odstranění:

• Zrušené SaaS služby (starý helpdesk, předchozí marketingový nástroj)
• Testovací prostředí, která už neběží
• Mechanismus a nebo mx, pokud vaše A/MX záznamy neodkazují na poštovní server

2. Nahraďte include přímými IP adresami

Pokud služba odesílá e-maily z fixní IP adresy (typicky vlastní server), nahraďte include nebo a mechanismus přímým ip4:/ip6:. Ušetříte minimálně jeden lookup.

# Před (2 lookupy)
v=spf1 a include:_spf.google.com -all

# Po (1 lookup méně)
v=spf1 ip4:198.51.100.10 include:_spf.google.com -all

Toto řešení funguje jen pro servery se stabilní IP adresou. U cloudových služeb, které IP adresy mění, je include jedinou spolehlivou cestou.

3. Segmentace na subdomény

Přesuňte část e-mailového provozu na subdoménu. Každá subdoména má vlastní SPF záznam s vlastním limitem 10 lookupů.

Příklad: marketing odesílejte z news.firma.cz, transakční e-maily z notify.firma.cz:

# firma.cz — firemní e-mail
v=spf1 include:_spf.google.com ip4:198.51.100.10 -all

# news.firma.cz — marketing
v=spf1 include:sendgrid.net -all

# notify.firma.cz — transakční e-maily
v=spf1 include:email.freshdesk.com include:amazonses.com -all

Segmentace má i další výhodu: odděluje reputaci jednotlivých e-mailových proudů. Problém s doručitelností marketingových kampaní neovlivní doručování faktur.

4. SPF flattening

SPF flattening nahrazuje include mechanismy přímo IP adresami, které by se jinak získaly DNS dotazy. Snižuje počet lookupů, ale má zásadní nevýhodu: pokud služba změní své IP adresy, váš SPF záznam přestane fungovat.

# Před flatteningem
v=spf1 include:_spf.google.com -all

# Po flatteningu (zjednodušený příklad)
v=spf1 ip4:209.85.128.0/17 ip4:74.125.0.0/16 -all

Google (a další velcí provideři) IP rozsahy pravidelně mění. Flattening proto vyžaduje automatizaci — pravidelnou kontrolu a aktualizaci IP adres. Bez automatizace riskujete, že legitimní e-maily přestanou procházet SPF kontrolou.

Flattening používejte jako poslední možnost, až po vyčerpání předchozích tří kroků.

Jak problému předcházet

Limit 10 DNS lookupů se většinou neprojeví hned — roste postupně s přidáváním nových služeb. Než přidáte nový include do SPF záznamu, ověřte aktuální počet lookupů analyzérem SPF záznamu.

Pravidelný monitoring SPF záznamu odhalí problém dříve, než ovlivní doručitelnost vašich e-mailů. Změny ve vnořených include (například když Google přidá nový server) mohou posunout váš záznam přes limit i bez vašeho zásahu.

Pokud provozujete doménu s více než třemi poštovními službami, zvažte segmentaci na subdomény od začátku — předejdete problému s limitem a získáte lepší kontrolu nad reputací odesílatele jednotlivých e-mailových proudů. Praktický postup sestavení záznamu najdete v článku Jak vytvořit SPF záznam krok za krokem.