Ротация DKIM-ключей 2048/4096 без простоя: несколько селекторов и TTL

Ротация DKIM — это не про «сломал — починил», а про плановую замену ключей без потери доставляемости. Ключи устаревают, компрометируются, меняются криптополитики, и рано или поздно приходится переходить на 2048 или 4096 бит. Хорошая новость: DKIM изначально спроектирован для безопасной ротации за счёт селекторов. Если грамотно распланировать TTL и задействовать несколько селекторов, всё пройдёт без простоя и без «dkim=fail» в заголовках у получателей.

Что такое селектор DKIM и зачем он нужен при ротации

DKIM-подпись в письме содержит домен (d=) и селектор (s=). Селектор — это «имя ключа», по которому получатель находит публичный ключ в DNS: <selector>._domainkey.<domain>. Главное следствие: вы можете держать в DNS столько селекторов, сколько нужно, и менять активный ключ просто переключением селектора на стороне MTA.

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

Если вы впервые собираете инфраструктуру для SPF/DKIM/DMARC, пригодится разбор в статье Записи DNS для SPF, DKIM, DMARC.

План ротации без простоя

1. Инвентаризация: выяснить текущий селектор, где и как он объявлен в DNS, какой TTL у записи.
2. Снижение TTL заранее: уменьшить TTL записи селектора и/или всей зоны за 24–48 часов до переключения.
3. Сгенерировать новый ключ (2048/4096), выбрать новый селектор.
4. Опубликовать новый публичный ключ в DNS как TXT для нового селектора, дождаться распространения.
5. Включить двойную подпись или переключить MTA на новый селектор (в зависимости от возможностей вашей связки).
6. Мониторинг: убедиться, что у получателей dkim=pass по новому селектору.
7. Подождать безопасный интервал, вернуть нормальный TTL, затем удалить старый селектор.

1) Инвентаризация

Проверьте заголовки реального исходящего письма. В DKIM-Signature найдёте поле s=old (пример) — это и есть селектор. Убедитесь, что публичный ключ доступен в DNS и запоминайте TTL.

# Проверка DNS ключа
# селектор old, домен example.com
# ожидается TXT с v=DKIM1; p=...
dig +short TXT old._domainkey.example.com

Если селектор нигде не найден, проверьте панель DNS и конфиг подписи у MTA/antispam (milter, фильтр). На этом же шаге оцените, нет ли дополнительных политик DKIM (запись _domainkey.example.com с флагами t=) и какой у них TTL. Если домен и зона управляются у нас, работать с записями удобно через регистрацию доменов.

2) Снизить TTL заранее

TTL — ваш рычаг управления риском. Уменьшите TTL с привычных 3600–14400 до 60–300 секунд за 24–48 часов до переключения. Это снизит инерцию кэшей резолверов и ускорит откат, если что-то пойдёт не так. Не забывайте про негативное кеширование NXDOMAIN: у резолверов оно определяется по SOA и может жить дольше, чем вы ожидаете. Поэтому лучше не удалять записи в горячей фазе, а только добавлять новые и переключать подпись. Если вы планируете переносить домен или DNS к другому провайдеру, учитывайте TTL и окна изменений — подробнее см. перенос домена по EPP и DNS.

3) Сгенерировать новый ключ 2048/4096

Минимум сегодня — 2048 бит. 4096 — ещё лучше с точки зрения криптостойкости, но предъявляет требования к DNS (см. ниже). Сгенерировать можно привычными инструментами.

# OpenSSL 2048
openssl genrsa -out dkim_2025_private.key 2048
openssl rsa -in dkim_2025_private.key -pubout -out dkim_2025_public.pem

# OpenSSL 4096
openssl genrsa -out dkim_2025_private.key 4096
openssl rsa -in dkim_2025_private.key -pubout -out dkim_2025_public.pem

# OpenDKIM (создаёт пару и готовую DNS-запись)
opendkim-genkey -r -s s2025 -d example.com -b 2048
# появятся s2025.private и s2025.txt

