DKIM ставит на каждое исходящее письмо цифровую подпись: почтовый сервер подписывает сообщение закрытым ключом, а получатель проверяет подпись по открытому ключу из DNS. Если подпись верна, значит письмо не изменили по дороге и оно действительно ушло с сервера, которому домен доверяет. Многие компании настраивают DKIM один раз и годами живут с тем же ключом. Со временем меняются администраторы, сервер переезжает, ключ успевает побывать в чужих руках или резервных копиях. Поэтому плановая смена ключа, то есть ротация, считается правильной практикой.
Что такое селектор и почему ротация строится на нём
У одного домена одновременно может быть несколько ключей DKIM, а различают их по селектору. Открытый ключ хранится в TXT-записи с именем селектор._domainkey.домен, а в заголовке DKIM-Signature тег s= указывает, какой селектор использован. Сервер получателя по этому селектору запрашивает нужный ключ из DNS.
DKIM-Signature: v=1; a=rsa-sha256; d=example.uz; s=mail2025; c=relaxed/relaxed; ...В этом и состоит идея ротации: старый ключ не заменяется «на месте», а новый публикуется отдельно под новым селектором. Какое-то время оба ключа живут в DNS, а сервер переключается на подпись новым. Благодаря этому ни одно письмо не получает ошибку проверки подписи.
Когда менять ключ
Жёсткого обязательного срока нет, но многие рекомендации по безопасности почты советуют менять ключ хотя бы раз в год, а активным отправителям — чаще. Внеплановая смена обязательна в следующих случаях:
- есть подозрение на взлом сервера или утечку закрытого ключа;
- завершилось сотрудничество с администратором или подрядчиком, у которого был доступ к ключу;
- почта переезжает на другой сервер или в другой сервис;
- нужно перейти со старого 1024-битного ключа на 2048-битный.
Последний пункт особенно важен. 1024-битный RSA-ключ сегодня считается слабым, поэтому новый ключ рекомендуется создавать длиной 2048 бит. Бывают и 4096-битные ключи, но они получаются очень длинными для DNS и с некоторыми системами вызывают проблемы.
Создание новой пары ключей
Если почтовый сервер ваш, ключ можно сгенерировать через OpenSSL. В имя селектора удобно включать дату, чтобы сразу было видно, когда ключ создан:
openssl genrsa -out mail2026.private 2048
openssl rsa -in mail2026.private -pubout -outform der | openssl base64 -A > mail2026.pubНа серверах с OpenDKIM команда opendkim-genkey создаёт и ключ, и готовую DNS-запись одновременно:
opendkim-genkey -b 2048 -d example.uz -s mail2026
# результат: mail2026.private и mail2026.txtФайл закрытого ключа должен быть доступен только почтовой службе, например через chmod 600. Никогда не пересылайте его по почте и не кладите в открытый репозиторий. На хостинге с панелью управления эту работу обычно выполняет сама панель: там есть возможность перевыпустить DKIM для домена.
Этапы ротации
Правильная ротация состоит из четырёх шагов, и между ними должно проходить время. Спешка почти всегда приводит к ошибкам подписи.
- Публикация нового открытого ключа. Добавьте TXT-запись
mail2026._domainkeyи дождитесь распространения DNS. Старую запись пока не трогайте. - Проверка. Убедитесь через
dig, что новая запись видна на всех серверах имён. - Переключение подписи. Укажите в настройках почтового сервера новый селектор и путь к новому закрытому ключу, перезагрузите службу.
- Отзыв старого ключа. Через несколько дней оставьте старый селектор с пустым ключом или удалите его.
mail2026._domainkey.example.uz. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
dig +short TXT mail2026._domainkey.example.uzСтарый ключ не удаляют сразу по простой причине: письма в очередях и задержанные доставки всё ещё несут старую подпись, а некоторые системы перепроверяют подпись уже после получения. Пустое значение p= по стандарту означает, что ключ отозван:
mail2025._domainkey.example.uz. IN TXT "v=DKIM1; p="2048-битный ключ и длина TXT-записи
Открытый 2048-битный ключ занимает около 400 символов, а одна строка TXT не может быть длиннее 255 символов. Поэтому длинный ключ делится на несколько строк в кавычках, которые DNS-сервер склеивает при ответе. Большинство DNS-панелей делают это автоматически, но при ручной правке файла зоны следите, чтобы внутри ключа не появилось лишних пробелов или переносов. Случайный пробел или потерянный символ полностью ломает подпись, и найти такую ошибку на глаз сложно.
mail2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5..."
"...QIDAQAB" )Пример: частная клиника в Самарканде
Частная клиника в Самарканде отправляет пациентам результаты анализов и напоминания о приёме по электронной почте. Почту когда-то настраивал внешний подрядчик, и ключ DKIM был 1024-битным. После окончания договора новый администратор получает задачу сменить ключ. Он создаёт 2048-битный ключ с селектором clinic2026, публикует его в DNS и ждёт сутки. Затем переключает подпись на новый селектор, отправляет тестовое письмо в свой ящик Gmail и в режиме «Показать оригинал» видит успешный результат DKIM и s=clinic2026. Через неделю старый селектор отзывается.
Проверка после смены
После ротации посмотрите в заголовках письма строку Authentication-Results: там должны быть dkim=pass и имя нового селектора. Если включены отчёты DMARC, в ближайшие дни убедитесь, что провалов DKIM не стало больше. Рост провалов обычно означает, что какая-то система, например форма сайта на отдельном сервере, всё ещё подписывает старым ключом или не подписывает вовсе.
На хостинге sayt.uz запись DKIM для корпоративной почты видна в разделе DNS личного кабинета, поэтому после добавления нового селектора её публикацию можно сверить там и командой dig.