DKIM „No Key for Signature": Oprava selektoru a rotace (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.

„No key for signature” znamená, že příjemce dotazoval DNS záznam, na který váš DKIM podpis ukazuje — selektor._domainkey.vasedomena — a nenašel žádný klíč: nebyl nikdy publikován nebo byl smazán uprostřed rotace. Publikujte selektor, který váš podepisovatel skutečně používá. Pouze 10,092,481 domén — 3.87% — dokončí triádu SPF+DKIM+DMARC, podle sčítání Defaults.Exposed zahrnujícího 261,086,232 ohodnocených domén.

Oprava je jeden DNS záznam, nalezený v jednom záhlaví. Přečtěte tagy s= a d= ze skutečného záhlaví DKIM-Signature, abyste zjistili, se kterým selektorem je vaše pošta podepsána, publikujte (nebo opravte) přesně tento záznam a preferujte delegaci CNAME, aby poskytovatel rotoval klíče za vás. Poté rotujte dle níže uvedeného průvodce — tato chyba obvykle znamená, že někdo smazal starý selektor příliš brzy.

Co znamená „dkim no key for signature”?

Každý DKIM podpis nese dva tagy říkající příjemci, kde načíst veřejný klíč: d= (podpisová doména) a s= (selektor). Příjemce dotazuje jeden DNS název sestavený z nich — s._domainkey.d — pro klíč. „No key for signature” znamená, že tento dotaz vrátil prázdnou odpověď: podpis existuje, ale klíč, který pojmenovává, neexistuje.

Formulace se objevuje v záhlavích Authentication-Results a souhrnných DMARC zprávách — přesné znění se liší dle příjemce, ale dvě varianty jsou důležité:

Řetězec výsledku (fragment, jak je běžně pozorováno)	Co se skutečně stalo	Přechodné?
`dkim=temperror (no key for signature)`	DNS dotaz selhal nebo vypršel čas — příjemce vůbec nemohl získat odpověď	Ano — opakování často projde; zkoumejte pouze pokud přetrvává
`dkim=permerror (no key for signature)`	DNS dotaz uspěl a odpověď byla „žádný takový záznam” — selektor skutečně chybí	Ne — záznam chybí, dokud ho nepublikujete

Jednorázový temperror je DNS počasí. Permerror — nebo temperror opakující se přes dny a příjemce — znamená, že záznam, na který podpis ukazuje, není ve vaší zóně. O tom je tento průvodce.

Důsledek: neověřitelný podpis počítá jako žádný DKIM vůbec, takže DMARC se vrátí pouze na SPF — a SPF se rozbíjí při přesměrování. Pokud je podpis přítomen, ale neplatný spíše než chybějící (hash těla, poškozený klíč), to je jiné selhání — viz „DKIM signature not valid”.

Jak zjistím, se kterým selektorem je moje pošta podepsána?

Nehadejte z dokumentace poskytovatele — přečtěte to ze skutečné zprávy:

Odešlete zprávu z postiženého systému do poštovní schránky, kterou ovládáte (Gmail adresa funguje dobře).
Otevřete raw zdrojový kód („Zobrazit originál” v Gmail, „Zobrazit zdroj zprávy” v Outlook).
Najděte záhlaví DKIM-Signature: a přečtěte dva tagy: s= je selektor, d= je podpisová doména. Ilustrační příklad: DKIM-Signature: v=1; a=rsa-sha256; d=vasedomena.cz; s=mail2026; ...
Záznam, který příjemce dotazuje, je s._domainkey.d — zde mail2026._domainkey.vasedomena.cz. Zkontrolujte sami: dig TXT mail2026._domainkey.vasedomena.cz +short. Prázdná odpověď = chyba je skutečná pro každého příjemce.
Opakujte per odesílací systém. Zpráva může nést více DKIM podpisů — poskytovatel poštovní schránky, newsletterový nástroj, helpdesk — každý s vlastním párem s=/d= a záznamem. Opravte ten selhávající a poznamenejte si jeho d=: pouze podpis, jehož d= odpovídá vaší doméně From, pomáhá DMARC.

Proč záznam selektoru chybí?

Čtyři příčiny způsobují téměř všechny tyto chyby — zkontrolujte je v tomto pořadí:

Nebyl nikdy publikován. Podepisovatel byl zapnut (nebo zapnut ve výchozím nastavení) se selektorem, který nikdo do DNS nepřidal. Běžné u nových nástrojů a bran, které podepisují neočekávaně.
Byl smazán uprostřed rotace. Někdo „uklidil” starý selektor, zatímco zprávy s ním podepsané byly stále v přenosu, frontě k opakování nebo čekaly na přesměrování. Ta pošta je již podepsána s s=stary; smazání stary._domainkey retroaktivně rozbíjí každou z těchto zpráv.
Vaše DNS UI poškodilo cíl CNAME. Mnoho poskytovatelů deleguje přes CNAME (s1._domainkey.vasedomena.cz → s1.domainkey.u123.esp.com) a mnoho DNS panelů tiše připojí vaši zónu k cíli — uloží s1.domainkey.u123.esp.com.vasedomena.cz, které se rozluští na nic. Ověřte cíl: dig CNAME s1._domainkey.vasedomena.cz +short. Stejná past číhá při migracích nástrojů — viz DKIM selhávající po přechodu k nástrojům e-mailu.
Poskytovatel rotoval, vaše zóna ne. Klíč poskytovatele vložený jako statický TXT záznam (namísto jejich CNAME záznamu) je osiřelý jejich plánovanou rotací — podepisovatel přejde na selektor, který jste nikdy nepublikovali. 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).

Jak opravím „no key for signature”?

