Как я меняю DKIM-селектор, не останавливая почту

Сменить DKIM-ключ можно без остановки SMTP: я публикую новый публичный ключ под отдельным селектором, переключаю на него подпись и сохраняю старую DNS-запись, пока завершаются проверки и уходят сообщения из очередей. Ниже — порядок ротации, критерии проверки и разбор условного сценария.

Что на самом деле может сломаться при смене DKIM

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

Риск ротации не в том, что почтовый сервер внезапно перестанет принимать SMTP-соединения. Если в DNS исчезнет публичный ключ, сервер обычно продолжит отправлять сообщения, но адресат может не проверить письма, подписанные этим селектором. Дальше решение зависит от принимающей стороны и настроек DMARC: сообщение могут доставить, пометить или отклонить. Поэтому обещание «удалим запись — почта точно встанет» неверно, как и обратное обещание, будто последствия будут только косметическими.

Опасный сценарий — оставить прежний селектор, но заменить содержимое его TXT-записи новым ключом, пока отправитель уже использует новую пару. Резолверы могут некоторое время отвечать сохраненным значением, а разные письма потребуют разные публичные ключи. RFC 6376 предусматривает селекторы именно для нескольких одновременно действующих ключей: новый селектор дает новой подписи отдельный адрес в DNS. Тут не нужно угадывать, какой ключ адресат закэшировал.

Отдельно разбираю компрометацию. Если закрытый ключ действительно утек, им перестают подписывать сразу после подготовки безопасной замены; старую публичную запись удаляют по плану отзыва, понимая, что проверка уже отправленных сообщений может измениться. При обычной плановой смене старый селектор оставляют доступным на период перекрытия. Это разные ситуации, и сводить их к универсальному правилу «всегда ждите сутки» нельзя.

• DKIM проверяет подпись выбранных частей письма.
• Новый селектор позволяет держать два ключа параллельно.
• Удаление TXT-записи влияет на проверку, а не само по себе на SMTP.
• DKIM pass не гарантирует попадание во входящие.

Как я провожу ротацию по шагам

Начинаю с инвентаризации всех отправителей домена: почтового сервера, сайта, CRM и сервисов рассылки, если они есть. От каждого источника отправляю контрольное письмо и фиксирую значения d= и s= из DKIM-Signature. Один домен может одновременно подписываться несколькими системами и селекторами; если забыть хотя бы одну, новая запись не заменит старую подпись. На этом этапе я также проверяю текущую TXT-запись и TTL у авторитетных DNS-серверов.

Затем создаю новую пару ключей и выбираю новый селектор, который не использовался раньше для этого домена. Для RSA стандарт рекомендует ключ не короче 2048 бит; это рекомендация RFC 8301, а не универсальное обещание совместимости с любой старой панелью. Закрытая часть остается только на сервере подписи и доступна учетной записи службы с нужными правами. В DNS публикуется открытая часть, обычно в TXT-записи вида новый-селектор._domainkey.example.com.

До переключения проверяю, что новая TXT-запись видна у авторитетных серверов DNS и что имя записи совпадает с будущим селектором посимвольно. Если DNS размещен у внешнего провайдера, запись нужно создать именно там: локальная панель почтового сервера не меняет чужую зону. Текущую запись не трогаю. Для проверки всей цепочки использую и проверку DKIM после смены ключа, но результат онлайн-сервиса не заменяет проверку тестового письма.

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

Старый публичный ключ оставляю в DNS, пока отправители больше не используют прежний селектор и не завершился согласованный период перекрытия. Его длительность зависит от TTL, отрицательного кэширования DNS, времени жизни сообщений в очередях и принятого у компании окна наблюдения. Я не назначаю всем «24–48 часов»: это число не учитывает ни настройки DNS, ни задержанные сообщения. Перед удалением старой записи еще раз проверяю заголовки писем со всех маршрутов.