# Rspamd (удобно для Lua-конфига и мульти-сигнинга)
rspamadm dkim_keygen -b 4096 -s s2025 -d example.com -k /etc/dkim/keys/example.com/s2025.key

Из публичного ключа извлеките значение p= (без заголовков PEM). Проверяйте, чтобы не попали переносы и посторонние символы.

4) Опубликовать новый селектор в DNS

Создайте TXT на имени s2025._domainkey.example.com. Содержимое:

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...длинный_base64...IDAQAB

Для 4096-битных ключей база64 может быть длинной. В зонах вида BIND длинную строку разбивают на несколько кавычечных фрагментов — DNS их склеит автоматически:

s2025._domainkey 300 IN TXT "v=DKIM1; k=rsa; p=MIICIjANBgkqh..."
                  "...продолжение_ключа..."
                  "...окончание_ключаIDAQAB"

Некоторые панели DNS не поддерживают многострочные TXT или ограничивают длину одного фрагмента. Тогда используйте 2048 бит или панель, которая корректно собирает длинные TXT. После публикации дождитесь, пока dig возвращает новую запись по всем точкам.

5) Двойная подпись или переключение

Лучший сценарий — временно подписывать каждой из двух пар ключей (старой и новой). Тогда у получателя всегда будет dkim=pass хотя бы по одному селектору. Это поддерживается не во всех связках, но если у вас фильтр/мта умеет мульти-сигнинг, включайте. Если шлёте почту со своего сервера — держать MTA на VDS удобнее: полный контроль над OpenDKIM/Rspamd и быстрый откат.

Примеры подходов:

• Мульти-сигнинг: добавить второй профиль с селектором s2025, оставить старый old. Новые письма будут иметь две подписи DKIM-Signature.
• Переключение без двойной подписи: перевести подпись на s2025, при этом не удалять DNS для old. Старые письма, уже ушедшие со старой подписью, продолжат верифицироваться за счёт старого DNS.

В обоих случаях ключевой принцип: не трогайте старую TXT-запись до окончания «времени жизни» старых писем.

6) Мониторинг

После переключения проверяйте заголовки тестовых писем: поле Authentication-Results у получателя должно содержать dkim=pass и ваш новый селектор. В логах фильтра/мильтора отслеживайте число успешных подписей и верификаций. Для DNS — регулярные проверки через dig из разных сетей.

# Проверка новой записи
dig +trace +short TXT s2025._domainkey.example.com

# Проверка соответствия ключей (если инструмент доступен)
opendkim-testkey -d example.com -s s2025 -k /etc/dkim/keys/example.com/s2025.key -vvv

Регистрация доменов от 99 руб.

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

Зарегистрировать домен

7) Возврат TTL и удаление старого селектора

Через 7–14 дней (или согласно вашей политике хранения и ожидания отложенных доставок/форвардинга) можно:

• Отключить подпись старым селектором (если было два).
• Вернуть TTL записи селектора к нормальному значению (например, 3600–14400).
• Оставить старый TXT ещё на 1–2 недели «про запас» и затем удалить.

Если у вас высокие объёмы рассылки или длинные SLA по ретраям, разумно держать старый ключ в DNS до 30 дней.

Тонкости 4096-битных ключей

4096-битные ключи заметно длиннее в базе64. Это влечёт три практических момента:

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

Безопасность и операционные практики

Периодичность ротации

Рекомендуемая периодичность — 6–12 месяцев. Включите напоминания и автоматизируйте генерацию/публикацию.

Хранение приватного ключа

• Разрешения только для пользователя MTA/фильтра (например, 0600).
• Хранение вне резервных копий, доступных широкому кругу, или в зашифрованном виде.
• Журналы доступа и контроль целостности.

Политики домена

Если используете доменную политику DKIM (запись _domainkey.example.com), убедитесь, что флаги (например, тестовый t=y) соответствуют реальному состоянию. Ротация ключей обычно не требует менять политику, но не лишне свериться. Для повышения общей защищённости домена посмотрите также материал Защита бренда домена.

