Defaults.Exposed › Opravy › Guides
'DKIM Signature Not Valid' — Příčiny v pořadí, ve kterém je kontrolovat (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 signature not valid” má pět běžných příčin, nejlépe zkontrolovaných v pořadí: obsah upravený při přenosu, zkrácený klíčový záznam, publikovaný klíč neodpovídající podepisovatel, nesprávný selektor a křehká kanonizace. Pouze 10,092,481 z 261,086,232 hodnocených domén (3.87%) drží úplnou triádu SPF + DKIM + vymáhajícího DMARC, podle sčítání Defaults.Exposed (2026-06-29).
Pořadí opravy záleží, protože nejčastější příčina vůbec není ve vašem DNS. Nejprve zkontrolujte, co změnilo zprávu při přenosu, poté pracujte dovnitř: integrita záznamu klíče, zda odpovídá tomu, čím váš poštovní server skutečně podepisuje, selektor a nakonec nastavení podepisování. Většina neplatných podpisů je opravena v prvním nebo druhém kroku.
Co skutečně znamená „DKIM signature not valid”?
Každá DKIM-podepsaná zpráva nese záhlaví DKIM-Signature pojmenovávající doménu (d=), selektor (s=), hash těla zprávy (bh=) a kryptografický podpis nad hashem těla plus vybranými záhlavími (b=). Příjemce načte váš veřejný klíč z DNS na <selektor>._domainkey.<doména>, přepočítá oba hashe a zkontroluje podpis (RFC 6376). „Signature not valid” je jazyk kontrolorů a záhlaví pro: toto ověření proběhlo a selhalo — klíč byl nalezen, ale matematika nevyšla.
Poslední věta je diagnostické zlato. Ověřovatel, který váš klíč nenajde, říká něco jiného — obvykle záhlaví jako dkim=fail (no key for signature) — a to je problém selektoru, pokrytý v DKIM „no key for signature” — oprava selektoru a rotace. A ověřovatel, který přepočítá jiný hash těla, to obvykle říká explicitně: body hash did not verify — Microsoft to hlásí jako dkim=fail (body hash did not verify), zatímco Gmail často zobrazuje stejnou diagnózu jako dkim=neutral (body hash did not verify). V každém případě ukazuje na úpravu obsahu, pokrytou v „body hash did not verify” — co změnilo vaší zprávu. Přečtěte přesné znění v záhlaví Authentication-Results před dotykem čehokoliv: řekne vám, kterou z pěti příčin máte.
Dostat toto správně je vzácné: pouze 51.84% hodnocených domén vůbec publikuje detekovatelný DKIM klíč v DNS, podle sčítání Defaults.Exposed, a pouze 3.87% z 261 milionů hodnocených domén kombinuje SPF, DKIM a vymáhající politiku DMARC — konfiguraci, kterou pravidla hromadných odesílatelů nyní předpokládají. Fáze po fázi obrázek je v modelu zralosti adopce SPF.
Jaké jsou tři příčiny v pořadí?
| # | Příčina | Znaky | Oprava |
|---|---|---|---|
| 1 | Obsah upravený při přenosu — zápatí brány, právní prohlášení, tagy subjektu poštovní konference | body hash did not verify v Authentication-Results; externí pošta selhává, přímá pošta prochází | Podepisujte po úpravě nebo přestaňte upravovat — viz průvodce hash těla |
| 2 | Zkrácený nebo poškozený dlouhý klíč | Publikovaný p= je viditelně kratší než klíč, který jste vygenerovali; každý příjemce selhává | Znovu publikujte 2048-bit klíč jako správně rozdělené TXT řetězce |
| 3 | Publikovaný klíč neodpovídá podepisovatel | Selhání začínají hned po rotaci, migraci nebo změně poskytovatele | Znovu zkopírujte aktuální veřejný klíč od podepisovatel; preferujte delegaci CNAME |
| 4 | Nesprávný nebo chybějící selektor | no key for signature — samotné vyhledávání selhává | Publikujte selektor, který podepisovatel skutečně používá — viz průvodce selektoru |
| 5 | Křehká kanonizace nebo tag l= | Přerušované selhání na triviálně přeformátovaných zprávách | c=relaxed/relaxed; odstraňte l= úplně |
Příčina 1 je tučně zvýrazněna, protože rozbíjí podpisy na zprávách, které byly podepsány dokonale. Bezpečnostní brána připojí prohlášení, zápatí compliance je orazítkováno po podpisu, poštovní konference přidá [listname] k předmětu — tělo nebo podepsaná záhlaví se změní, hashe se již neshodují a podpis je neplatný bez jakéhokoliv pochybení ve vašem DNS. Pokud selhání korelují s poštou, která prošla bránou, konferencí nebo archivačním skokem, začněte tam.
Jak opravím „DKIM signature not valid”?
- Spusťte bezplatnou kontrolu na defaults.exposed před dotykem DNS. Ukáže, zda je váš publikovaný záznam klíče přítomný, dobře formátovaný a úplný — odděluje „váš DNS je rozbitý” (příčiny 2–4) od „váš DNS je v pořádku, zpráva je měněna” (příčina 1) v jednom kroku.
- Přečtěte záhlaví
Authentication-Resultsselhávající zprávy.body hash did not verify→ příčina 1, jděte do průvodce hash těla — obvyklí podezřelí jsou zápatí brány a prohlášení a opravou je podepisování po úpravě.no key for signature→ příčina 4, jděte do průvodce selektoru. Prostá chyba podpisu → pokračujte. - Zkontrolujte publikovaný klíč na zkrácení. Vyhledejte
<selektor>._domainkey.<vasedomena>jako TXT (dig TXT selektor._domainkey.example.com). 2048-bit RSA veřejný klíč je delší než 255-znakový limit jednoho TXT řetězce, takže musí být publikován jako více citovaných řetězců, které příjemci zřetězí — a webová UI DNS poskytovatelů jsou notoricky proslulá tichým zkracováním vložení, poškozením rozdělení nebo vložením mezer a uvozovek do hodnotyp=. Porovnejte znak za znakem s klíčem, který váš podepisovatel vygeneroval; naše průvodci nastavením DKIM pokrývají zvláštnosti per poskytovatele. - Ověřte, že publikovaný klíč odpovídá podepisovatel. Po rotaci klíče, migraci poskytovatele nebo opětovném připojení ESP je běžné, že podepisovatel drží nový soukromý klíč, zatímco DNS stále servíruje starý veřejný klíč — každý podpis se ověří vůči špatnému klíči a selže. Znovu zkopírujte aktuální záznam z administrační konzole svého poskytovatele. Lépe: kde poskytovatel nabízí delegaci CNAME, použijte ji — poskytovatel rotuje klíče na jejich straně a celá třída selhání zmizí. A nikdy nemažte starý selektor, dokud provoz podepsaný s ním neodtekl.
- Opravte nastavení podepisování, nejen záznam. Nastavte kanonizaci na
c=relaxed/relaxed, která toleruje přebalení mezer a přeskládání záhlaví, které meziservery legitimně dělají;simplekanonizace selhává na změnách, které člověk ani nevidí. A nepoužívejte tag délky tělal=: byl zamýšlen pro průchod zápatí, ale umožňuje komukoli připojit obsah k vaší podepsané zprávě bez rozbití podpisu — skutečný vektor útoku — a stále nepřežije většinu úprav brány. Žádnél=je jak bezpečnější, tak spolehlivější volbou. - Znovu naskenujte, poté zkontrolujte zarovnání. Platný podpis pomáhá DMARC pouze tehdy, pokud doména
d=je zarovnána s vaší doménou From — podpis validující jakod=vasefirma.gappssmtp.comprojde DKIM a stále selže DMARC. Pokud jste to vy, viz past výchozího podpisu, poté propracujte vše ostatní, co kontrola označí, na stránce opravit DKIM.
Nejčastější dotazy
Je „DKIM signature not valid” totéž jako „body hash did not verify”? Zpráva o hash těla je jeden konkrétní podpřípad: tělo se změnilo po podpisu (zápatí, prohlášení, přepsání konferencí). „Signature not valid” je souhrnný verdikt pro jakékoliv selhané ověření, včetně špatných klíčů a změn záhlaví — proto je krok 2 výše čtením záhlaví a proč případ hash těla má vlastního průvodce.
Znamená neplatný DKIM podpis, že moje pošta je odmítnuta? Sám o sobě ne — příjemci zacházejí s rozbitým podpisem jako s chybějícím. Poškození přichází přes DMARC: pokud SPF také neprojde se zarovnáním, zpráva selže DMARC a vaše publikovaná politika se uplatní. K datu sčítání 2026-06-29 pouze 3.87% z 261,086,232 hodnocených domén drží SPF, DKIM a vymáhající politiku DMARC dohromady — ale Gmail a Microsoft nyní očekávají přesně toto od odesílatelů, takže rozbitá noha DKIM stojí doručitelnost ještě před odmítnutím.
Mám použít 1024-bit nebo 2048-bit DKIM klíč? 2048-bit — 1024-bit klíče jsou pod aktuálními kryptografickými doporučeními a někteří příjemci je hodnotí níže. Úskalí je čistě provozní: 2048-bit klíč se nevejde do jednoho 255-znakového TXT řetězce, takže musí být správně rozdělen (příčina 2 výše). Delegace CNAME na poskytovatele zcela obchází problém rozdělení.
Můj DKIM prochází kontrolorem, ale DMARC stále selhává — jak?
Téměř jistě zarovnání: podpis je platný, ale jeho doména d= (say, vasefirma.gappssmtp.com nebo vastenant.onmicrosoft.com) neodpovídá vaší doméně From, takže DMARC ho nemůže použít. Povolte podepisování vlastní domény svého poskytovatele — úplný průvodce je v průvodci pastí výchozího podpisu.
Mohu prostě vypnout DKIM, pokud stále selhává? Ne — od mandátů hromadných odesílatelů 2024 vyžadují Gmail a Yahoo DKIM pro odesílatele s objemem a vymáhající politika DMARC realisticky potřebuje DKIM, protože SPF samo se rozbíjí při přesměrování. Opravte podpis; výše uvedené příčiny jsou všechny opravitelné za odpoledne.
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 po svých změnách a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: s datem, v přímé řeči, DKIM zobrazující zeleně. Je to artefakt, který budou potřebovat pro obnovení kybernetického pojištění a příští dotazník bezpečnosti dodavatele — rozdíl mezi „opravil/a jsem DNS věc” a zdokumentovaný stav před a po, který říká, že doména ověřuje svou poštu.
Zkontrolujte svou doménu → · Průvodce „Body hash did not verify” → · Opravit DKIM → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.