Потеряли DKIM-ключ? Проверьте подпись и DNS по шагам

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

Как понять, что сломалась именно DKIM-подпись

Когда письмо попадает в спам, я не объявляю виновником DKIM по одному симптому. На доставку влияют репутация отправителя, SPF, DMARC, содержимое письма и правила конкретного получателя. Сначала отправьте контрольное письмо на внешний адрес, который вы можете проверить, и откройте его исходные заголовки. В Authentication-Results смотрите результат DKIM и домен проверки; значение dkim=pass означает, что принимающая сторона проверила подпись. dkim=fail говорит о неуспешной проверке, а dkim=none — что принимающая сторона не обнаружила подписи. Это ориентиры из заголовка конкретного получателя, а не диагноз всему почтовому потоку.

Затем сопоставьте время отправки с журналами почтовой системы: был ли запрос на подпись, какой компонент его обрабатывал и сообщил ли он об ошибке чтения ключа или конфигурации. В Postfix сам по себе журнал не обязан содержать события DKIM: подпись часто выполняет отдельный фильтр или почтовая платформа. Поэтому ищите запись в журналах именно своего подписывающего компонента. Permission denied или отсутствие файла — повод проверить путь, владельца, режим доступа и подключённый том, но не доказательство, что ключ потерян. Перезагрузка могла совпасть с проблемой, а могла просто привлечь к ней внимание. Для разбора настройки SPF, DKIM и DMARC важно не смешивать три независимые проверки.

Результат DKIM и итоговая доставка — разные вещи. DMARC оценивает выравнивание домена видимого отправителя с прошедшим SPF или DKIM; политика домена задаёт пожелание получателю, что делать с письмом, которое не прошло проверку DMARC. При политике p=none владелец просит не применять специальное действие только на основании DMARC, при quarantine просит поместить письмо в подозрительные, при reject — отклонить. Получатель сохраняет собственную антиспам-политику. Поэтому неверно говорить, что любой dkim=fail автоматически означает подделку, блокировку или спам.

Перед изменениями я фиксирую три значения: домен в подписи, селектор из DKIM-Signature и DNS-ответ по имени <selector>._domainkey.<домен>. Селектор — часть имени DNS-записи; он позволяет держать несколько ключей для одного домена и менять их поэтапно. Проверка только главной TXT-записи домена здесь бесполезна. Если подпись отсутствует, разбирайте включение подписания и маршрут исходящего письма; если есть fail, проверяйте содержимое подписи и соответствие публичного ключа закрытому. Это две разные ветки поиска, и смешивать их — быстрый способ чинить не ту настройку.

Что делать с потерянным ключом: условный пример

В черновом сценарии студия «Медея-Мед» столкнулась с отсутствующей подписью после перезапуска почтовой системы. Я оставляю компанию только как условный пример: у нас нет проверяемых журналов, конфигурации или подтверждения, что именно такой инцидент происходил. Поэтому здесь нет выдуманных 20 сотрудников, недельного отключения резервной копии и «ровно 14 минут» восстановления. Для реального разбора такие числа берутся из заявки и журналов, а не из желания сделать историю эффектнее.

В условном сценарии сначала выясняем, сохранился ли закрытый ключ и где платформа хранит настройки подписания. Если файл или запись доступны и целы, восстановление прежней конфигурации может быть проще смены ключа. Если ключ действительно утрачен, создать его заново технически можно, но надо одновременно связать новую закрытую часть с подписывающим компонентом, а открытую — опубликовать в DNS. До этого система может подписывать новым селектором, пока получатели всё ещё видят старую DNS-версию; последовательность включения зависит от платформы. В документации Carbonio указано, что закрытый ключ DKIM хранится в LDAP, а почтовый транспорт начинает использовать созданный ключ сразу. Значит, совет искать Carbonio-ключ только в файле на диске неверен.

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

После восстановления я подтверждаю результат новым письмом и фиксирую изменения: какой селектор используется, где хранится закрытая часть, какая DNS-запись опубликована и кто отвечает за её контроль. «Почта снова работает» — слишком расплывчатая отметка для аварийной задачи: входящая почта могла работать всё время, а исходящая подписываться лишь с части узлов. Нужны контрольные письма из фактических каналов отправки и результат проверки у получателя. Для условной студии это и было бы критерием завершения, а не обещание вернуть все письма в папку «Входящие».

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

В DKIM закрытый ключ остаётся у системы, которая подписывает исходящие сообщения, а открытый публикуется в DNS для проверки получателем. Я не советую выполнять команду удаления ключа из случайного примера: у Carbonio, Zimbra, Mailcow и связки Postfix с OpenDKIM отличаются хранение ключей, способ назначения селектора и управление сервисами. Даже похожая утилита может иметь другой смысл в конкретной сборке. Сначала откройте документацию именно установленной версии и выясните, какой компонент подписывает почту и как его штатно настраивать. В официальном руководстве Carbonio для создания пары указана утилита /opt/zextras/libexec/zmdkimkeyutil; там же описаны LDAP и порядок активации. Это полезная проверенная привязка, но не универсальная команда для всех платформ.

Для независимой связки OpenDKIM генератор opendkim-genkey создаёт материал для публикации и закрытую часть, однако параметры команды и размещение файлов следует брать из руководства пакета в вашем дистрибутиве. Не подменяйте селектор словом default, если платформа уже подписывает другим именем. До генерации сохраните экспорт конфигурации и текущую публичную запись DNS, чтобы было понятно, что именно заменяется и как вернуть прежнюю настройку. Закрытый ключ ограничьте в доступе согласно пользователю и требованиям своего сервиса; точный владелец и права зависят от установки, контейнера и того, читает ли ключ процесс напрямую.