Spusťte bezplatnou kontrolu na defaults.exposed před dotykem DNS. Přečte vaše živé DKIM, SPF a DMARC záznamy a ukáže, co příjemci skutečně vidí — včetně toho, zda se selektor rozluští a zda cíl CNAME nebyl poškozen.
Publikujte selektor, který podepisovatel skutečně používá — hodnotu s= ze záhlaví, nikoli tu z old průvodce. Získejte záznam z administrační konzole svého poskytovatele (nastavení DKIM na Google Workspace · nastavení DKIM na Microsoft 365) a přidejte ho přesně na s._domainkey.vasedomena.cz.
Preferujte delegaci CNAME před vložením TXT klíče. Pokud váš poskytovatel nabízí DKIM CNAME záznamy, použijte je: klíč žije v jejich zóně, takže ho rotují bez toho, abyste znovu museli upravovat DNS — příčina 4 se stane nemožnou. Newsletterové platformy téměř všechny fungují tímto způsobem; viz e-maily z Mailchimp/Brevo/Klaviyo selhávají DMARC.
Ověřte z vnějšku svého panelu. dig TXT s._domainkey.vasedomena.cz +short (nebo dig CNAME … pro delegované selektory) z počítače mimo vaší síť. Panel zobrazující záznam nic nedokazuje, pokud zóna servíruje něco jiného.
Znovu naskenujte a znovu odešlete testovací zprávu. Authentication-Results by nyní měl zobrazovat dkim=pass. Poté propracujte vše ostatní, co kontrola označí, na stránce opravit DKIM — procházející podpis, který není zarovnán s vaší doménou From, stále selže DMARC.

Jak rotovat DKIM klíče bez způsobení této chyby?

Rotace je místem, kde se funkční nastavení rozbíjejí. Pravidlo, které tomu zabrání: selektor je smazán pouze poté, co poslední zpráva s ním podepsaná odtekla — nikdy při přepnutí. Podepsaná pošta žije déle, než si myslíte: fronty k opakování běží dny a přesměrované zprávy se znovu ověřují při každém pohybu.

Krok	Akce	Brána před dalším krokem
1. Přidání	Publikujte nový selektor (`s2._domainkey…`) vedle starého	`dig` potvrdí, že se rozluští z vnějšku
2. Přepnutí	Nasměrujte podepisovatel na nový selektor	Testovací zpráva zobrazuje `s=s2` a `dkim=pass`
3. Čekání	Ponechte starý selektor publikovaný, zatímco provoz v průběhu, ve frontě a přesměrovaný odteče	≥ 7 dní; sledujte souhrnné DMARC zprávy, dokud se starý selektor přestane zobrazovat
4. Vyřazení	Odstraňte starý klíč — nebo lépe, znovu ho publikujte s prázdným tagem `p=`: „vyřazený”, ne „nikdy neexistoval”	Nikdy nezačínejte při přepnutí — předčasné smazání je příčina č. 1 „no key for signature”

S delegací CNAME váš poskytovatel spouští přesně tento průvodce uvnitř své vlastní zóny a vy to nikdy neuvidíte — nejsilnější argument pro delegování.

Nejčastější dotazy

Je „no key for signature” temperror nebo permerror? Existují oba řetězce: temperror je DNS dotaz, který selhal nebo vypršel čas — přechodný, často pryč při opakování — zatímco permerror znamená, že DNS odpověděl „žádný takový záznam”. Temperror opakující se přes příjemce se obvykle ukáže být skutečně chybějícím záznamem. Zkontrolujte pomocí dig a věřte odpovědi, nikoli štítku.

Znamená tato chyba, že někdo spoofuje moji doménu? Ne — spoofátor by nepodepisoval vaším selektorem. Znamená to, že vaše vlastní pošta nese podpis, který příjemci nemohou ověřit, takže se počítá jako nepodepsaná a DMARC se spoléhá pouze na SPF. Úplné, zarovnané ověřování je vzácné: pouze 10,092,481 z 261,086,232 domén (3.87%) dokončilo triádu SPF+DKIM+DMARC v sčítání Defaults.Exposed (data k 2026-06-29).

Mohu smazat starý selektor, jakmile nový funguje? Ne okamžitě. Zprávy s ním podepsané jsou stále v frontách k opakování a cestách přesměrování; smazání klíče je retroaktivně rozbíjí. Ponechte starý záznam alespoň týden, sledujte své DMARC zprávy, dokud se starý selektor přestane zobrazovat, poté ho vyřaďte — ideálně s prázdným p= spíše než smazáním.

Dashboard mého poskytovatele říká, že DKIM je nakonfigurováno, ale příjemci stále hlásí no key. Jak? Téměř vždy past cíle CNAME: váš DNS panel připojil vaši zónu k cíli (…esp.com.vasedomena.cz), takže záznam existuje, ale neukazuje nikam. dig CNAME selektor._domainkey.vasedomena.cz +short zobrazí uložený cíl doslovně — porovnejte ho znak za znakem s tím, co poskytovatel požadoval.

Pošlete vlastníkovi zprávu

Pokud toto opravujete pro klienta nebo svého zaměstnavatele, uzavřete smyčku s důkazem. Znovu spusťte bezplatnou kontrolu jakmile se selektor rozluští a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: s datem, v přímé řeči, DKIM nyní ověřuje. Je to artefakt, který budou potřebovat pro obnovení kybernetického pojištění a příští dotazník bezpečnosti dodavatele — důkaz fungující kontroly, nikoli jen uzavřený tiket.

Zkontrolujte svůj DKIM zdarma

Zjistěte, zda se vaše selektory rozluštují — a přesně co opravit — soukromě a pouze pro vlastníky.

Zkontrolujte svou doménu → · „DKIM signature not valid” → · Opravit DKIM → · Nastavit DKIM na Google Workspace → · Pouze souhrnná data. Data uložena a zpracována v EU.