Ověření domény neprochází: nejčastější chyby v DNS a jak si záznam zkontrolovat přes dig

Průvodce ověřením domény vám dá tři záznamy, vy je vložíte, kliknete na „Zkontrolovat" a výsledek je červený. V devíti případech z deseti je příčina jedna z osmi chyb níže, a všechny se dají odhalit jedním příkazem dig. Článek je psaný tak, abyste ho mohli projít shora dolů, dokud záznam nezezelená.

Nejdřív nástroj: dig a nslookup

dig je na macOS a Linuxu k dispozici rovnou, na Windows použijte nslookup nebo nainstalujte BIND tools. Základní dotaz na TXT záznam:

dig TXT _dmarc.firma.cz +short

nslookup -type=TXT _dmarc.firma.cz

Dvě užitečné varianty:

• Dotaz přímo na autoritativní server vaší domény obejde všechny mezipaměti a ukáže, co jste skutečně uložili: dig TXT _dmarc.firma.cz @ns.vas-registrator.cz +short. Jméno autoritativního serveru zjistíte příkazem dig NS firma.cz +short.
• Dotaz na veřejný resolver (@8.8.8.8, @1.1.1.1) ukáže, co vidí zbytek světa, včetně zpoždění propagace.

Pokud oba dotazy vrací správnou hodnotu a kontrola přesto selhává, čtěte dál; problém je v obsahu záznamu.

Chyba 1: zdvojené jméno domény

Nejčastější chyba vůbec. Průvodce řekne „vytvořte TXT záznam _dmarc.firma.cz", vy do pole Název v administraci napíšete _dmarc.firma.cz, ale administrace k němu sama připojí doménu. Výsledkem je záznam na _dmarc.firma.cz.firma.cz, který nikdo nikdy nenajde.

Jak to poznat:

dig TXT _dmarc.firma.cz +short            → nic
dig TXT _dmarc.firma.cz.firma.cz +short   → "v=DMARC1; p=none; …"

Oprava: do pole Název patří jen část před vaší doménou: _dmarc, tem1._domainkey, a pro záznam na samotné doméně @ nebo prázdné pole (podle registrátora). Některé administrace naopak chtějí plné jméno s tečkou na konci (_dmarc.firma.cz.); tečka říká „tohle je absolutní jméno, nic nepřipojuj".

Chyba 2: dva SPF záznamy

Na doméně smí být přesně jeden TXT záznam začínající v=spf1. Když existují dva (starý od hostingu a nový od e-mailové služby), RFC 7208 říká, že výsledek je permerror a SPF se chová, jako by neexistovalo.

dig TXT firma.cz +short
"v=spf1 include:spf.hosting.cz ~all"
"v=spf1 include:spf.topemail.cz ~all"

Oprava: záznamy sloučit do jednoho:

"v=spf1 include:spf.hosting.cz include:spf.topemail.cz ~all"

Totéž platí pro DMARC: na _dmarc smí být jeden záznam v=DMARC1.

Chyba 3: víc než 10 DNS dotazů ve SPF

Při vyhodnocení SPF smí příjemce udělat nejvýše 10 dotazů vyvolaných mechanismy include:, a, mx, ptr, exists a redirect=. Každý include: se počítá, a to včetně toho, co obsahuje uvnitř; include:_spf.google.com sám spotřebuje několik. Při překročení je výsledek opět permerror.

Jak to poznat: ručně projděte každý include příkazem dig TXT _spf.google.com +short a počítejte, nebo použijte libovolný online nástroj na kontrolu SPF, který počet dotazů ukáže.

Oprava: odebrat includes služeb, které už nepoužíváte (bývalý newsletterový nástroj, starý hosting), nahradit mx a a konkrétními ip4: tam, kde se adresy nemění, a oddělit marketing na subdoménu s vlastním SPF. Mechanismy ip4: a ip6: se do limitu nepočítají.

Chyba 4: uvozovky, mezery a kopírování

Administrace registrátorů se liší v tom, jestli hodnotu TXT chtějí s uvozovkami nebo bez. Když vložíte "v=spf1 …" do pole, které uvozovky přidává samo, výsledkem je záznam ""v=spf1 …"", který není platný. Opačně: některé administrace bez uvozovek rozdělí hodnotu na mezerách.

dig TXT firma.cz +short
"\"v=spf1 include:spf.topemail.cz ~all\""     ← zdvojené uvozovky

Další varianty stejné chyby: nevidítelná mezera na konci, „chytré" typografické uvozovky z textového editoru, nebo středník ; v DMARC nahrazený jiným znakem. Hodnotu kopírujte z průvodce přímo do administrace, ne přes Word.

Chyba 5: DKIM klíč rozdělený na části

