DKIM selhává po přechodu k nástrojům e-mailu: Průvodce migrací CNAME a selektoru (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.

DKIM se rozbíjí po přechodu k nástroji ze dvou mechanických důvodů: váš DNS panel poškodil cíle CNAME nového nástroje — obvykle připojením vaší vlastní zóny — nebo byly selektory starého nástroje odstraněny, než jeho pošta odtekla. Pouze 3.87% domén — 10,092,481 — dokončí triádu SPF+DKIM+DMARC, podle sčítání Defaults.Exposed zahrnujícího 261,086,232 hodnocených domén.

Pořadí opravy: naskenujte doménu, poté zkontrolujte uložený cíl každého nového CNAME pomocí dig — cíl končící vaším vlastním doménovým jménem je kouřící pistole. Opravte záznamy na autoritativních nameserverech, potvrďte, že nový nástroj podepisuje a prochází před směrováním reálné pošty přes něj, a ponechte selektory starého nástroje publikované, dokud jeho provoz neodteče.

Proč se DKIM rozbilo, když jste přešli na nástroje?

Nic na samotném DKIM se nezměnilo — vaše selektory ano. Starý nástroj podepisoval svými selektory; nový podepisuje různými, obvykle delegovanými přes dva nebo tři CNAME záznamy přidané během přijímání. Čtyři úskalí způsobují téměř každé selhání DKIM po migraci:

Váš DNS panel připojil vaši zónu k cíli CNAME. Mnoho panelů zachází s jakýmkoliv vloženým hostitelským jménem jako relativním a tiše uloží cil.poskytovatel.com.vasedomena.cz namísto cil.poskytovatel.com. Záznam existuje, panel zobrazuje zelený check a rozluštění nepovede nikam.
Zmatek s tečkou na konci. Některé panely vyžadují tečku na konci (cil.poskytovatel.com.) pro „absolutní — přestaňte připojovat mou zónu”; jiné tečku odmítají jako neplatnou a absolutnost řeší samy. Stejná vložená hodnota je správná v jednom panelu a poškozená v dalším.
Selektory starého nástroje byly smazány v den přepnutí. Pošta, kterou starý nástroj již podepsal, sedí v frontách k opakování a cestách přesměrování dny; odstranění jeho selektorů — nebo uzavření starého účtu, čímž se zruší jeho delegované CNAME záznamy — retroaktivně rozbíjí tuto poštu.
Ověřili jste na nesprávných nameserverech. Pokud migrace zahrnovala změnu nameserveru, opravené záznamy mohou existovat na jednom NS setu, zatímco příjemci stále dotazují druhý.

Pouze 51.84% z 261 milionů domén v sčítání prezentuje detekovatelný DKIM klíč v čase skenování (data k 2026-06-29).

Stejná migrace obvykle zanechá také SPF zbytky — 1,013,416 domén, přibližně 1 z 138 těch, které se pokoušejí o SPF, provozuje dva záznamy v=spf1, klasický znak toho, že přechod k poskytovateli přidal záznam namísto sloučení. Tato strana přesunu má vlastního průvodce: SPF přestalo fungovat po přechodu k poskytovateli e-mailu.

Jak poznám poškozený CNAME záznam?

Nevěřte panelu — zeptejte se DNS, co skutečně uložil. Dotázejte cíl CNAME pro každý selektor, který vám nový nástroj dal. Ilustrační příklad, napodobující delegovaný selektor ve stylu SendGrid (tvar cíle vašeho poskytovatele se bude lišit):

$ dig CNAME s1._domainkey.vasedomena.cz +short
s1.domainkey.u1234567.wl123.sendgrid.net.vasedomena.cz.

Poskytovatel požadoval s1.domainkey.u1234567.wl123.sendgrid.net — ale uložený cíl končí .vasedomena.cz. Panel připojil zónu; toto jméno se rozluští na nic, takže příjemci nenajdou žádný klíč. Zdravá verze:

$ dig CNAME s1._domainkey.vasedomena.cz +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Jediná tečka na konci ve výstupu dig je normální — označuje plně kvalifikované jméno.) Pokud je cíl správný, sledujte ho o jeden skok: dig TXT s1._domainkey.vasedomena.cz +short by měl vrátit klíč poskytovatele. Prázdná odpověď se správným CNAME znamená, že problém je na straně poskytovatele delegace — dokončete jejich ověřovací krok nebo viz DKIM „no key for signature” pro diagnózu na úrovni selektoru.

Průvodce migrací: před, během, po

Selhání obvykle není v záznamech — je v pořadí. DKIM migrace se pokazí při přepnutí, protože ověřování se děje po přepnutí, když reálná pošta již selhává.

Fáze	Co dělat	Brána před přechodem
Před přepnutím	Přidejte DKIM CNAME záznamy nového nástroje (a záznamy bounce domény), poté je prokažte: `dig` každý uložený cíl CNAME z vnějšku vaší sítě, dokončete vlastní ověřovací krok nástroje a odešlete test přes nový nástroj do poštovní schránky, kterou ovládáte	Testovací zpráva zobrazuje `dkim=pass` s `d=` = vaší doménou — nikdy nesměrujte reálnou poštu přes neověřený nástroj
Den přepnutí	Přesuňte reálný provoz na nový nástroj. Nedotýkejte se ničeho patřícího starému nástroji: ponechte jeho selektory, CNAME záznamy a účet živé	Pošta nového nástroje prochází u skutečných příjemců; starý nástroj stále prochází pro vše, co stále protéká přes něj
Po odtečení	Sledujte souhrnné DMARC zprávy, dokud se selektory starého nástroje přestanou zobrazovat (fronty k opakování a přesměrování běží dny — povolte týden nebo více), poté vyřaďte jeho záznamy a účet	Staré selektory nepřítomné ve zprávách ≥ 7 dní před odstraněním

