Если SPF отвечает на вопрос “кому разрешено отправлять письма от имени домена”, то DKIM (DomainKeys Identified Mail) решает другую задачу — подтверждает, что содержимое письма не было изменено на пути от отправителя к получателю. Механизм строится на криптографии с открытым ключом: отправляющий сервер подписывает письмо закрытым ключом, а принимающая сторона сверяет подпись с открытым ключом, опубликованным в DNS-записи домена.
Принцип работы цифровой подписи
При отправке письма почтовый сервер вычисляет хэш от заголовков и части содержимого, шифрует его закрытым ключом и добавляет результат в специальный заголовок письма. Получатель, зная домен и селектор, запрашивает соответствующий открытый ключ из DNS и проверяет, совпадает ли расшифрованное значение с реальным содержимым письма. Если хотя бы один бит текста изменился в пути — например, из-за некорректной работы промежуточного сервера, — проверка не пройдёт.
Селекторы и множественные записи
Домен может использовать сразу несколько DKIM-ключей одновременно — для этого применяется механизм селекторов, когда каждая подпись ссылается на отдельную DNS-запись вида селектор ._domainkey.домен. Это позволяет разным сервисам отправки, работающим от имени одного домена, иметь собственные независимые ключи, не пересекающиеся между собой.
Жизненный цикл ключа
Генерация и публикация
Пара ключей создаётся один раз для конкретного селектора: закрытый остаётся на стороне отправляющего сервиса, открытый публикуется в DNS в виде TXT-записи определённого формата.
Ротация ключей
Поскольку компрометация закрытого ключа теоретически позволяет злоумышленнику подделывать подписанные письма, рекомендуется периодически заменять ключи на новые, публикуя очередной селектор и постепенно выводя предыдущий из использования.
Отзыв скомпрометированного ключа
При подозрении на утечку закрытого ключа соответствующую DNS-запись можно оперативно очистить, оставив пустое значение — это делает все письма, подписанные этим ключом, непроверяемыми и вынуждает почтовые системы применять к ним политику, установленную на уровне DMARC.
Что ломает подпись даже при корректной настройке
Модификация письма на промежуточных серверах
Некоторые корпоративные шлюзы, системы рассылки уведомлений или антивирусные фильтры вносят незначительные изменения в тело письма или заголовки при пересылке. Даже минимальная правка — добавленная подпись, изменённый порядок заголовков — приводит к тому, что проверка DKIM записи домена формально проваливается, хотя исходное письмо было подписано корректно.
Несовпадение домена подписи и домена отправителя
Технически DKIM может подписывать письмо от имени одного домена, даже если конверт письма указывает другой отправляющий адрес. Такое расхождение допустимо с точки зрения самого протокола, но снижает эффективность последующей проверки выравнивания (alignment), которая применяется на уровне DMARC.
Как убедиться, что подпись работает корректно
Убедиться, что для каждого активно используемого сервиса отправки опубликован собственный селектор с актуальным открытым ключом.
Проверить, что длина ключа соответствует современным рекомендациям, а не унаследована от устаревшей конфигурации.
Отследить, не осталось ли в DNS-зоне заброшенных селекторов от сервисов, которые больше не используются.
Убедиться, что письма после прохождения через внутреннюю почтовую инфраструктуру компании не подвергаются модификации, ломающей подпись.
Почему это не разовая настройка
DKIM нередко настраивают один раз при подключении нового почтового сервиса и больше не возвращаются к этому вопросу. Между тем изменение поставщика рассылок, миграция инфраструктуры или истечение срока действия ключа способны незаметно нарушить проверку — причём проблема часто обнаруживается только тогда, когда письма уже начинают терять в доставляемости, а не в момент фактической поломки.