Проверочный чек-лист перед переключением

• Новый ключ сгенерирован, приватная часть на проде, права ограничены.
• Новый селектор опубликован в DNS, запись проверена из нескольких сетей.
• TTL снижён до 60–300 секунд заранее.
• Конфигурация MTA/фильтра протестирована на стенде.
• Настроены оповещения по метрикам dkim=fail и ошибкам подписи.
• Подготовлен план отката (вернуться к старому селектору мгновенно).

Типичные ошибки и как их избежать

• Перетирают существующий селектор: старые письма перестают верифицироваться. Решение: всегда новый селектор, старый оставить в DNS на период выгорания.
• Неправильная склейка TXT: лишние пробелы, переносы, пропавшие кавычки. Решение: проверка через dig, валидация средствами milter/фильтра.
• Слишком рано удаляют старый ключ: форварды и отложенные доставки дают dkim=fail. Решение: выдержать буфер 2–4 недели.
• Забывают снизить TTL: откат болезненнее. Решение: готовить зону заранее.
• Несоответствие домена d= и публикуемого DNS: подписывают поддоменом, а ключ публикуют на корне или наоборот. Решение: проверяйте, что s=sel + d=example.com соответствует sel._domainkey.example.com.

Пример конфигурации: два селектора пошагово

Имеем селектор old (2048), хотим перейти на s2025 (4096):

1. За 48 часов уменьшаем TTL у old._domainkey.example.com до 300.
2. Генерируем s2025, публикуем TXT, TTL 300.
3. Ждём распространения, проверяем dig.
4. Включаем двойную подпись (old и s2025) или переключаемся на s2025.
5. Наблюдаем метрики 7–14 дней, исправляем замечания.
6. Отключаем old в конфиге подписи.
7. Поднимаем TTL у s2025 до 3600–14400, держим old в DNS ещё 1–2 недели, затем удаляем.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Тесты end-to-end

• Отправить тест на внешние ящики и проверить заголовки. Ищем Authentication-Results с dkim=pass и s=s2025.
• Имитировать форвард: переслать письмо через внешний сервис/аккаунт и убедиться, что подпись переживает трансформации (желательно relaxed/relaxed).
• Проверить, что старые письма со s=old продолжают верифицироваться до удаления старого TXT.

Откат за 5 минут

Если после переключения растут dkim=fail у получателей:

• Моментально вернуть подпись на старый селектор (конфиг milter/фильтра).
• Не трогать DNS: новый селектор пусть остаётся — низкий TTL минимизирует последствия.
• Разобраться с причиной: неверный p=, обрезка TXT, несовместимость 4096 у вашего DNS-провайдера, каноникализация, переподпись посредником и т.д.

FAQ по ротации

Сколько селекторов можно держать одновременно?

Сколько угодно. Практически — 2–3 достаточно: действующий, новый (на время ротации) и иногда тестовый.

Нужно ли менять селектор при каждой ротации?

Да. Новый ключ — новый селектор. Это позволяет не ломать верификацию старых писем.

Зачем снижать TTL, если мы только добавляем записи?

Для ускоренного исправления ошибок. Если что-то опубликовали неверно, низкий TTL позволит быстрее распространить правки. Также полезно при откате.

Как долго держать старый ключ в DNS?

Базовая рекомендация — 2–4 недели. Если у вас длинные очереди ретраев или сложные маршруты с форвардингом, держите до 30 дней.

Выводы

Ротация DKIM-ключей без простоя — это дисциплина и планирование: несколько селекторов, аккуратный TTL, тесты и мониторинг. Переход на 2048/4096 при соблюдении этих правил проходит гладко: новые письма сразу верифицируются по новому ключу, а старые — по старому. Не экономьте на подготовке и проверках — и у команд доставки не будет поводов вспоминать про «сломанный SMTP».