Настройка DKIM: создать ключ и добавить запись в DNS

DKIM не настроена: что это значит и что чинить

Формулировку «DKIM не настроена» человек обычно видит не в документации, а в отчёте почтового сервиса или в письме от получателя. Означает она одно из трёх, и лечится по-разному.

Первое. Записи в DNS нет вовсе. Проверка ищет её по адресу селектор._domainkey.ваш-домен и не находит ничего. Так бывает, когда ключ сгенерировали и забыли опубликовать, либо опубликовали не на том домене, что случается с поддоменами чаще, чем хотелось бы.

Второе. Запись есть, а письма ей не подписываются. Со стороны DNS всё выглядит правильно, а в заголовках писем DKIM-Signature отсутствует. Подпись ставит не DNS, а тот сервер или сервис, который отправляет почту, и включать её нужно именно там, в настройках отправки, а не в зоне домена.

Третье. Подпись есть, но получатель её не засчитывает. Обычно причина в том, что письмо подписано доменом сервиса рассылок, а не вашим. Формально проверка проходит, подпись валидна, но выравнивание с адресом в поле From не сходится, и DMARC отказывается засчитывать такую подпись как вашу.

Различить эти случаи можно за минуту, и лезть в панель для этого не надо. Откройте исходник любого отправленного письма и найдите заголовок DKIM-Signature. Нет заголовка, случай второй. Есть, но в теге d= чужой домен, случай третий. А если проверка селектора в DNS молчит, первый.

Где взять DKIM-ключ у популярных провайдеров

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

В Яндекс 360 ключ лежит в администрировании домена, в разделе про почту: там же показана готовая TXT-запись и селектор mail. Mail.ru для бизнеса отдаёт значение в настройках домена, селектор обычно mailru. У reg.ru подпись включается в панели управления почтой, ключ создаётся автоматически при включении. Beget и Timeweb работают так же: включаете DKIM в настройках почты домена, панель сама добавляет запись в зону, если DNS обслуживается у них. У nic.ru запись придётся добавить руками, скопировав значение из почтового раздела.

Собственный ключ нужен в одном случае. Когда почту отправляет ваш сервер или сервис, который ключи не генерирует. Тогда его создаёт форма выше, и приватную часть вы отдаёте своему почтовому серверу.

Что делать после публикации записи

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

Дальше отправьте письмо на любой свой ящик и посмотрите заголовки, лучше всего в Gmail, где исходник открывается в два клика. Если DKIM- Signature на месте, а Authentication-Results показывает dkim=pass, подпись работает. Если dkim=fail, обычно виноват перенос строки внутри значения: длинный ключ разбили на части, и часть панелей склеивает их с лишними пробелами.

Как устроен DKIM

Почтовый сервер подписывает исходящее письмо закрытым ключом и добавляет подпись в заголовок DKIM-Signature. Получатель берёт из этого заголовка имя селектора, запрашивает по нему открытый ключ в вашем DNS и проверяет подпись. Совпало, значит письмо отправлено с вашего домена и не изменилось в пути.

Отсюда простое следствие: закрытый ключ нужен ровно одной стороне, тому, кто отправляет письма. Всё остальное публично.

Что делать с полученными значениями

1. Открытый ключ опубликуйте TXT-записью на имя селектор._domainkey.
2. Закрытый ключ сохраните на почтовом сервере и укажите путь к нему в настройках подписи.
3. Отправьте тестовое письмо и посмотрите его заголовки: в Authentication-Results должно появиться dkim=pass.

Частая проблема при публикации

Ключ на 2048 бит не помещается в одну строку TXT: DNS ограничивает строку 255 символами. Панели обычно разбивают значение сами, но некоторые требуют сделать это вручную, и тогда запись оформляется как несколько строк в кавычках подряд, без разделителей. Если после публикации проверка ключа говорит, что он не читается, почти наверняка значение разорвано переносом строки или потеряло часть символов при копировании.

Что означают теги записи

• v=DKIM1 — версия. Если тег присутствует, он обязан быть первым.
• k=rsa — тип ключа. Значение по умолчанию, поэтому его часто опускают. Альтернатива это k=ed25519: ключ короче и быстрее, но поддержан не всеми принимающими серверами, поэтому его публикуют вторым селектором рядом с RSA, а не вместо него.
• p= — сам открытый ключ в base64. Пустое значение p= означает отозванный ключ: запись остаётся, подписи ей больше не проверяются.
• t=y — тестовый режим. Получатель проверяет подпись, но не учитывает результат. Полезен первые дни, вредит, если о нём забыли: домен выглядит подписанным, а защиты нет.
• h=sha256 — допустимый алгоритм хеширования. Указывать не обязательно; sha1 в 2026 году не используется.

Длина ключа

1024 бита это исторический минимум, который до сих пор встречается у старых рассылочных сервисов. Такой ключ считается слабым: его подделывают вычислительно, и Gmail с 2023 года помечает подписи на 1024 битах как ненадёжные. Рабочий выбор это 2048.

4096 бит выглядит логичным продолжением, но на практике создаёт больше проблем, чем решает: значение перестаёт помещаться в ограничения части DNS-панелей и старых резолверов, а выигрыш в стойкости для подписи письма несущественный. Если провайдер не требует иного, остаётся 2048.

Про селекторы

Селектор — это произвольное имя перед ._domainkey, и он существует ровно для того, чтобы ключей могло быть несколько. Каждый сервис отправки подписывает своим: mail у одного, s1 у другого, google у Workspace. Они не конфликтуют: получатель берёт из заголовка письма имя селектора и идёт за ключом именно по нему.

Отсюда практическое следствие: подключая новый сервис рассылок, не нужно ничего переносить и заменять. Добавляется отдельный селектор, старый продолжает работать. Осмысленные имена вроде crm2026 или esp-main экономят время через год, когда придётся вспоминать, чей это ключ.

Приватный ключ

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

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

Как убедиться, что подпись работает

Публикация записи — это половина дела: ключ лежит в DNS, но письма подписываются только после того, как приватная часть прописана в отправляющем сервисе. Проверить можно одним письмом на собственный ящик: в исходнике должен появиться заголовок DKIM-Signature, а в Authentication-Results — dkim=pass.

Если стоит dkim=fail, а ключ читается, причина почти всегда в одном из трёх: значение в DNS не совпадает с тем, что выдал сервис (потерялись символы при копировании), письмо изменяется в пути антивирусом или списочным сервером, либо подпись покрывает заголовок, который потом переписывается, например Subject с добавленной меткой «[Внешнее]».