DKIM „Body Hash Did Not Verify” — Какво е променило съобщението и как да го поправите (2026)

Публикувано 2026-07-08

Данни към 2026-06-29 · методология v7. Агрегирани census данни от 261 милиона оценени домейна. Вижте как оценяваме.

„Body hash did not verify” означава, че DKIM подписът е бил валиден когато съобщението е напуснало вас — и нещо е презаписало тялото на съобщението след това. Подписът не е счупен; съобщението е било модифицирано по пътя. Само 3.87% от домейните — 10,092,481 — завършват пълната триада SPF-DKIM-DMARC, според census-а на Defaults.Exposed от 261,086,232 домейна (2026-06-29).

Поправката е търсене, а след това решение. Намерете хопа, който модифицира пощата ви — шлюз, добавящ disclaimer, устройство, пренаписващо линкове, пощенски списък, добавящ footer. След това подписвайте след хопа, спрете модификацията или направете подписа толерантен към нея — в този ред.

Какво всъщност означава „body hash did not verify”?

DKIM подписът (RFC 6376) носи два хеша: bh= — хеш на тялото на съобщението при подписване, и b= — подписва хедърите плюс хеша на тялото. Проверяващият преизчислява хеша на тялото от полученото съобщение; ако не съвпадне с bh=, проверката спира с низа, който всички поставят в търсачката — хедър при получателя като:

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

Това е документираният текст на Microsoft; Gmail често рендира същата диагноза като dkim=neutral (body hash did not verify). Така или иначе, присъдата стеснява проблема значително. DNS ключът, селекторът и конфигурацията за подписване са наред. Криптографията е свършила работата си: тялото е променено между подписване и проверка — един добавен ред, един презаписан URL, един преекодиран символ е достатъчен. (Различно съобщение — signature did not verify, no key for signature — означава различен проблем; започнете с „DKIM подписът не е валиден”.) Спешно е, защото неуспешен подпис не може да даде на DMARC aligned pass: освен ако SPF не минава с alignment за същото съобщение, пощата изцяло не минава DMARC.

Какво е променило съобщението ви? Обичайните заподозрени

Нещо в маршрута на доставка е редактирало тялото след като подписващият го е запечатал. На практика е едно от четири неща:

Кой го е модифицирал	Какво е променено	Типичен признак
Изходящ шлюз / smart host (Exchange transport rules, Mimecast, Proofpoint, Barracuda…)	Добавя правен disclaimer, маркетингов footer или банер „EXTERNAL:” след като пощенският сървър вече е подписал	Всяко съобщение по този маршрут не минава; директни изпращания, заобикалящи шлюза, минават
Устройство за сигурност / защита на линкове	Пренаписва URL-и към scanning redirects, добавя tracking wrappers	Само съобщения с линкове не минават
Пощенски списък (Google Groups, Mailman…)	Добавя таг в темата и footer на списъка, понякога преформатира тялото	Само поща изпратена през списъка не минава
Forwarder / relay, реекодиращ MIME	Преобразува charset, пренавива редове — невидимо за човек, фатално за хеш	Неуспехите се концентрират при един получател или адрес за препращане

Проверете маркирания ред първо — пощенският сървър подписва, крайното устройство редактира, и всяко съобщение излиза с подпис, верен тридесет милисекунди.

Как да намеря хопа, модифициращ пощата ми?

Диференциална диагноза — сравнете маршрут, който работи, срещу маршрута, който не работи:

Изпратете директно тестово съобщение до пощенска кутия, която контролирате при голям получател (Gmail работи добре), заобикаляйки колкото е възможно от изходящата верига.
Изпратете второ съобщение по неминаващия маршрут — през шлюза, през списъка, до домейна на засегнатия получател.
Сравнете редовете Authentication-Results в пълните хедъри на двете. Директно изпращане dkim=pass, неминаващ маршрут dkim=fail (или dkim=neutral) с body hash did not verify: модификаторът се намира между двата маршрута.
Вижте тялото на получения имейл: disclaimer, банер или footer, който не сте въвели? Линкове, пренаписани към scanning домейн? Това е хопът, идентифициран — а верига Received: показва кой relay се появява само в неминаващия маршрут.

DMARC агрегираните ви доклади разказват същата история в мащаб: источник, последователно докладващ DKIM fail при SPF pass, обикновено е модификация по маршрута на собствения ви трафик, а не атакуващ.

Как да го поправя?

Стартирайте безплатното сканиране на defaults.exposed преди да докосвате каквото и да е. Потвърждава, че публикуваните DKIM ключове и DMARC политика са в ред, така че дебъгвате единствения реален проблем — модификацията — а не преследвате призраци в DNS. Страницата за поправка на DKIM покрива проверките от страна на записа.
Подписвайте след модифициращия хоп. Архитектурно правилното решение: преместете DKIM подписването на най-крайното устройство, докосващо съобщението. Средите с Exchange + шлюз трябва да подписват на шлюза (Mimecast, Proofpoint и подобни го поддържат) и да деактивират подписването нагоре по веригата. Ако Google Workspace или Microsoft 365 е последният ви хоп, подписвайте там и не позволявайте на нищо да редактира пощата след него — вижте настройка на DKIM в Google Workspace или Microsoft 365.
Или спрете модификацията. Премахнете редакцията от транспортния маршрут: disclaimer в подписа на клиента или шаблона вместо транспортно правило; банер „EXTERNAL:” ограничен само до входяща поща (маркирането на изходящата ви поща като external е двойна конфигурационна грешка); автентикираната изходяща поща освободена от пренаписване на линкове.
Използвайте relaxed/relaxed канонизация (c=relaxed/relaxed). simple канонизацията на тялото не минава при единствен пренавит ред; relaxed толерира промени в whitespace и окончания на редове. Бъдете честни относно ограничението: relaxed прощава форматирането, но не и съдържанието — добавен footer пак не ще мине, и правилно.
Тествайте отново двата маршрута, след това направете ново сканиране. И двата маршрута трябва сега да показват dkim=pass с вашия домейн в d=, а докладът от сканирането да е чист.

