DKIM «Body Hash Did Not Verify» — что изменило ваше сообщение и как это исправить (2026)

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

Данные по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 миллионам оценённых доменов. См. как мы выставляем оценки.

«Body hash did not verify» означает, что ваша DKIM-подпись была верна в момент, когда сообщение покинуло вас, — а потом что-то переписало тело сообщения. Подпись не сломана; сообщение было изменено в пути. Лишь 3,87% доменов — 10 092 481 — имеют полную триаду SPF-DKIM-DMARC, согласно переписи Defaults.Exposed по 261 086 232 доменам (2026-06-29).

Исправление — это сначала охота, потом решение. Найдите узел, который модифицирует вашу почту: шлюз, добавляющий дисклеймер, устройство, переписывающее ссылки, список рассылки, добавляющий подвал. Затем подписывайте после этого узла, устраните модификацию или сделайте подпись терпимой к ней — именно в таком порядке.

Что на самом деле означает «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-ключ, селектор и конфигурация подписания в полном порядке. Криптография сделала своё дело: тело изменилось между подписанием и проверкой — достаточно одной добавленной строки, одной переписанной ссылки, одного перекодированного символа. (Другое сообщение — signature did not verify, no key for signature — означает другой сбой; начните с «DKIM signature not valid».) И это срочно, потому что несостоявшаяся подпись не может дать DMARC выровненный пройденный тест: если SPF не проходит с выравниванием на том же сообщении, письмо целиком не проходит DMARC.

Что изменило ваше сообщение? Обычные подозреваемые

Что-то на пути доставки отредактировало тело после того, как ваш подписант его запечатал. На практике это одно из четырёх:

Кто изменил	Что меняет	Типичный признак
Исходящий шлюз / smart host (транспортные правила Exchange, Mimecast, Proofpoint, Barracuda…)	Добавляет юридический дисклеймер, маркетинговый подвал или баннер «EXTERNAL:» уже после того, как почтовый сервер подписал письмо	Не проходит каждое сообщение на этом маршруте; прямые отправки в обход шлюза проходят
Устройство безопасности / защита ссылок	Переписывает URL-адреса на сканирующие редиректы, добавляет обёртки отслеживания	Не проходят только сообщения со ссылками
Список рассылки (Google Groups, Mailman…)	Добавляет метку в тему и подвал списка, иногда переформатирует тело	Не проходит только почта, отправленная через список
Пересыльщик / релей, перекодирующий MIME	Перекодирует кодировку символов, переносит строки — незаметно для человека, фатально для хеша	Сбои сосредоточены на одном получателе или адресе пересылки

Первым делом проверьте выделенную жирным строку — почтовый сервер подписывает, пограничное устройство редактирует, и каждое сообщение уходит с подписью, которая была верна тридцать миллисекунд.

Как найти узел, модифицирующий мою почту?

Дифференциальная диагностика — сравните работающий маршрут с проблемным:

Отправьте прямое тестовое сообщение на подконтрольный вам ящик у крупного получателя (Gmail отлично подходит), в обход как можно большей части вашей исходящей цепочки.
Отправьте второе сообщение по проблемному маршруту — через шлюз, через список, на домен затронутого получателя.
Сравните строки Authentication-Results в обоих полных наборах заголовков. Прямая отправка dkim=pass, проблемный маршрут dkim=fail (или dkim=neutral) с body hash did not verify: модификатор живёт между этими двумя маршрутами.
Посмотрите на полученное тело: дисклеймер, баннер или подвал, которых вы не печатали? Ссылки, переписанные на сканирующий домен? Вот ваш узел, поимённо, — а цепочка Received: покажет, какой релей появляется только на проблемном маршруте.

Ваши агрегированные отчёты DMARC рассказывают ту же историю в масштабе: источник, стабильно сообщающий о сбое DKIM при прохождении SPF, — это обычно модификация в пути на вашем собственном маршруте, а не злоумышленник.

Как это исправить?

Запустите бесплатное сканирование на defaults.exposed, прежде чем что-либо менять. Оно подтвердит, что опубликованные DKIM-ключи и политика DMARC в порядке, — так вы отлаживаете одну настоящую проблему, модификацию, а не гоняетесь за призраками в DNS. Проверки со стороны записей описаны на странице исправить DKIM.
Подписывайте после модифицирующего узла. Архитектурно правильное решение: перенесите подписание DKIM на самое внешнее устройство, касающееся сообщения. Компаниям со связкой Exchange плюс шлюз следует подписывать на шлюзе (Mimecast, Proofpoint и аналоги это поддерживают) и отключить подписание выше по цепочке. Если ваш последний узел — Google Workspace или Microsoft 365, подписывайте там и не позволяйте ничему редактировать почту после него — см. настройку DKIM в Google Workspace или Microsoft 365.
Или устраните саму модификацию. Уберите правку из транспортного пути: дисклеймер — в подпись клиента или шаблон вместо транспортного правила; баннер «EXTERNAL:» — только на входящую почту (помечать собственную исходящую почту как внешнюю — ошибка конфигурации вдвойне); аутентифицированную исходящую почту — исключить из перезаписи ссылок.
Используйте канонизацию relaxed/relaxed (c=relaxed/relaxed). Канонизация тела simple ломается на одной перенесённой строке; relaxed терпима к изменениям пробелов и окончаний строк. Будьте честны насчёт предела: relaxed прощает форматирование, но никогда — содержимое: добавленный подвал всё равно ломает хеш, и так и должно быть.
Повторно протестируйте оба маршрута, затем просканируйте домен заново. Оба маршрута должны теперь показывать dkim=pass с вашим доменом в d=, а отчёт сканирования — быть чистым.