Для RSA стандарт обновлён: RFC 8301 требует от подписывающих систем ключ минимум 1024 бита и рекомендует 2048 бит; проверяющие должны поддерживать RSA от 1024 до 4096 бит, а более длинные ключи могут поддерживаться. Поэтому утверждение «минимум 2048, лучше 4096, иначе фильтр отклонит» неточно. Практический выбор — обычно рекомендованные 2048 бит с проверкой возможностей почтовой платформы и DNS-провайдера. RFC 6376 отдельно предупреждает о росте размера ответа DNS и нагрузки при чрезмерно длинных ключах. Увеличить число на генераторе легко; сделать так, чтобы каждый получатель и DNS-путь корректно обработал запись, чуть сложнее.

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

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

Как опубликовать открытый ключ и учесть DNS-кэш

Открытый ключ размещают в TXT-записи с именем <селектор>._domainkey.<домен>. Имя селектора берите из фактической DKIM-подписи или интерфейса управления, а значение — из вывода штатной утилиты. Запись должна соответствовать формату, который ожидает DNS-провайдер: некоторые панели сами разбивают длинный TXT на строки, но это всё равно должно оставаться корректным значением записи. Не копируйте приватную часть в DNS. И не добавляйте новую запись поверх старой с тем же селектором без понимания формата: проверяющий должен получить именно один корректный публичный ключ для имени, указанного в подписи.

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

Проверяйте точное имя селектора запросом TXT через dig, например dig TXT selector._domainkey.example.com — замените примерные имя и домен на свои. Сначала узнайте ответ авторитетного DNS, затем сравните его с тем, что видит публичный резолвер. Если записи нет, проверьте имя зоны: панели DNS могут автоматически дописывать домен к введённому имени. Если ключ обрезан или разбит некорректно, сверяйте полное значение TXT, а не только первые символы. При несовпадении не запускайте массовую смену селекторов наугад: сначала выясните, какую запись реально запрашивают получатели.

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

Как перезапустить подпись и проверить письмо

Когда DNS опубликован, убедитесь, что отправляющий сервер использует именно новый ключ и селектор. Не выполняйте подряд systemctl restart opendkim и systemctl restart postfix, пока не знаете, что именно установлено: служба может называться иначе, быть контейнером или вовсе управляться почтовой платформой. В Carbonio применяется собственная схема управления сервисами; перезапуск всего кластера ради одной записи может прервать больше функций, чем нужно. Сначала используйте официальный порядок для вашей версии. Если конфигурация требует перечитать файл, иногда достаточно reload или перезапуска одного компонента, но это определяется его документацией. Универсальной команды, одинаковой для Carbonio, Mailcow и самостоятельного Postfix, нет.

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

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

Если dkim=pass, но письмо всё равно в спаме, DKIM уже не первая точка отказа. Сверьте выравнивание SPF/DKIM для DMARC, репутацию домена и IP отправки, обратную запись, частоту и содержание рассылки, а также отчёты принимающей стороны, если они доступны. Папка назначения зависит от локальных правил получателя, и ни один стандарт не обещает входящие только за успешно проверенную подпись. Мой критерий закрытия задачи — подпись проверяется на всех рабочих исходящих каналах, DNS отвечает ожидаемым ключом, а оставшиеся проблемы доставки расследуются отдельно.

Как не потерять ключ и спокойно менять его в будущем

Закрытый DKIM-ключ — часть конфигурации почты, поэтому включите его или штатный механизм его восстановления в защищённую схему резервного копирования. Доступ к резервной копии должен быть ограничен; хранить единственную копию рядом с рабочим сервером — всё равно что держать запасной ключ от офиса на той же связке, которая пропала. Для Carbonio отдельно учитывайте, что документация указывает хранение приватного ключа в LDAP: резервировать надо поддерживаемые данные и конфигурацию платформы целиком, а не угадывать каталог на диске. Проверьте восстановление на тестовом контуре или в согласованное окно, не меняя рабочую подпись ради эксперимента.

Ведите короткую карточку селекторов: домен, имя селектора, дата включения, владелец настройки, место защищённой резервной копии и план удаления старой записи. Это особенно полезно, если отправляет несколько систем: CRM, сайт, бухгалтерская программа и почтовый сервер могут подписываться разными ключами. У каждой исходящей системы должен быть известный маршрут подписи. При смене поставщика почты перепроверьте, кто подписывает письма и какие DNS-записи остаются действующими; список шагов для смены почтового провайдера помогает не потерять связанные настройки.

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

Раз в установленный у вас интервал проверяйте контрольное письмо, состояние DNS и возможность восстановить настройки. После обновления ОС или перезапуска проверьте не просто активность процесса, а факт подписи реальным письмом. В журнале мониторинга полезно замечать сбой компонента подписания и изменение DNS, но сигнал должен вести к понятной проверке, а не к автоматическому удалению ключа. Для почты компании до 50 рабочих мест такой план обычно проще и надёжнее, чем аварийная ночная смена записи без доступа к владельцу DNS. Если в инфраструктуре много систем отправки, поддержка резервного MX и второй площадки решает соседнюю задачу доступности, но не заменяет контроль DKIM.

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