DKIM-подпись: что это и как правильно настроить

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

Зачем нужен DKIM

Протокол SMTP не проверяет, кто на самом деле отправил письмо. Любой сервер может указать произвольный адрес в поле From. DKIM закрывает эту брешь: он привязывает содержимое письма к конкретному домену через цифровую подпись.

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

Как работает DKIM-подпись

Процесс состоит из двух этапов: подписание на стороне отправителя и проверка на стороне получателя.

Подписание. Когда письмо покидает отправляющий сервер, тот выбирает набор заголовков (From, To, Subject, Date и другие) и тело письма. На основе этих данных вычисляется хеш. Хеш шифруется закрытым ключом, и результат помещается в заголовок DKIM-Signature.

Проверка. Принимающий сервер извлекает из заголовка DKIM-Signature домен (d=) и селектор (s=). По этим данным формирует DNS-запрос вида selector._domainkey.example.com и получает открытый ключ. Затем расшифровывает подпись, вычисляет собственный хеш тех же заголовков и тела и сравнивает результаты. Совпадение означает Pass.

Структура заголовка DKIM-Signature

Заголовок содержит несколько параметров, каждый отвечает за свою часть проверки:

v=1 - версия DKIM (всегда 1). a=rsa-sha256 - алгоритм подписи. d=example.com - домен, от имени которого подписано письмо. s=mail2024 - селектор, указывающий на конкретный ключ в DNS.

h=from:to:subject:date - список подписанных заголовков. bh= - хеш тела письма. b= - сама подпись в кодировке Base64.

Параметр c=relaxed/relaxed задаёт режим канонизации - правила нормализации заголовков и тела перед хешированием. Режим relaxed допускает незначительные изменения пробелов и регистра, что снижает количество ложных срабатываний при прохождении через промежуточные серверы.

DNS-запись с открытым ключом

Открытый ключ публикуется в TXT-записи DNS. Имя записи строится по шаблону selector._domainkey.example.com. Содержимое включает версию, тип ключа и сам ключ в формате Base64.

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

Длина ключа: 1024 vs 2048 бит

Стандарт допускает ключи от 1024 бит, но с 2024 года Google и Yahoo требуют минимум 1024 бит для прохождения проверки. На практике стоит использовать 2048-битные ключи: они обеспечивают запас криптографической стойкости на годы вперёд.

У 2048-битных ключей есть особенность: длина TXT-записи превышает 255 символов, а это максимум одной DNS-строки. Запись нужно разбить на несколько строк (multi-string TXT record). Большинство DNS-хостингов делают это автоматически, но при ручной настройке легко допустить ошибку.

Канонизация: simple и relaxed

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

Режим simple требует точного совпадения - используется редко. Режим relaxed нормализует пробелы и регистр перед вычислением хеша. Стандартная рекомендация - c=relaxed/relaxed, где первый параметр относится к заголовкам, второй - к телу.

Ротация ключей

Закрытый ключ следует менять регулярно - раз в 6-12 месяцев. Если ключ утечёт, злоумышленник сможет подписывать письма от имени вашего домена до тех пор, пока ключ активен.

Процедура ротации: создайте новую пару ключей с новым селектором. Опубликуйте открытый ключ в DNS. Переключите отправляющий сервер на новый селектор. Убедитесь, что письма подписываются новым ключом. Только после этого удалите старую DNS-запись. Между публикацией нового ключа и удалением старого оставьте буфер в несколько дней - в очередях MTA могут оставаться письма, подписанные старым ключом.

Частые ошибки при настройке DKIM

Отсутствие DKIM для внешних сервисов. Компания настроила DKIM для корпоративной почты, но забыла про ESP, CRM или helpdesk. Письма от этих сервисов уходят без подписи и проваливают проверку DMARC.

Ошибки в DNS-записи. Лишний пробел, незакрытая кавычка, отсутствие разбивки длинного ключа на строки. Любая синтаксическая ошибка делает ключ нечитаемым, и проверка возвращает PermError.

Подпись не включает заголовок From. По стандарту RFC 6376 заголовок From обязателен в списке подписываемых заголовков. Без него DMARC alignment не пройдёт, даже если сама подпись валидна.

Устаревший ключ. Ключ не менялся годами. Чем дольше ключ активен, тем выше вероятность компрометации. К тому же 512-битные ключи, которые использовались на ранних этапах DKIM, уже давно считаются небезопасными.

DKIM в связке с SPF и DMARC

DKIM сам по себе не указывает, что делать с письмом, которое не прошло проверку. Это задача DMARC. DMARC требует, чтобы хотя бы один из механизмов - SPF или DKIM - прошёл проверку с корректным alignment (домен в подписи совпадает с доменом в From).

На практике DKIM надёжнее SPF при пересылке. Когда письмо форвардится через промежуточный сервер, SPF часто ломается: IP пересылающего сервера не указан в SPF-записи оригинального домена. DKIM-подпись при этом сохраняется, потому что привязана к содержимому письма, а не к IP-адресу отправителя.

Именно поэтому для прохождения DMARC при пересылке DKIM играет ключевую роль. Без валидной DKIM-подписи пересланные письма рискуют оказаться в спаме.