DKIM «No Key for Signature»: исправление селектора и ротации (2026)

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

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

«No key for signature» означает, что получатель запросил DNS-запись, на которую указывает ваша подпись DKIM — selector._domainkey.yourdomain — и не нашёл ключа: он либо никогда не публиковался, либо был удалён посреди ротации. Опубликуйте селектор, который реально использует подписывающая сторона. Лишь 10 092 481 доменов — 3,87% — имеют полную триаду SPF+DKIM+DMARC, по данным переписи Defaults.Exposed из 261 086 232 оценённых доменов.

Исправление — это одна DNS-запись, найденная в одном заголовке. Прочитайте теги s= и d= из реального заголовка DKIM-Signature, чтобы узнать, каким селектором подписывается ваша почта, опубликуйте (или почините) ровно эту запись — и предпочтите делегирование через CNAME, чтобы провайдер ротировал ключи за вас. Затем ротируйте по регламенту ниже: эта ошибка обычно означает, что кто-то удалил старый селектор слишком рано.

Что означает «dkim no key for signature»?

Каждая подпись DKIM несёт два тега, говорящих получателю, откуда взять открытый ключ: d= (подписывающий домен) и s= (селектор). Получатель запрашивает одно DNS-имя, собранное из них — s._domainkey.d, — чтобы получить ключ. «No key for signature» означает, что этот запрос вернулся пустым: подпись есть, а ключа, на который она указывает, нет.

Формулировка встречается в заголовках Authentication-Results и в агрегированных отчётах DMARC — точный текст различается у получателей, но важны два варианта:

Строка результата (фрагмент, в широко наблюдаемом виде)	Что произошло на самом деле	Временная?
`dkim=temperror (no key for signature)`	DNS-запрос не выполнился или истёк по таймауту — получатель вообще не смог получить ответ	Да — повторные попытки часто проходят; расследуйте, только если ошибка устойчива
`dkim=permerror (no key for signature)`	DNS-запрос выполнился, и ответ был «такой записи нет» — селектор действительно отсутствует	Нет — запись отсутствует, пока вы её не опубликуете

Разовый temperror — это «погода» в DNS. Permerror — или temperror, повторяющийся днями и у разных получателей, — означает, что записи, на которую указывает подпись, нет в вашей зоне. Об этом и есть это руководство.

Последствие: неподдающаяся проверке подпись засчитывается как отсутствие DKIM вообще, поэтому DMARC опирается на один SPF — а SPF ломается при пересылке. Если подпись присутствует, но недействительна, а не отсутствует (хеш тела, искажённый ключ), это другой сбой — см. «DKIM signature not valid».

Как узнать, каким селектором подписывается моя почта?

Не гадайте по документации провайдера — прочитайте его из реального сообщения:

Отправьте сообщение из проблемной системы на почтовый ящик, который вы контролируете (хорошо подходит адрес Gmail).
Откройте исходный текст письма («Show original» в Gmail, «View message source» в Outlook).
Найдите заголовок DKIM-Signature: и прочитайте два тега: s= — это селектор, d= — это подписывающий домен. Иллюстративный пример: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Получатель запрашивает запись s._domainkey.d — здесь это mail2026._domainkey.yourdomain.com. Проверьте сами: dig TXT mail2026._domainkey.yourdomain.com +short. Пустой ответ = ошибка реальна для каждого получателя.
Повторите для каждой отправляющей системы. Сообщение может нести несколько подписей DKIM — почтовый провайдер, инструмент рассылок, служба поддержки — каждая со своей парой s=/d= и своей записью. Почините ту, что не проходит, и обратите внимание на её d=: DMARC помогает только подпись, у которой d= совпадает с вашим доменом From.

Почему запись селектора отсутствует?

Почти все такие ошибки объясняются четырьмя причинами — проверяйте их в этом порядке:

Её никогда не публиковали. Подписывающую систему включили (или она включилась по умолчанию) с селектором, который никто не добавил в DNS. Типично для новых инструментов и шлюзов, которые подписывают неожиданно.
Её удалили посреди ротации. Кто-то «прибрался» и удалил старый селектор, пока подписанные им сообщения ещё были в пути, стояли в очередях на повтор или ожидали пересылки. Эта почта уже подписана с s=old; удаление old._domainkey задним числом ломает каждое из этих сообщений.
Ваш DNS-интерфейс исказил целевой адрес CNAME. Многие провайдеры делегируют через CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), а многие DNS-панели молча дописывают вашу зону к целевому адресу — сохраняя s1.domainkey.u123.esp.com.yourdomain.com, который никуда не резолвится. Проверьте целевой адрес: dig CNAME s1._domainkey.yourdomain.com +short. Та же ловушка кусает при миграции инструментов — см. DKIM сломался после смены почтовых инструментов.
Провайдер ротировал ключ, а ваша зона — нет. Ключ провайдера, вставленный как статическая TXT-запись (вместо их CNAME), осиротеет при их плановой ротации — подписывающая система переходит на селектор, который вы никогда не публиковали. Лишь 51,84% из 261 млн доменов в переписи предъявляют обнаружимый ключ DKIM на момент сканирования (данные по состоянию на 2026-06-29).