• Снять текущие селекторы со всех отправителей.
• Опубликовать TXT-запись для нового селектора.
• Проверить DNS и переключить подпись.
• Оставить старую запись на период перекрытия.
• Удалить старый ключ после контрольной проверки.

Условный сценарий: студия «Кварта-Плюс»

Разберу условную студию «Кварта-Плюс» — это пример для объяснения процесса, а не отчет о подтвержденном инциденте. У нее есть основная почтовая система и сайт, который тоже отправляет уведомления. Руководитель просит сменить старый DKIM-ключ без остановки деловой переписки. Я не обещаю срок «за пятнадцать минут» и не приписываю сценарию процент доставки: сначала надо выяснить реальное состояние отправителей и DNS.

В начале я отправляю письмо из почтового клиента и отдельное уведомление с сайта. В заголовках сравниваю d= и s=; так становится ясно, использует ли сайт тот же селектор или отдельный. Затем проверяю TXT-записи для каждого найденного селектора. Если две системы подписывают разными ключами, ротацию планирую для каждой отдельно, иначе после переключения основного сервера часть уведомлений продолжит выходить со старой подписью.

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

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

Что учитывать в панели и OpenDKIM

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

В OpenDKIM закрытый ключ хранится на сервере, а выбор ключа для подписи связывается с доменом и селектором через активную конфигурацию. Нельзя просто положить новый файл рядом и ждать, что служба сама начнет его использовать: нужно обновить соответствие в той схеме, которая уже настроена на этом сервере. Перед изменением сохраняю копию конфигурации и проверяю права на закрытый ключ, чтобы он не стал доступен обычным пользователям.

Утилита проекта OpenDKIM позволяет проверить, что ключ из DNS соответствует локальному закрытому ключу. Пример для домена example.com и селектора s2026: opendkim-testkey -d example.com -s s2026 -k /path/to/s2026.private. Путь здесь условный: подставьте фактический файл и не копируйте команду вслепую в чужую схему. Проверка записи не доказывает, что почтовый сервер уже подписывает письма новым селектором; это подтверждается только заголовком отправленного сообщения.

После правки конфигурации я применяю изменение по документации конкретного дистрибутива и сервиса. Иногда достаточно перечитать настройки подписывающей службы, иногда требуется ее перезапуск; перезапускать весь почтовый сервер «на всякий случай» я не советую. Кнопка в панели не читает мысли администратора. Сначала подтверждаю, что конфигурация загружена, затем отдельно проверяю отправку, заголовок письма и DNS-ответ.

Как проверить DKIM и понять результат

Тестирую письма, отправленные после переключения, и читаю исходные заголовки. В DKIM-Signature сверяю домен d= и новый селектор s=; в Authentication-Results смотрю, что именно написал принимающий сервер. Результат dkim=pass означает, что эта подпись прошла проверку у данного получателя. Он не говорит, что письмо обязательно окажется во входящих: на доставку также влияют политика домена, репутация отправителя, содержание и другие проверки.

Если получаю dkim=fail, сначала сопоставляю s= с именем TXT-записи, затем проверяю, что в DNS опубликован открытый ключ именно от того закрытого ключа, которым подписывает сервер. Отдельная запись с опечаткой, лишний селектор в конфигурации или старая подпись от другого исходящего сервиса дают похожий внешний симптом. TXT может отображаться несколькими фрагментами в интерфейсе DNS; важно, чтобы итоговое значение записи соответствовало формату протокола. Не создавайте несколько TXT-записей с одним именем селектора.

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

Пересылка тоже меняет картину: промежуточный сервис может переписать тему, тело или заголовки письма, и прежняя DKIM-подпись тогда не пройдет проверку. Это не доказывает ошибку при ротации. Сравните исходное сообщение и пересланную копию, а если нужна общая диагностика, используйте чек-лист проверки доставки. После успешного теста продолжайте наблюдать за реальными маршрутами и удаляйте старую запись только по заранее зафиксированному условию.

Частые вопросы