DKIM: селекторы, ротация ключей и миграции без потери доставляемости

DKIM (DomainKeys Identified Mail) — один из базовых механизмов аутентификации исходящей почты. Он не «шифрует письмо», а добавляет криптографическую подпись части заголовков и тела. Получатель проверяет подпись по публичному ключу из DNS и использует результат в антиспаме, антифишинге и при построении репутации домена.

На практике DKIM чаще ломают не криптографией, а организацией: неподходящий dkim selector, невнятные TTL, обрезанные DNS TXT-записи, отсутствие ротации ключей, хаотичная миграция между серверами и конфликты нескольких подписывающих компонентов (например, MTA + Rspamd).

Ниже — «боевая» инструкция, как выстроить DKIM так, чтобы он переживал обслуживание, миграции, смену MTA/антиспама и регулярную ротацию ключей без просадок доставляемости.

Как устроен DKIM: selector, ключ и DNS TXT

У DKIM есть три ключевые сущности:

• Селектор — имя, по которому получатель находит публичный ключ. Это и есть dkim selector. В DNS он становится частью поддомена вида <selector>._domainkey.example.com.

• Публичный ключ — публикуется в DNS как TXT (в некоторых DNS-панелях значение визуально «разбивается» на строки, но логически остаётся одной TXT-записью).

• Приватный ключ — хранится на сервере и используется подписывающим компонентом (OpenDKIM, Rspamd, milter и т.д.).

Когда письмо отправляется, в него добавляется заголовок DKIM-Signature:. В нём есть параметры: домен подписи (d=), селектор (s=), алгоритм (a=), список подписанных заголовков (h=) и собственно подпись (b=).

DKIM проверяет целостность. Если письмо изменили после подписи (баннеры, дисклеймеры, «умные» транспорты, перекодирование), подпись может сломаться даже при идеальном DNS.

Как выглядит DNS TXT запись DKIM

Типичная запись выглядит так (пример, не копируйте как есть):

mail2025._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."

Главная ловушка — случайно создать две TXT-записи для одного и того же имени selector._domainkey. Часть проверяющих систем/получателей это переживёт, но встречаются неоднозначные интерпретации, из-за которых диагностика превращается в лотерею.

Выбор DKIM selector: как назвать и как жить с несколькими

Селектор — это не «любое слово». Он участвует в жизненном цикле ключей, миграциях, параллельных отправителях и инцидент-реакции.

Практичные схемы именования:

• По дате/версии: dk2025q1, k2025-12 — удобно для плановой ротации и аудита.

• По системе-отправителю: postfix, crm, newsletter — удобно, если письма уходят из разных систем и нужны разные ключи.

• Комбинированно: mx1-2025, crm-2025q4 — хорошо, когда есть несколько серверов и несколько потоков исходящей почты.

multiple selectors означает, что у домена одновременно может быть несколько активных селекторов с разными ключами. Это нормально и, как правило, правильно: вы заранее публикуете новый селектор, а старый держите до тех пор, пока «хвост» ретраев доставки и очередей гарантированно не закончится.

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

В типовом сценарии достаточно двух:

• Текущий (используется для подписи сейчас).

• Предыдущий (оставлен на период перехода и ретраев доставки).

Три и более появляются, если у вас несколько источников отправки (основной MTA, отдельный сервер рассылок, внешняя CRM/SaaS, и т.д.).

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

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

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

DKIM key rotation: как ротировать ключи без провалов

dkim key rotation — плановая смена ключей подписи. Цель: снизить риски компрометации ключа и упростить реагирование на инциденты, не ломая при этом доставляемость.

Главная ошибка — «перезаписать TXT на месте». Если вы меняете публичный ключ для того же селектора, письма, подписанные старым приватным ключом (которые ещё могут доставляться с задержкой или ретраями), начнут проваливать проверку DKIM.

Рабочий шаблон ротации:

1. Сгенерировать новый ключ с новым селектором.

2. Опубликовать новый DNS TXT для newselector._domainkey.

3. Подождать распространения DNS (ориентируйтесь на TTL и реальную скорость обновления у резолверов).

4. Переключить подписывающий сервис на новый селектор.

5. Держать старый селектор в DNS ещё 1–2 недели (или дольше, если у вас длинные очереди, ретраи или партнёры с задержками).

6. Удалить старый селектор из DNS только после того, как убедились, что он нигде не используется.

TTL и ротация: практический подход