Как исправить «no key for signature»?

Запустите бесплатное сканирование на defaults.exposed, прежде чем трогать DNS. Оно читает ваши живые записи DKIM, SPF и DMARC и показывает, что реально видят получатели, — включая то, резолвится ли селектор и не искажён ли целевой адрес CNAME.
Опубликуйте селектор, который реально использует подписывающая сторона — значение s= из заголовка, а не из старого регламента. Возьмите запись из консоли администрирования провайдера (настройка DKIM в Google Workspace · настройка DKIM в Microsoft 365) и добавьте её точно по адресу s._domainkey.yourdomain.com.
Предпочитайте делегирование через CNAME вставке TXT-ключа. Если провайдер предлагает DKIM-записи CNAME, используйте их: ключ живёт в их зоне, и они ротируют его без вашего участия в DNS — причина 4 становится невозможной. Платформы рассылок почти все работают именно так; см. письма Mailchimp/Brevo/Klaviyo не проходят DMARC.
Проверьте извне вашей панели. dig TXT s._domainkey.yourdomain.com +short (или dig CNAME … для делегированных селекторов) с машины вне вашей сети. То, что панель показывает запись, ничего не доказывает, если зона отдаёт что-то другое.
Пересканируйте и отправьте тестовое сообщение заново. Authentication-Results теперь должен показывать dkim=pass. Затем разберитесь со всем остальным, что отметило сканирование, на странице исправить DKIM — проходящая проверку подпись, не выровненная с вашим доменом From, всё равно не проходит DMARC.

Как ротировать ключи DKIM, не вызывая эту ошибку?

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

Шаг	Действие	Условие перед следующим шагом
1. Добавить	Опубликуйте новый селектор (`s2._domainkey…`) рядом со старым	`dig` подтверждает, что он резолвится извне
2. Переключить	Направьте подписывающую систему на новый селектор	Тестовое сообщение показывает `s=s2` и `dkim=pass`
3. Ждать	Оставьте старый селектор опубликованным, пока стекает трафик в пути, в очередях и на пересылке	≥ 7 дней; следите за агрегированными отчётами DMARC, пока старый селектор не перестанет появляться
4. Вывести из строя	Удалите старый ключ — а лучше переопубликуйте его с пустым тегом `p=`: «выведен из эксплуатации», а не «никогда не существовал»	Никогда не начинайте это в момент переключения — преждевременное удаление — причина №1 ошибки «no key for signature»

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

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

«No key for signature» — это temperror или permerror? Существуют обе строки: temperror — это DNS-запрос, который не выполнился или истёк по таймауту, — временное явление, часто исчезающее при повторе, — а permerror означает, что DNS ответил «такой записи нет». Temperror, повторяющийся у разных получателей, обычно тоже оказывается действительно отсутствующей записью. Проверьте через dig и доверяйте ответу, а не ярлыку.

Означает ли эта ошибка, что кто-то подделывает мой домен? Нет — злоумышленник не стал бы подписываться вашим селектором. Она означает, что ваша собственная почта несёт подпись, которую получатели не могут проверить, поэтому она засчитывается как неподписанная, и DMARC опирается на один SPF. Полная выровненная аутентификация встречается редко: лишь 10 092 481 из 261 086 232 доменов (3,87%) имеют полную триаду SPF+DKIM+DMARC по данным переписи Defaults.Exposed (данные по состоянию на 2026-06-29).

Можно ли просто удалить старый селектор, как только заработает новый? Не сразу. Подписанные им сообщения всё ещё находятся в очередях повторов и на путях пересылки; удаление ключа ломает их задним числом. Держите старую запись минимум неделю, следите за отчётами DMARC, пока старый селектор не перестанет появляться, затем выводите его из эксплуатации — в идеале пустым p=, а не удалением.

Проверка у моего провайдера говорит, что DKIM настроен, а получатели всё равно сообщают об отсутствии ключа. Как так? Почти всегда это ловушка целевого адреса CNAME: ваша DNS-панель дописала вашу зону к целевому адресу (…esp.com.yourdomain.com), поэтому запись существует, но указывает в никуда. dig CNAME selector._domainkey.yourdomain.com +short показывает сохранённый целевой адрес дословно — сравните его посимвольно с тем, что просил провайдер.

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

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

Проверьте свой DKIM бесплатно

Узнайте, резолвятся ли ваши селекторы — и что именно исправлять, — приватно и только для владельца.

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