DKIM „Body Hash Did Not Verify" — Co změnilo vaší zprávu a jak to opravit (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.

„Body hash did not verify” znamená, že váš DKIM podpis byl platný, když zpráva odešla od vás — a něco přepsalo tělo zprávy poté. Podpis není rozbitý; zpráva byla upravena při přenosu. Pouze 3.87% domén — 10,092,481 — dokončí úplnou triádu SPF-DKIM-DMARC, podle sčítání Defaults.Exposed zahrnujícího 261,086,232 domén (2026-06-29).

Oprava je hledání, potom rozhodnutí. Najděte skok, který modifikuje vaši poštu — brána připojující prohlášení, zařízení přepisující odkazy, poštovní konference přidávající zápatí. Poté podepisujte po tomto skoku, zastavte modifikaci nebo udělejte podpis tolerantním vůči ní — v tomto pořadí.

Co skutečně znamená „body hash did not verify”?

DKIM podpis (RFC 6376) nese dva hashe: bh=, hash těla zprávy jak byl podepsán, a b=, který podepisuje záhlaví plus tento hash těla. Ověřovatel přepočítá hash těla ze zprávy, kterou přijal; pokud neodpovídá bh=, ověřování se zastaví s řetězcem, který všichni vkládají do vyhledávacího pole — záhlaví příjemce jako:

Authentication-Results: …; dkim=fail (body hash did not verify)

To je zdokumentovaný řetězec důvodu od Microsoftu; Gmail často zobrazuje stejnou diagnózu jako dkim=neutral (body hash did not verify). Každopádně verdikt enormně zužuje problém. Váš DNS klíč, selektor a konfigurace podepisování jsou všechny v pořádku. Kryptografie odvedla svou práci: tělo se změnilo mezi podpisem a ověřením — jeden připojený řádek, jeden přepsaný URL, jeden překódovaný znak stačí. (Jiná zpráva — signature did not verify, no key for signature — znamená jiné selhání; začněte s „DKIM signature not valid”.) A je to naléhavé, protože selhavší podpis nemůže dát DMARC zarovnaný průchod: pokud SPF neprojde se zarovnáním na stejné zprávě, pošta selže DMARC úplně.

Co změnilo vaší zprávu? Obvyklí podezřelí

Něco v cestě doručení upravilo tělo poté, co ho váš podepisovatel zapečetil. V praxi je to jedna ze čtyř věcí:

Kdo to upravil	Co změní	Typický znak
Odchozí brána / smart host (Exchange transportní pravidla, Mimecast, Proofpoint, Barracuda…)	Připojí právní prohlášení, marketingové zápatí nebo banner „EXTERNAL:” poté, co poštovní server již podepsal	Každá zpráva na této cestě selže; přímé odesílání obcházející bránu projde
Bezpečnostní zařízení / ochrana odkazů	Přepíše URL na skenovací přesměrování, přidá sledovací obaly	Selžou pouze zprávy obsahující odkazy
Poštovní konference (Google Groups, Mailman…)	Přidá tag předmětu a zápatí konference, někdy přeformátuje tělo	Selže pouze pošta odeslaná přes konferenci
Přesměrovávač / relay překódovávající MIME	Překóduje charset, přebalí řádky — neviditelné pro člověka, fatální pro hash	Selhání se shlukují na jednom příjemci nebo přesměrovávací adrese

Nejprve zkontrolujte tučně zvýrazněný řádek — poštovní server podepíše, okrajové zařízení upraví a každá zpráva odchází s podpisem, který byl pravdivý po třicet milisekund.

Jak najdu skok, který modifikuje moji poštu?

Diferenciální diagnóza — porovnejte cestu, která funguje, s cestou, která selhává:

Odešlete přímou testovací zprávu do poštovní schránky, kterou ovládáte, u hlavního příjemce (Gmail funguje dobře), obejdete co nejvíce svého odchozího řetězce.
Odešlete druhou zprávu po selhávající cestě — přes bránu, přes konferenci, na doménu postiženého příjemce.
Porovnejte řádky Authentication-Results v obou úplných záhlavích. Přímé odeslání dkim=pass, selhávající cesta dkim=fail (nebo dkim=neutral) s body hash did not verify: modifikátor žije mezi těmito dvěma cestami.
Podívejte se na přijaté tělo: prohlášení, banner nebo zápatí, které jste nevnapsali? Přepsané odkazy na skenovací doménu? To je váš skok, pojmenovaný — a řetězec Received: ukazuje, který relay se objevuje pouze v selhávající cestě.

Vaše souhrnné DMARC zprávy říkají totéž ve velkém měřítku: zdroj konzistentně hlásící selhání DKIM s průchodem SPF je obvykle modifikace při přenosu na vaší vlastní cestě, nikoli útočník.

Jak to opravím?

Spusťte bezplatnou kontrolu na defaults.exposed před dotykem čehokoliv. Potvrdí, že vaše publikované DKIM klíče a politika DMARC jsou v pořádku, takže ladíte jeden skutečný problém — modifikaci — nikoli pronásledujete přízraky v DNS. Stránka opravit DKIM pokrývá kontroly na straně záznamu.
Podepisujte po modifikujícím skoku. Architektonicky správná oprava: přesuňte DKIM podepisování na nejzevnější zařízení, které se dotýká zprávy. Provozovny Exchange plus brána by měly podepisovat na bráně (Mimecast, Proofpoint a jejich kolegové to vše podporují) a deaktivovat podepisování upstream. Pokud Google Workspace nebo Microsoft 365 je vaším posledním skokem, podepisujte tam a nenechte nic upravovat poštu po tom — viz nastavit DKIM na Google Workspace nebo Microsoft 365.
Nebo zastavte modifikaci. Vezměte úpravu z transportní cesty: prohlášení do podpisu klienta nebo šablony namísto transportního pravidla; banner „EXTERNAL:” omezený pouze na příchozí poštu (označení vlastní odchozí pošty jako externí je chybná konfigurace hned dvakrát); ověřená odchozí pošta vyjmutá z přepisování odkazů.
Použijte kanonizaci relaxed/relaxed (c=relaxed/relaxed). simple kanonizace těla selže na jediném přebalením řádku; relaxed toleruje změny mezer a konců řádků. Buďte čestní o limitu: relaxed odpouští formátování, nikdy obsah — připojené zápatí stále selže, jak by mělo.
Znovu otestujte obě cesty, poté znovu naskenujte. Obě cesty by nyní měly zobrazovat dkim=pass s vaší doménou v d= a zpráva skenování by měla být čistá.

Mám použít tag l= pro toleranci připojeného obsahu?

Ne — a buďte podezřiví vůči každému průvodci, který to navrhuje. Tag l= hashuje pouze prvních N bajtů těla, takže připojené zápatí již neruší podpis. „Funguje” tím, že nechává konec vaší zprávy nepodepsaný: kdokoliv drží legitimně podepsanou zprávu, může připojit libovolný obsah a váš platný podpis se stále ověří nad výsledkem. To je spoofingová díra oblečená jako oprava — praktické zneužití bylo demonstrováno a někteří příjemci penalizují nebo ignorují l= přesně z tohoto důvodu. Vyřešte modifikaci; nepodepisujte část své pošty.

Co s poštovními konferencemi — mohu to opravit?

Většinou ne — a vědět to vám ušetří týdny. Konference, která přidává tag předmětu nebo zápatí, záměrně rozbíjí váš hash těla a vy konferenci nekontrolujete. Dvě věci pomáhají:

Tento zbytek je přesně důvod, proč je nasazení DMARC postupné. Přechod z p=none přes p=quarantine s rampou pct=, zatímco čtete souhrnné zprávy, znamená, že zprávy poškozené konferencí jdou do karantény namísto zničení, zatímco posuzujete dopad — tématem z p=none na p=reject bez ztráty legitimní pošty.
ARC je mechanismus příjemce, nikoli váš. Authenticated Received Chain umožňuje konferenci dosvědčit, jak vypadalo ověřování při příchodu a příjemci rozhodnout, zda tomu věřit. Vy, jako odesílatel, nemáte co konfigurovat. Dobře spravované konference zmírňují přepsáním záhlaví From; špatně spravované prostě rozbijí vaši poštu.

Přesměrování je sousední případ — spolehlivě rozbíjí SPF, ale pouze někdy DKIM, což je důvod, proč zarovnaný DKIM je vaše noha odolná vůči přesměrování, když tělo přežije: viz přeposlaný e-mail selže SPF — proč to nemůžete opravit.

Proč se DKIM tak často rozbíjí, když tak málo domén má vůbec celý zásobník?

Protože DKIM je křehké prostřední dítě triády: SPF je statický DNS záznam, DMARC prohlášení o politice, ale DKIM musí přežít cestu. Pouze 51.84% hodnocených domén vůbec publikuje detekovatelný DKIM klíč v DNS, podle sčítání Defaults.Exposed, a pouze 10,092,481 domén — 3.87% z 261,086,232 hodnocených — drží SPF, DKIM a vymáhající politiku DMARC dohromady (model zralosti adopce SPF rozkládá žebřík). Správné provedení této opravy je nejtěžší část přidání se k těm 3.87%.

Nejčastější dotazy

Je „body hash did not verify” znakem, že někdo spoofuje moji doménu? Obvykle ne — spoofátor typicky vůbec nemůže vytvořit váš DKIM podpis, takže jejich pošta nezobrazuje žádný podpis nebo no key. Selhavší hash těla znamená, že zpráva skutečně podepsaná vaší infrastrukturou byla poté upravena. Nejprve zkontrolujte svou vlastní bránu, než budete předpokládat útočníka.

SPF prochází u těchto zpráv — jsem stále v pořádku? Zatím možná: DMARC potřebuje pouze jeden zarovnaný průchod. Ale průchod SPF se odpaří ve chvíli, kdy někdo zprávu přepošle a pokud není zarovnaný s vaší doménou From, nikdy se pro DMARC nepočítal. S pouze 3.87% domén držících úplnou triádu (sčítání 2026-06-29 zahrnující 261,086,232 domén), „jedna noha kulhá” je normální stav — a opravitelný.

Vyřeší přechod na kanonizaci relaxed/relaxed můj problém s prohlášením? Ne. Relaxed toleruje pouze změny mezer a přebalení řádků. Připojené prohlášení je změna obsahu a hash na ní musí selhat — to je DKIM fungující správně. Přesuňte bod podepisování nebo přesuňte prohlášení.

Selhání se děje pouze u domény jednoho zákazníka. Proč? Jejich strana téměř jistě modifikuje příchozí poštu — bezpečnostní zařízení přepisující odkazy nebo razítkující bannery před spuštěním jejich ověřovatele, nebo interní přesměrování překódovávající tělo. Pošlete jim sekci diagnostiky této stránky; oprava je na jejich bráně, nikoli ve vašem DNS.

Pošlete vlastníkovi zprávu

Pokud toto opravujete pro klienta nebo svého zaměstnavatele, uzavřete smyčku s důkazem. Jakmile je modifikující skok opraven, znovu spusťte bezplatnou kontrolu a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: s datem, v přímé řeči, DKIM a DMARC stojící na jedné stránce. Je to artefakt, který budou potřebovat pro obnovení kybernetického pojištění a příští dotazník dodavatele — důkaz, že pošta opouštějící firmu je nyní poštou, která dorazí.

Zkontrolujte svou doménu → · Průvodce „DKIM signature not valid” → · Opravit DKIM → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.