Для DKIM разумный TTL — 3600–14400 секунд. Слишком большой TTL усложняет быстрые изменения при инцидентах. Слишком маленький повышает нагрузку на DNS и иногда приводит к нестабильным результатам из-за агрессивного кеширования/ошибок на стороне отдельных резолверов.

Если планируете ротацию или миграцию, можно временно снизить TTL за 24–48 часов до переключения, а после стабилизации вернуть обратно.

OpenDKIM: базовая настройка и точки, где чаще всего ошибаются

opendkim обычно используют как milter для Postfix/Sendmail. Задачи простые: хранение ключей, привязка доменов/селекторов, подпись исходящих писем.

Типовая структура (упрощённо):

• Каталог с ключами, например /etc/opendkim/keys/example.com/.

• Файл KeyTable: какой селектор и какой ключ использовать.

• Файл SigningTable: какие отправители/домены подписывать каким ключом.

Пример (как текст, адаптируйте под себя):

# /etc/opendkim/KeyTable
mail2025._domainkey.example.com example.com:mail2025:/etc/opendkim/keys/example.com/mail2025.private

# /etc/opendkim/SigningTable
*@example.com mail2025._domainkey.example.com

# /etc/opendkim/TrustedHosts
127.0.0.1
::1
192.0.2.10

Смысл: SigningTable говорит «все отправители @example.com подписываем селектором mail2025», KeyTable показывает путь к приватному ключу.

Частые ошибки в OpenDKIM

• Подписывают не тот домен: в письме From: один, envelope-from другой, а правила подписи настроены неожиданно. Итог — проблемы с DMARC alignment и доставляемостью.

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

• Подпись «не там» в пайплайне: письмо подписали, а потом другой фильтр изменил тело/заголовки — DKIM развалился у получателя.

Rspamd DKIM: когда антиспам ещё и подписывает

rspamd dkim — популярный вариант, когда DKIM подпись делает сам Rspamd. Это удобно: одна система проверяет входящую почту и подписывает исходящую; в некоторых сценариях также помогает с пересылками через ARC.

Ключевой момент: не допускайте ситуации, когда одно письмо подписывается дважды разными системами «встык» без ясной цели. Две подписи DKIM в одном письме допустимы, но у вас должна быть причина (например, подпись домена и подпись outbound-шлюза). Иначе вы усложняете отладку и повышаете риск рассинхрона при ротации.

Если вы используете пересылки и хотите лучше понимать, как DKIM/ARC ведут себя в таких цепочках, пригодится заметка про ARC и форвардинг: ARC в связке Postfix и Rspamd для пересылок.

Что проверить, если подпись Rspamd пропала

• Письмо уходит в обход Rspamd (не через настроенный прокси/хуки MTA).

• Ключ не найден по домену/селектору (ошибка пути, домен не совпадает, нет mapping).

• Есть политика «не подписывать» для отдельных отправителей/сетей.

• Проблемы с правами на приватный ключ.

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

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Миграция почты и DKIM: сценарии без потери доставляемости

Миграция чаще всего выглядит так: вы переносите MTA/антиспам на новый сервер, меняете IP, иногда меняете стек (OpenDKIM → Rspamd или наоборот), и параллельно живут очереди отправки и ретраи.

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

Сценарий 1: переезд сервера, DKIM ключи сохраняем

Самый простой и надёжный сценарий: вы переносите приватный ключ на новый сервер и продолжаете подписывать тем же селектором. Тогда DNS менять не нужно, а риск провала DKIM минимальный.

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

Сценарий 2: переезд + смена DKIM ключей (параллельные селекторы)

Если вы не хотите переносить старый приватный ключ (политика безопасности или подозрение на компрометацию), действуйте через multiple selectors:

1. Оставьте старый селектор и его DNS TXT запись.

2. Создайте новый селектор и опубликуйте его DNS TXT.

3. На старом сервере продолжайте подписывать старым селектором до выключения.

4. На новом сервере подписывайте новым селектором.

5. Держите оба селектора в DNS, пока не закончится «хвост» ретраев и пока не убедитесь, что старый селектор нигде не используется.

Сценарий 3: несколько источников отправки (CRM + сайт + рассылки)

Если часть писем отправляет ваш сервер, часть — внешняя система, чтобы не было конфликтов:

• Выделите отдельный dkim selector на каждый источник (или хотя бы на каждый класс источников).