Tučný řádek je místo, kde se migrace zachrání nebo ztratí: každá kontrola v něm může být provedena dny před přepnutím, s nulový rizikem pro živou poštu. Mechanika vyřazení selektorů — včetně důvodu, proč republishing s prázdným p= je lepší než mazání — je pokryta v průvodci rotací; tato tabulka je o sekvencování samotného přepnutí nástroje.

Jak opravím DKIM po přepnutí?

Spusťte bezplatnou kontrolu na defaults.exposed před dotykem DNS. Přečte vaše živé záznamy a ukáže, co příjemci skutečně vidí — včetně cílů CNAME s připojenou zónou a selektorů, které se nerozluštují.
Vypište DKIM záznamy, které nový nástroj očekává. Z jeho administrační konzole — pro poskytovatele poštovních schránek, průvodci nastavením Google Workspace a Microsoft 365 ukazují, kde; newsletterové a CRM nástroje uvádějí své CNAME záznamy pod ověřováním domény (viz e-maily z Mailchimp/Brevo/Klaviyo selhávají DMARC).
Zkontrolujte uloženou hodnotu každého záznamu pomocí dig CNAME <jméno> +short a porovnejte ji znak za znakem s tím, co nástroj požadoval. Cíl končící vaší vlastní doménou = připojená zóna; znovu zadejte ji a pokud panel stále připojuje, přidejte tečku na konci (nebo ji odstraňte, pokud panel tečky odmítá).
Ověřte na autoritativních nameserverech. dig +short NS vasedomena.cz, poté opakujte kontroly CNAME @<ten nameserver>. Pokud migrace změnila nameservery, zkontrolujte oba sety — příjemci mohou stále dotazovat starý, dokud se delegace nerozšíří.
Znovu spusťte ověření nástroje a odešlete testovací zprávu. Záhlaví Authentication-Results by mělo zobrazovat dkim=pass s d= rovným vaší doméně — průchod na výchozí doméně nástroje se nezarovná pro DMARC.
Ponechte selektory starého nástroje publikované, dokud jeho pošta neodteče, poté je záměrně vyřaďte. Poté znovu naskenujte a propracujte vše ostatní, co bylo označeno na stránce opravit DKIM.

Nejčastější dotazy

Potřebuji tečku na konci svého DKIM CNAME záznamu nebo ne? Závisí zcela na panelu. Tečka znamená „absolutní jméno — nepřipojujte mou zónu”; některé panely to vyžadují, některé ji přidají za vás, některé ji odmítají. Jediný test, na který záleží, je výstup dig CNAME <selektor>._domainkey.vasedomena.cz +short po uložení: pokud cíl končí vaší vlastní doménou, panel připojil zónu a potřebujete tečku (nebo jiný vstupní formát).

Mohu smazat DKIM záznamy starého nástroje v den přepnutí? Ne. Pošta, kterou starý nástroj podepsal, je stále ve frontách k opakování a cestách přesměrování, a smazání klíče, na který ukazuje, retroaktivně rozbíjí tyto zprávy. Ponechte staré selektory živé, dokud se přestanou zobrazovat ve vašich souhrnných DMARC zprávách — týden nebo více — a neuzavírejte starý účet dříve.

Můj DNS panel i nový nástroj říkají „ověřeno”, ale příjemci stále selhávají DKIM. Jak? Dva běžné případy: nástroj ověřil vůči kešované kontrole, zatímco autoritativní nameservery servírují něco jiného (dotazujte je přímo pomocí dig @<ns>), nebo DKIM prochází, ale na výchozí podepisovací doméně nástroje spíše než na vaší, takže DMARC stále selže zarovnání. Skenování rozliší oba případy.

Mohou DKIM záznamy obou nástrojů koexistovat během překrytí? Ano — a měly by. DKIM nemá pravidlo jednoho záznamu: každý selektor je svým vlastním DNS jménem, takže záznamy obou nástrojů žijí vedle sebe bez konfliktu, což umožňuje snadno dodržet pravidlo o ponechání starých selektorů přes odtékání. (SPF je opak — dva záznamy v=spf1 ho ruší, což je důvod, proč průvodce migrací SPF je o slučování.)

Pošlete vlastníkovi zprávu

Pokud provádíte tuto migraci pro klienta nebo svého zaměstnavatele, uzavřete ji s důkazem. Jakmile nový nástroj podepisuje a je zarovnán, znovu spusťte bezplatnou kontrolu a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: s datem, v přímé řeči, důkaz, že přepnutí zanechalo doménu plně ověřenou. Je to artefakt, který budou potřebovat pro obnovení kybernetického pojištění a příští dotazník bezpečnosti dodavatele — přemění „migrace je hotová” z tvrzení na dokument.

Zkontrolujte svůj DKIM zdarma

Zjistěte, zda se selektory vašeho nového nástroje rozluštují — a přesně co opravit — soukromě a pouze pro vlastníky.

Zkontrolujte svou doménu → · SPF se rozbilo po přechodu k poskytovateli → · Opravit DKIM → · Nastavit DKIM na Google Workspace → · Pouze souhrnná data. Data uložena a zpracována v EU.