DKIM-запись не найдена: проверка selector и DNS-имени ключа

Проверка пишет «DKIM-запись не найдена», хотя запись уже добавлена в DNS? Сначала сверьте selector и домен подписи: проверять нужно точное имя ключа, а не просто домен сайта.

Возьмите значения s= и d= из заголовка DKIM-Signature свежего письма. Затем проверьте имя selector._domainkey.домен-подписи, тип записи и ответы действующих DNS-серверов — это поможет отличить ошибку адреса от отсутствующего ключа.

1. Найдите selector у нужного отправителя

Откройте исходник письма, отправленного именно проблемным способом: из формы сайта, CRM или почтового ящика. Не публикуйте исходник целиком: он может содержать адреса и служебные сведения.

В условном примере фрагмент подписи выглядит так:

DKIM-Signature: ... d=mail.example.com; s=site2026; ...

Здесь site2026 — selector, то есть имя выбранного ключа. Искать его надо по адресу site2026._domainkey.mail.example.com. Домен берут из d=, даже если в видимом адресе отправителя указан другой домен; правило формирования имени описано в RFC 6376, раздел 3.6.2.1.

Не подставляйте наугад default, mail или selector из чужой инструкции. У формы сайта и корпоративной почты могут быть разные отправляющие системы. Если подписи нет, начните с настроек DKIM у фактического почтового провайдера: подбор DNS-имени этого не исправит.

2. Проверьте полное DNS-имя и тип

Выполните запросы с компьютера, где установлен dig. Здесь и далее замените пример своими значениями:

dig site2026._domainkey.mail.example.com. TXT
dig site2026._domainkey.mail.example.com. CNAME

Полный вывод полезнее одного +short: в нём видны код ответа, секции ANSWER и AUTHORITY. Пустая строка сокращённого вывода сама по себе не объясняет причину.

Сопоставьте результат с панелью отправляющего сервиса. Если он выдал TXT, проверьте значение ключа; если CNAME — точную цель алиаса и TXT по этому целевому имени. Например, Microsoft 365 использует CNAME для DKIM; нужные значения следует брать из своего кабинета, а не копировать из примера.

Не продублировался ли домен

DNS-панель может автоматически дописывать имя зоны. Если зона — example.com, относительное имя для нашего примера будет site2026._domainkey.mail. Полное имя допустимо только в формате, который поддерживает конкретная панель.

Проверьте сохранённое имя: вариант с окончанием example.com.example.com указывает на лишний суффикс. Не добавляйте запись повторно, пока не сверили фактическое имя и требуемый тип.

3. Сравните ответы DNS-серверов

Убедитесь, что редактируете зону на действующих NS, а не в старом кабинете хостинга. Для обычной зоны список можно начать проверять так:

dig example.com. NS

Если почтовый поддомен делегирован отдельно, используйте серверы его зоны. Запросите точное имя на каждом авторитетном NS; ns1.example.net ниже — условный адрес сервера:

dig @ns1.example.net site2026._domainkey.mail.example.com. TXT +norecurse

Проверьте флаг aa: сервер должен отвечать авторитетно за нужную зону. Для записи CNAME сравните и сам алиас; его цель может обслуживаться уже другими NS.

• NXDOMAIN: запрошенного имени нет. Вернитесь к selector, домену подписи и месту редактирования зоны.
• NOERROR без нужной записи: имя может существовать, но ожидаемый тип отсутствует. Проверьте CNAME и целевое имя.
• SERVFAIL или тайм-аут: сначала исследуйте сбой DNS; сообщение не доказывает отсутствие ключа.
• NS отвечают по-разному: проверьте согласованность зоны. Полезен отдельный разбор сравнения ответов каждого NS.

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

4. Ключ найден — проверьте свежую подпись

Наличие записи ещё не означает успешную проверку письма. Сверьте опубликованное значение с настройками отправителя: ключ мог быть обрезан, заменён или оставлен от другого selector.

Несколько строк в кавычках внутри одной TXT-записи могут быть частями одного значения; несколько отдельных TXT-записей с ключами на одном имени — другая ситуация. Пустой параметр p= означает отзыв ключа, а не рабочую настройку. Эти различия определены в RFC 6376, разделах 3.6.1–3.6.2.

После исправления отправьте новое тестовое письмо на свой ящик тем же маршрутом. В результатах проверки принимающей системы найдите dkim=pass для нужной подписи. Если ключ доступен, но подпись не проходит, следующий этап — проверка соответствия ключевой пары и изменений письма в пути; повторное создание DNS-записи без диагностики не поможет.

Что считать результатом

Проверка завершена, когда точное имя из свежей подписи разрешается через действующие NS, а получатель успешно проверяет эту подпись. Даже этот результат не гарантирует доставку во «Входящие»; если письмо не приходит вовсе, начните с общего разбора формы, DNS и почтовой отправки.

Web-Puls помогает регулярно контролировать доступность сайта, но успешный HTTP-ответ не подтверждает исправность DKIM и доставку писем. Для почтовой проблемы нужен отдельный тест отправки.

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