• Ведите простую таблицу: источник → селектор → где хранится ключ → дата последней ротации.

• При ротации не трогайте чужие селекторы и не «чистите DNS», пока не понимаете последствия.

Проверка и диагностика: что смотреть, когда «всё настроено», но DKIM fail

Симптоматика часто одинаковая: в заголовках письма у получателя dkim=fail, а в DNS «вроде бы есть TXT».

1) Проверьте, что селектор реально совпадает

Откройте исходники письма и найдите DKIM-Signature. Посмотрите s= и d=. Запрос в DNS должен идти именно в:

<s>._domainkey.<d>

Ошибка на один символ, другой домен, лишняя точка в имени — и проверка не пройдёт.

2) Проверьте, что в DNS одна корректная TXT-запись

Для имени вида selector._domainkey лучше иметь одну TXT-запись, содержащую v=DKIM1 и p=.... Если панель разбила значение на несколько строк — это нормально, пока это одна запись, а не два отдельных TXT-ресурса.

3) Проверьте, не модифицируется ли письмо после подписи

Классическая причина: система добавляет или меняет тело письма после DKIM. Например, транспорт дописывает дисклеймер, меняет переносы строк, перекодирует части тела, вставляет трекеры.

Вывод: подпись должна происходить после всех преобразований, либо преобразования должны быть совместимы с выбранной canonicalization (это уже детали DKIM, но суть именно в порядке фильтров).

4) Проверьте «двойную подпись» и порядок фильтров

Если у вас и OpenDKIM, и DKIM signing в Rspamd включены одновременно, определите единственный источник подписи (или осознанно держите две подписи и понимаете зачем). Иначе получите ситуацию, когда один компонент подписал, второй что-то изменил, и подпись стала невалидной.

Практика эксплуатации: регламент, чтобы DKIM не превращался в лотерею

Чтобы DKIM работал годами, а не «до первой миграции», помогает простой регламент:

• Инвентаризация: список доменов, селекторов, мест хранения ключей, кто подписывает (OpenDKIM/Rspamd/внешний сервис).

• Ротация: план раз в 6–12 месяцев (или по политике). Всегда через новый селектор, а не заменой ключа в существующем.

• Мониторинг: периодически отправляйте тестовые письма на ящики разных провайдеров и проверяйте результаты DKIM/SPF/DMARC в заголовках. Это позволяет ловить деградации доставляемости до того, как пользователи начнут жаловаться.

• Контроль DNS изменений: любые правки DNS TXT проводите через проверку (хотя бы «вторыми глазами»), потому что DKIM часто ломается из-за лишней кавычки, пробела или дубля записи.

Если вам нужен более «пошаговый» разбор ротации, TTL и тактики нескольких селекторов, дополнительно см. материал: ротация DKIM: селекторы и TTL без провалов.

Частые вопросы про селекторы, ротацию и миграции

Можно ли использовать один селектор годами?

Технически да. Практически — нежелательно: без ротации вы увеличиваете риски. А при инциденте придётся менять ключ «на месте», что ломает проверку у писем в очередях.

Можно ли удалить старый селектор сразу после переключения?

Не стоит. Письма могут доставляться с задержкой и ретраями, плюс некоторые системы отправляют повторно при временных ошибках. Оставляйте старый селектор в DNS минимум на время, превышающее ваш худший сценарий ретраев (часто 7–14 дней).

Нужно ли менять DKIM при смене DNS-провайдера?

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

Как DKIM влияет на доставляемость в связке с DMARC?

DKIM сам по себе — сигнал доверия, но максимальный эффект обычно даёт связка SPF + DKIM + DMARC с корректным alignment. DKIM особенно полезен там, где SPF может ломаться (пересылки, сложные маршруты), а подпись остаётся проверяемой.

Итог: рабочая схема DKIM для живой инфраструктуры

• Выбирайте понятные имена dkim selector (по времени или по источнику отправки).

• Публикуйте ключи как одну корректную DNS TXT-запись на selector._domainkey.

• Ротацию делайте только через новый селектор и держите multiple selectors в переходный период.

• При миграциях заранее готовьте DNS и не допускайте двойной подписи разными системами без необходимости.

• Проверяйте реальные заголовки писем и логи подписи — именно там видно, что происходит на самом деле.

Так DKIM перестаёт быть «магией почтовиков» и становится обычным управляемым механизмом, который переживает обновления, переезды и рост инфраструктуры.