Veřejný klíč o délce 2048 bitů přesahuje 255 znaků, což je maximum pro jeden řetězec v TXT záznamu. Správné řešení je zapsat ho jako několik řetězců v jednom záznamu, které příjemce spojí:

dig TXT tem1._domainkey.firma.cz +short
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…" "…rest…IDAQAB"

Většina administrací to udělá sama. Chyba nastane, když klíč ručně rozdělíte do dvou samostatných záznamů, nebo když vám administrace hodnotu zkrátí. Pokud dig vrátí klíč kratší, než jaký jste vložili, hledejte limit délky pole u registrátora; někdy pomůže jen podpora, nebo přechod na jiného správce DNS.

Pokud služba nabízí DKIM jako CNAME (klíč ukazuje na záznam u ní), tento problém odpadá úplně.

Chyba 6: CNAME přes Cloudflare proxy

Cloudflare má u každého záznamu přepínač Proxy status. Oranžový mráček znamená, že provoz jde přes Cloudflare; u A a CNAME záznamů Cloudflare vrací svoje IP adresy, ne cílové. Pro web je to žádoucí. Pro DKIM nebo ověřovací záznam vedený přes CNAME je to zničující: příjemce místo cílového jména dostane IP Cloudflare a TXT za ním nikdy nenajde.

Oprava: u všech záznamů, které se týkají e-mailu (CNAME pro DKIM, případný CNAME pro ověření, MX a jejich A záznamy), nastavte DNS only (šedý mráček). Jak to poznat:

dig CNAME tem1._domainkey.firma.cz +short

Pokud místo jména u e-mailové služby vidíte A záznam s IP adresou Cloudflare, je zapnutá proxy.

Chyba 7: TTL a propagace

Když záznam uložíte, neobjeví se všude hned. Dva zdroje zpoždění:

• Mezipaměť resolverů. Každý záznam má TTL (dobu platnosti v sekundách). Pokud jste se na _dmarc.firma.cz ptali před vložením záznamu, resolver si mohl zapamatovat zápornou odpověď („neexistuje") na dobu podle SOA záznamu, často hodinu. Dotaz přímo na autoritativní server (@ns…) ukáže pravdu okamžitě.
• Zpoždění u správce DNS. Někteří registrátoři zapisují změny do svých serverů v intervalech (minuty až desítky minut).

Prakticky: pokud autoritativní server vrací správnou hodnotu, je záznam v pořádku a stačí počkat; u většiny domén do hodiny, výjimečně podle původního TTL až 24 až 48 hodin. Pokud chcete kontrolu zrychlit, nastavte před změnami TTL na 300 a po ověření ho zase zvyšte.

Chyba 8: záznam na špatné doméně nebo u špatného správce

Vložili jste záznamy k registrátorovi, ale DNS vaší domény obsluhuje hosting nebo Cloudflare. Nebo máte web na www.firma.cz a ověřujete firma.cz, ale DNS je delegované na jiný server než ten, do kterého píšete.

dig NS firma.cz +short

Ukáže, kdo doménu skutečně obsluhuje. Změny dělejte jen tam. Podobný případ: ověřujete subdoménu shop.firma.cz, ale záznam vložíte na hlavní doménu; SPF a DMARC se dědí různě (DMARC z nadřazené domény ano, SPF ne), tak si přečtěte, co přesně průvodce chce.

Kontrolní postup, když nic nepomáhá

1. dig NS firma.cz +short → kde je DNS.
2. dig TXT <jméno> @<autoritativní server> +short → co jste skutečně uložili. Porovnejte znak po znaku s průvodcem.
3. dig TXT <jméno> @8.8.8.8 +short → co vidí svět. Pokud se liší od bodu 2, čekáte na propagaci.
4. dig TXT <jméno>.firma.cz +short → test na zdvojené jméno.
5. Počet SPF záznamů na doméně a počet DNS dotazů.
6. U Cloudflare šedý mráček u všech e-mailových záznamů.

Pokud je všech šest bodů v pořádku a průvodce stále hlásí chybu, pošlete nám výstup těchto příkazů na podporu; z něj problém poznáme většinou během minut. Co jednotlivé záznamy dělají a jak mají vypadat, popisuje návod na SPF, DKIM a DMARC; jak postupovat při migraci domény mezi službami, checklist k migraci.

Shrnutí

• Do pole Název patří jen část před doménou; zkontrolujte dig na zdvojené jméno.
• Jeden SPF, jeden DMARC, max. 10 dotazů ve SPF.
• Uvozovky podle registrátora, žádné typografické znaky, nic přes Word.
• Dlouhý DKIM klíč je víc řetězců v jednom záznamu, ne víc záznamů.
• U Cloudflare DNS only pro vše kolem e-mailu.
• Dotaz na autoritativní server ukáže pravdu bez čekání na propagaci.