Трябва ли да използвам тага l=, за да накарам DKIM да игнорира добавено съдържание?

Не — и бъдете подозрителни към всяко ръководство, което го предлага. Тагът l= хешира само първите N байта на тялото, така че добавен footer вече не чупи подписа. „Работи” като оставя края на съобщението ви неподписан: всеки, притежаващ легитимно подписано съобщение, може да добави произволно съдържание и валидният ви подпис пак ще провери резултата. Това е дупка за спуфинг, облечена в дрехи на поправка — практическата злоупотреба е демонстрирана, и някои получатели санкционират или игнорират l= точно поради тази причина. Решете модификацията; не подписвайте непотписана част от пощата си.

Какво да правя с пощенски списъци — мога ли да ги поправя?

Предимно не — и знаенето на това спестява седмици. Списък, добавящ таг в темата или footer, чупи хеша на тялото по дизайн, и вие не контролирате списъка. Две неща помагат:

Именно тази остатъчна фракция е защо внедряването на DMARC е поетапно. Преминаването от p=none към p=quarantine с pct= рамп, докато четете агрегирани доклади, означава, че наказаните от списъка съобщения отиват в спам вместо да бъдат унищожени, докато оценявате въздействието — темата на от p=none до p=reject без загуба на легитимен имейл.
ARC е механизъм на получателя, а не ваш. Authenticated Received Chain позволява на списъка да удостовери как е изглеждало автентикирането при пристигането и получателят да реши дали да му се довери. Няма нищо за конфигуриране от ваша страна като изпращач. Добре управляваните списъци смекчават, пренаписвайки хедъра From; лошо управляваните просто чупят пощата ви.

Препращането е сроден случай — то надеждно чупи SPF, но само понякога DKIM, ето защо aligned DKIM е застраховката ви срещу препращане, когато тялото оцелее: вижте препратена поща не минава SPF — защо не можете да го поправите.

Защо DKIM се чупи толкова често, когато толкова малко домейни имат пълния стек?

Защото DKIM е крехкото средно дете на триадата: SPF е статичен DNS запис, DMARC е политическо изявление, но DKIM трябва да оцелее пътуването. Само 51.84% от оценените домейни публикуват открит DKIM ключ в DNS изобщо, според census-а на Defaults.Exposed, а само 10,092,481 домейна — 3.87% от 261,086,232 оценени — притежават SPF, DKIM и прилагаща DMARC политика заедно (моделът за зрялост при приемане на SPF разгражда стълбата). Правилното отстраняване на тази грешка е най-трудната част от присъединяването към тези 3.87%.

Често задавани въпроси

„Body hash did not verify” признак ли е, че някой спуфва домейна ми? Обикновено не — спуфърът обикновено изобщо не може да произведе DKIM подписа ви, така че пощата им не показва подпис или показва no key. Неуспешен body hash означава, че съобщение, действително подписано от вашата инфраструктура, е редактирано след това. Проверете собствения си шлюз преди да предполагате атакуващ.

SPF минава за тези съобщения — добре ли съм? Засега може би: DMARC изисква само един aligned pass. Но SPF pass-ът изчезва в момента, в който някой препрати съобщението, и ако не е aligned с вашия From домейн, никога не се е броил за DMARC. С само 3.87% от домейните, притежаващи пълната триада (census 2026-06-29 на 261,086,232 домейна), „един крак куца” е нормалното състояние — и поправимото.

Преминаването към relaxed/relaxed канонизация ще поправи ли проблема с disclaimer-а? Не. Relaxed толерира само промени в whitespace и пренавиване на редове. Добавен disclaimer е промяна на съдържанието, и хешът задължително ще не мине по него — DKIM работи правилно. Преместете точката на подписване или преместете disclaimer-а.

Проблемът се случва само при домейна на един клиент. Защо? Тяхната страна почти сигурно модифицира входяща поща — устройство за сигурност, пренаписващо линкове или поставящо банери преди верификаторът им да работи, или вътрешно препращане, реекодиращо тялото. Изпратете им диагностичния раздел на тази страница; поправката е на техния шлюз, а не в DNS-а ви.

Изпратете доклада на собственика

Ако поправяте това за клиент или работодател, затворете цикъла с доказателства. След като модифициращият хоп е поправен, пуснете отново безплатното сканиране и препратете оценения доклад на собственика на бизнеса: датиран, разбираем за обикновен човек, DKIM и DMARC на една страница. Това е артефактът, от който ще се нуждаят за подновяването на киберзастраховката и следващия въпросник на доставчик — доказателство, че пощата, напускаща компанията, е пощата, която пристига.

Проверете домейна → · Ръководство „DKIM подписът не е валиден” → · Поправете DKIM → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.