Стоит ли использовать тег l=, чтобы DKIM игнорировал добавленное содержимое?

Нет — и относитесь с подозрением к любому руководству, которое это предлагает. Тег l= хеширует только первые N байт тела, так что добавленный подвал больше не ломает подпись. Это «работает» за счёт того, что конец вашего сообщения остаётся неподписанным: любой, у кого есть легитимное подписанное сообщение, может дописать к нему произвольное содержимое — и ваша действительная подпись по-прежнему проходит проверку над результатом. Это дыра для спуфинга, переодетая в исправление: практические злоупотребления продемонстрированы, и некоторые получатели штрафуют или игнорируют l= именно поэтому. Решайте проблему модификации; не оставляйте часть своей почты без подписи.

А что со списками рассылки — их можно починить?

В основном нет — и знание этого сэкономит вам недели. Список, добавляющий метку в тему или подвал, ломает хеш вашего тела по самой своей природе, а список вы не контролируете. Помогают две вещи:

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

Пересылка — смежный случай: она надёжно ломает SPF, но лишь иногда DKIM, поэтому выровненный DKIM — ваша устойчивая к пересылке опора, когда тело выживает: см. пересланная почта не проходит SPF — почему это нельзя исправить.

Почему DKIM ломается так часто, если полный набор есть у столь немногих доменов?

Потому что DKIM — хрупкий средний ребёнок триады: SPF — статичная DNS-запись, DMARC — заявление о политике, а DKIM должен пережить само путешествие. Лишь 51,84% оценённых доменов вообще публикуют обнаружимый DKIM-ключ в DNS, согласно переписи Defaults.Exposed, и лишь 10 092 481 доменов — 3,87% из 261 086 232 оценённых — держат SPF, DKIM и принудительную политику DMARC одновременно (модель зрелости внедрения SPF раскладывает эту лестницу по ступеням). Правильно выполнить это исправление — самая трудная часть вступления в эти 3,87%.

Часто задаваемые вопросы

Является ли «body hash did not verify» признаком того, что кто-то подделывает мой домен? Обычно нет — злоумышленник, как правило, вовсе не может воспроизвести вашу DKIM-подпись, поэтому его почта идёт без подписи или с no key. Несостоявшийся хеш тела означает, что сообщение, действительно подписанное вашей инфраструктурой, было отредактировано после. Проверьте собственный шлюз, прежде чем подозревать атакующего.

SPF на этих сообщениях проходит — я всё ещё в порядке? Пока что, возможно: DMARC достаточно одного выровненного пройденного теста. Но пройденный SPF испаряется в момент, когда кто-либо пересылает сообщение, а если он не выровнен с вашим доменом в From, он и так никогда не засчитывался для DMARC. При том что лишь 3,87% доменов держат полную триаду (перепись 2026-06-29 по 261 086 232 доменам), «одна хромающая опора» — нормальное состояние, причём исправимое.

Исправит ли переход на канонизацию relaxed/relaxed мою проблему с дисклеймером? Нет. Relaxed терпима только к изменениям пробелов и переносов строк. Добавленный дисклеймер — это изменение содержимого, и хеш обязан на нём ломаться: это DKIM работает правильно. Перенесите точку подписания или перенесите дисклеймер.

Сбой происходит только на домене одного клиента. Почему? Почти наверняка их сторона модифицирует входящую почту — устройство безопасности переписывает ссылки или ставит баннеры до запуска их верификатора, либо внутренняя пересылка перекодирует тело. Отправьте им диагностический раздел этой страницы; исправлять нужно их шлюз, а не ваш DNS.

Отправьте владельцу отчёт

Если вы чините это для клиента или работодателя, закройте вопрос доказательством. Когда модифицирующий узел исправлен, повторно запустите бесплатное сканирование и перешлите отчёт с оценкой владельцу бизнеса: датированный, простым языком, DKIM и DMARC на одной странице. Это артефакт, который понадобится при продлении киберстраховки и следующей анкете от заказчика, — доказательство того, что почта, покидающая компанию, теперь и есть та почта, которая приходит.

Проверьте свой домен → · Руководство «DKIM signature not valid» → · Исправить DKIM → · Как мы выставляем оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.