«DKIM signature not valid» — причины в том порядке, в котором их проверять (2026)

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

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

У ошибки «DKIM signature not valid» пять типичных причин, и проверять их лучше по порядку: содержимое изменено в пути, обрезанная запись ключа, опубликованный ключ не совпадает с подписывающей стороной, неправильный селектор и хрупкая канонизация. Лишь 10 092 481 из 261 086 232 оценённых доменов (3,87%) имеют полную триаду SPF + DKIM + принудительный DMARC — по данным переписи Defaults.Exposed (2026-06-29).

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

Что на самом деле означает «DKIM signature not valid»?

Каждое подписанное DKIM сообщение несёт заголовок DKIM-Signature, в котором указаны домен (d=), селектор (s=), хеш тела сообщения (bh=) и криптографическая подпись хеша тела вместе с выбранными заголовками (b=). Получатель извлекает ваш открытый ключ из DNS по адресу <selector>._domainkey.<domain>, пересчитывает оба хеша и проверяет подпись (RFC 6376). «Signature not valid» на языке проверок и заголовков означает: эта проверка была выполнена и провалилась — ключ найден, но математика не сошлась.

Последняя оговорка — диагностическое золото. Проверяющий, который не может найти ваш ключ, сообщает иначе — обычно заголовком вида dkim=fail (no key for signature), — и это проблема селектора, разобранная в руководстве DKIM «no key for signature» — исправления селектора и ротации. А проверяющий, который пересчитал другой хеш тела, обычно говорит об этом явно: body hash did not verify — Microsoft сообщает это как dkim=fail (body hash did not verify), а Gmail часто выводит тот же диагноз как dkim=neutral (body hash did not verify). В обоих случаях это указывает на изменение содержимого, разобранное в руководстве «body hash did not verify» — что изменило ваше сообщение. Прежде чем что-либо трогать, прочитайте точную формулировку в заголовке Authentication-Results: она говорит, какая из пяти причин у вас на руках.

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

Каковы пять причин — по порядку?

#	Причина	Признак	Исправление
1	Содержимое изменено в пути — подписи шлюзов, юридические оговорки, теги рассылок в теме	`body hash did not verify` в Authentication-Results; внешняя почта не проходит, прямая проходит	*Подписывать после* изменения или прекратить изменять — см. руководство по body hash**
2	Обрезанный или искажённый длинный ключ	Опубликованный `p=` заметно короче сгенерированного вами ключа; проверка не проходит у всех получателей	Заново опубликовать 2048-битный ключ в виде правильно разбитых строк TXT
3	Опубликованный ключ не совпадает с подписывающей стороной	Сбои начинаются сразу после ротации, миграции или смены провайдера	Заново скопировать текущий открытый ключ у подписывающей стороны; предпочесть делегирование через CNAME
4	Неправильный или отсутствующий селектор	`no key for signature` — сам запрос ключа не выполняется	Опубликовать селектор, который реально использует подписывающая сторона, — см. руководство по селекторам
5	Хрупкая канонизация или тег `l=`	Периодические сбои на тривиально переформатированных сообщениях	`c=relaxed/relaxed`; полностью убрать `l=`

Причина 1 выделена жирным, потому что она ломает подписи сообщений, которые были подписаны безупречно. Шлюз безопасности добавляет оговорку, комплаенс-подпись ставится после подписывания, список рассылки добавляет [listname] в тему — тело или подписанные заголовки меняются, хеши больше не совпадают, и подпись недействительна без всякой вины вашего DNS. Если сбои коррелируют с почтой, прошедшей через шлюз, рассылку или архивирующий узел, начинайте оттуда.

Как исправить «DKIM signature not valid»?

Запустите бесплатное сканирование на defaults.exposed, прежде чем трогать DNS. Оно показывает, существует ли ваша опубликованная запись ключа, корректно ли она оформлена и полна ли, — за один шаг отделяя «ваш DNS сломан» (причины 2–4) от «ваш DNS в порядке, сообщение изменяют в пути» (причина 1).
Прочитайте заголовок Authentication-Results непрошедшего сообщения. body hash did not verify → причина 1, переходите к руководству по body hash — обычные подозреваемые: подписи шлюзов и оговорки, а исправление — подписывать после изменения. no key for signature → причина 4, переходите к руководству по селекторам. Просто недействительная подпись → продолжайте.
Проверьте опубликованный ключ на обрезание. Запросите <selector>._domainkey.<yourdomain> как TXT (dig TXT selector._domainkey.example.com). Открытый 2048-битный ключ RSA длиннее лимита в 255 символов для одной строки TXT, поэтому он должен публиковаться как несколько строк в кавычках, которые получатели склеивают, — а веб-интерфейсы DNS-провайдеров печально известны тем, что молча обрезают вставку, портят разбиение или добавляют пробелы и кавычки в значение p=. Сравните посимвольно с ключом, который сгенерировала ваша подписывающая система; наши пошаговые руководства по настройке DKIM разбирают причуды конкретных провайдеров.
Убедитесь, что опубликованный ключ соответствует подписывающей стороне. После ротации ключа, миграции провайдера или переподключения ESP нередко бывает так: подписывающая сторона держит новый закрытый ключ, а DNS всё ещё отдаёт старый открытый — каждая подпись проверяется по не тому ключу и не проходит. Заново скопируйте текущую запись из консоли администрирования вашего провайдера. Ещё лучше: если провайдер предлагает делегирование через CNAME, используйте его — провайдер ротирует ключи на своей стороне, и весь этот класс сбоев исчезает. И никогда не удаляйте старый селектор, пока не иссякнет трафик, подписанный им.
Исправьте настройки подписывания, а не только запись. Установите канонизацию c=relaxed/relaxed, которая терпима к переносу пробелов и перекладыванию заголовков — законным действиям промежуточных серверов; канонизация simple ломается на изменениях, которые человек даже не увидит. И не используйте тег длины тела l=: он задумывался, чтобы пропускать подписи-футеры, но позволяет кому угодно дописывать содержимое к вашему подписанному сообщению, не ломая подпись, — реальный вектор атаки, — и при этом всё равно не переживает большинство изменений на шлюзах. Отсутствие l= — выбор одновременно более безопасный и более надёжный.
Пересканируйте, затем проверьте выравнивание. Действительная подпись помогает DMARC, только если домен d= выравнивается с вашим доменом From — подпись, проходящая проверку как d=yourcompany.gappssmtp.com, проходит DKIM и всё равно не проходит DMARC. Если это ваш случай, см. ловушку подписи по умолчанию, а затем разберитесь со всем остальным, что отметило сканирование, на странице исправить DKIM.

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

«DKIM signature not valid» — это то же самое, что «body hash did not verify»? Сообщение о хеше тела — один конкретный частный случай: тело изменилось после подписывания (футеры, оговорки, переписывание рассылками). «Signature not valid» — общий вердикт для любой провалившейся проверки, включая плохие ключи и изменения заголовков, — поэтому шаг 2 выше — это чтение заголовка, а для случая с хешем тела есть отдельное руководство.

Означает ли недействительная подпись DKIM, что мою почту отклоняют? Сама по себе — нет: получатели относятся к сломанной подписи как к отсутствующей. Ущерб приходит через DMARC: если SPF тоже не проходит с выравниванием, сообщение не проходит DMARC и применяется ваша опубликованная политика. По данным переписи 2026-06-29, лишь 3,87% из 261 086 232 оценённых доменов имеют одновременно SPF, DKIM и принудительную политику DMARC — но Gmail и Microsoft теперь ожидают от отправителей именно этого, так что сломанная опора DKIM стоит доставляемости ещё до всяких отклонений.

Какой ключ DKIM использовать — 1024-битный или 2048-битный? 2048-битный: 1024-битные ключи ниже текущих криптографических рекомендаций, и некоторые получатели снижают за них оценку. Загвоздка чисто операционная: 2048-битный ключ не помещается в одну строку TXT из 255 символов, поэтому его нужно правильно разбивать (причина 2 выше). Делегирование через CNAME вашему провайдеру полностью обходит проблему разбиения.

Мой DKIM проходит в инструменте проверки, а DMARC всё равно не проходит — как так? Почти наверняка выравнивание: подпись проходит проверку, но её домен d= (скажем, yourcompany.gappssmtp.com или yourtenant.onmicrosoft.com) не совпадает с вашим доменом From, поэтому DMARC не может её использовать. Включите у провайдера подписывание собственным доменом — полное пошаговое руководство в руководстве о ловушке подписи по умолчанию.

Можно ли просто отключить DKIM, если он всё время не проходит? Нет — после требований к массовым отправителям 2024 года Gmail и Yahoo требуют DKIM от отправителей с большими объёмами, а принудительной политике DMARC DKIM реально необходим, потому что один SPF ломается при пересылке. Чините подпись: все перечисленные причины исправимы за полдня.

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

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

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