DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к каждому исходящему письму, что позволяет получателям убедиться, что сообщение было отправлено владельцем домена и не подвергалось изменениям во время пересылки. Определённый в RFC 6376, DKIM является одним из самых эффективных механизмов аутентификации электронной почты: в отличие от SPF, его надежность сохраняется даже при пересылке. В этом руководстве мы рассмотрим архитектуру подписи, структуру заголовка DKIM-Signature, сравнительные характеристики алгоритмов RSA и Ed25519, а также ротацию ключей, канонизацию, over-signing и распространённые ошибки.
- Содержание
- 1. Как работает DKIM
- 2. Анатомия заголовка DKIM-Signature
- 3. Концепция селектора
- Селекторы по провайдерам
- 4. RSA vs Ed25519: сравнение алгоритмов для DKIM
- 5. Канонизация: Simple и Relaxed
- 6. Процедура ротации ключей
- 7. DKIM и DMARC: выравнивание и совместная настройка
- 8. Over-Signing
- 9. Лучшие практики
- 10. Распространённые ошибки DKIM и способы их устранения
- 11. Инструменты
- 12. Источники и ссылки
- Ответы на эти вопросы могут быть для вас полезными
Содержание
- Как работает DKIM
- Анатомия заголовка DKIM-Signature
- Концепция селектора
- RSA в сравнении с Ed25519
- Канонизация: Simple и Relaxed
- Процедура ротации ключей
- DKIM и выравнивание DMARC
- Лучшие практики
- Распространённые сбои
- Инструменты
- Источники и ссылки
1. Как работает DKIM
DKIM использует асимметричную криптографию (пару открытого и закрытого ключей) для подтверждения содержания письма. Отправляющий сервер хранит закрытый ключ, а открытый ключ публикуется в DNS. Когда получатель получает сообщение, он извлекает открытый ключ и проверяет подпись
Генерация ключей. Владелец домена генерирует пару ключей RSA (или Ed25519). Закрытый ключ устанавливается на почтовый сервер или ESP (сервис рассылки, Email Service Provider). Открытый ключ публикуется как DNS TXT-запись по адресу selector._domainkey.example.com.
Подпись сообщения. Отправляющий MTA (агент передачи почты, Mail Transfer Agent) выбирает заголовки, которые будут подписаны — такие как From, To, Subject, Date, — и тело сообщения. Он производит их канонизацию (нормализацию пробелов), затем хэширует получившийся результат и шифрует его с использованием закрытого ключа.
Вставка подписи. Зашифрованный хэш и метаданные помещаются в заголовок DKIM-Signature, добавляемый в начало сообщения. Этот заголовок включает селектор, алгоритм, список подписанных заголовков и значение подписи в кодировке base64.
DNS-запрос. Принимающий MTA читает заголовок DKIM-Signature, извлекает селектор (s=) и домен (d=) и запрашивает s._domainkey.d для получения TXT-записи с открытым ключом.
Верификация. Получатель снова канонизирует подписанные заголовки и тело, вычисляет хэш и использует открытый ключ для расшифровки подписи. Если вычисленные хэши совпадают, это подтверждает, что подпись верна — сообщение не только подлинное, но и не изменялось.
Оценка DMARC. Если домен из поля d= совпадает с доменом заголовка From: (в режиме relaxed или strict), это означает, что DMARC считает DKIM успешным.
💡 DKIM не обеспечивает шифрования содержания сообщения. Он лишь добавляет цифровую подпись, подтверждающую исходное происхождение и целостность письма. Само сообщение передаётся в открытом виде, если только для защиты на транспортном уровне не используется TLS.
Когда вы выстраиваете связку DKIM, SPF и DMARC, полезно отдельно посмотреть Битва титанов: выбираем лучший сервис для email-рассылок, чтобы оценить, как инфраструктура отправки влияет на доставляемость и контроль домена.
2. Анатомия заголовка DKIM-Signature
Каждое сообщение, подписанное DKIM, содержит заголовок DKIM-Signature со следующими тегами:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; t=1712880000; x=1713484800; h=from:to:subject:date:message-id:mime-version; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=LjxLMKpHN2kQz... (значение подписи)| Тег | Обязательный | Значение | Допустимые значения |
|---|---|---|---|
| v | Да | Версия | 1 (всегда) |
| a | Да | Алгоритм подписи | rsa-sha256, rsa-sha1 (устарел), ed25519-sha256 |
| d | Да | Домен подписи (ключ выравнивания DMARC) | например, example.com |
| s | Да | Селектор (ключ поиска открытого ключа) | например, selector1, google, s1 |
| h | Да | Подписанные поля заголовка | Список имён заголовков, разделённых двоеточием |
| b | Да | Данные подписи (base64) | Значение криптографической подписи |
| bh | Да | Хэш тела (base64) | Хэш канонизированного тела |
| c | Нет | Канонизация (заголовок/тело) | simple/simple (по умолчанию), relaxed/relaxed, relaxed/simple |
| t | Нет | Временная метка подписи (Unix epoch) | например, 1712880000 |
| x | Нет | Срок действия подписи (Unix epoch) | например, 1713484800 |
| l | Нет | Ограничение длины тела (подписанные байты) | Целое число — избегайте использования |
| i | Нет | Идентификатор агента или пользователя | Должен быть поддоменом d= |
| q | Нет | Метод запроса | dns/txt (по умолчанию, единственное значение) |
| z | Нет | Скопированные поля заголовка (для диагностики) | Копии подписанных заголовков, разделённые символом pipe |
🚫 Избегайте использования тега l= (ограничение длины тела). Он ограничивает проверку только первыми N байт тела, что создаёт уязвимость, позволяя злоумышленникам добавлять вредоносное содержимое после подписанной части. RFC 6376 §8.2 чётко предостерегает от такой практики.
3. Концепция селектора
Селектор — это метка, позволяющая одному домену иметь несколько ключей DKIM одновременно. Это необходимо для ротации ключей и работы в многосервисных средах. Открытый ключ публикуется по адресу <selector>._domainkey.<domain>
📖 Определение. Селектор DKIM — произвольная строка, выбранная владельцем домена, которая идентифицирует конкретную запись открытого ключа в DNS. Он указывается в теге s= заголовка DKIM-Signature и используется для построения DNS-запроса: selector._domainkey.domain.com.
Селекторы по провайдерам
На практике я рекомендую использовать описательные селекторы, включающие дату или назначение: google-2024, marketing-q1. Это значительно упрощает аудит ротации ключей — с первого взгляда видно, какие ключи актуальны, а какие устарели.
4. RSA vs Ed25519: сравнение алгоритмов для DKIM
RFC 8463 (2018) представил Ed25519 в качестве альтернативы RSA для подписей DKIM. Вот как они соотносятся между собой:
🎯 Оптимальная стратегия — двойная подпись с RSA-2048 и Ed25519 одновременно. Получатели, поддерживающие Ed25519, получают преимущество в виде меньших подписей и более быстрой верификации. Те, кто не поддерживает, будут использовать подпись RSA. Каждая подпись использует отдельный селектор.
5. Канонизация: Simple и Relaxed
Канонизация нормализует сообщение перед хэшированием, чтобы допускать незначительные изменения, вносимые промежуточными почтовыми серверами. Тег c= задаёт алгоритм для заголовков и тела отдельно — например, c=relaxed/relaxed
# simple/simple — очень строгий, легко нарушается:
Subject: Hello World ← точные байты должны совпадать
# relaxed/relaxed — устойчив к изменениям пробелов:
Subject:Hello World ← лишние пробелы и изменения регистра нормализуются
subject: hello world ← оба варианта канонизируются к одной форме⚡ Совет профессионала: всегда используйте c=relaxed/relaxed. Промежуточные серверы — списки рассылки, службы пересылки, антивирусные шлюзы — часто изменяют пробелы. Простая канонизация вызывает ненужные сбои DKIM в реальных почтовых потоках.
6. Процедура ротации ключей
Ключи DKIM следует периодически менять — каждые 6–12 месяцев — чтобы ограничить ущерб в случае компрометации закрытого ключа. Механизм селекторов делает ротацию без простоев вполне решаемой задачей
Шаг 1. Генерация новой пары ключей. Создайте новую пару ключей RSA-2048 или Ed25519 с новым селектором — например, dkim-202604.
Шаг 2. Публикация нового открытого ключа. Добавьте новую TXT-запись по адресу dkim-202604._domainkey.example.com. Дождитесь распространения DNS (TTL).
Шаг 3. Переключение подписи на новый селектор. Настройте ваш MTA или ESP для подписи исходящей почты новым закрытым ключом и селектором.
Шаг 4. Мониторинг сбоев. Следите за отчётами DMARC и заголовками верификации DKIM в течение нескольких дней. Убедитесь, что новый ключ проходит проверку.
Шаг 5. Отзыв старого ключа. После периода перекрытия в 1–2 недели опубликуйте пустой тег p= для старого селектора: v=DKIM1; p=. Это сообщает получателям, что ключ отозван.
Шаг 6. Удаление старой DNS-записи. После ещё одного цикла TTL полностью удалите DNS-запись старого селектора.
💡 Пустой тег p= в DNS-записи DKIM (RFC 6376 §3.6.1) — официальный сигнал отзыва. Он сообщает верификаторам, что ключ был намеренно отозван, в отличие от отсутствующей записи, которая может восприниматься как сбой DNS.
7. DKIM и DMARC: выравнивание и совместная настройка
Чтобы DMARC засчитал DKIM как пройденный результат, должны быть выполнены два условия одновременно
Первое: подпись DKIM должна быть верифицирована — то есть криптографически действительна.
Второе: домен d= должен совпадать с доменом заголовка From:.
8. Over-Signing
📖 Определение. Over-signing (избыточная подпись) — лучшая практика DKIM, при которой тег h= включает заголовки, отсутствующие в сообщении. Например, Reply-To указывается дважды. Это предотвращает добавление злоумышленниками поддельного заголовка Reply-To после подписи — любое добавление сделает подпись недействительной.
# Пример over-signing: перечисление заголовков, отсутствующих в сообщении
h=from:to:subject:date:reply-to:reply-to:cc:cc
# "reply-to" указан дважды:
# Первый экземпляр охватывает фактический заголовок Reply-To (если присутствует)
# Второй экземпляр "запечатывает" слот — добавление нового Reply-To нарушает подпись
🎯 Применяйте over-signing как минимум для этих заголовков: From, To, Subject, Date, Reply-To, CC, Content-Type, MIME-Version, Message-ID. Over-signing предотвращает атаки с инъекцией заголовков после подписи.
9. Лучшие практики
Используйте RSA минимум 2048 бит. 1024-битные ключи устарели согласно RFC 8301. Генерируйте 2048-битные ключи для всех селекторов.
Используйте канонизацию relaxed/relaxed. Простая канонизация слишком легко даёт сбои при работе с промежуточными MTA. Relaxed — отраслевой стандарт.
Подписывайте своим доменом. Убедитесь, что тег d= совпадает с вашим доменом From: для выравнивания DMARC. Настройте пользовательский DKIM на каждом ESP.
Выполняйте ротацию ключей каждые 6–12 месяцев. Используйте систему селекторов для ротации без простоев. Отзывайте старые ключи с помощью пустого тега p=.
Применяйте over-signing для критических заголовков. Указывайте From, Reply-To, Subject и CC дважды в теге h= для предотвращения инъекции заголовков.
Никогда не используйте тег l=. Ограничения длины тела позволяют добавлять содержимое к подписанным сообщениям. На моей практике именно этот пункт чаще всего упускают при первичной настройке — всегда подписывайте полное тело.
10. Распространённые ошибки DKIM и способы их устранения
🚫 DNS-запись не найдена. Наиболее распространённый сбой DKIM. Обычно вызван опечаткой в имени селектора, отсутствующей CNAME-записью или задержкой распространения DNS. Всегда проверяйте с помощью dig TXT selector._domainkey.example.com.
🚫 Несовпадение хэша тела (тег bh=). Тело было изменено после подписи — как правило, списком рассылки, антивирусным шлюзом или службой добавления нижних колонтитулов. Используйте relaxed-канонизацию тела и исследуйте конкретные MTA в цепочке доставки.
11. Инструменты
| Инструмент | Назначение |
|---|---|
| DKIM Record Checker | Поиск открытого ключа любого селектора и проверка синтаксиса записи |
После технической настройки DKIM полезно отдельно посмотреть Email рассылки: как не нарушить закон и не попасть на штраф за рассылку, чтобы сверить техническую аутентификацию с юридическими требованиями к массовым отправкам.
12. Источники и ссылки
📄 RFC 7489 — DMARC
🎯 Ключевой вывод: DKIM — наиболее устойчивый механизм аутентификации электронной почты: он выживает при пересылке, проверяет целостность сообщений и обеспечивает предпочтительный путь выравнивания для DMARC. Используйте RSA 2048 бит или Ed25519, всегда выбирайте канонизацию relaxed/relaxed, подписывайте своим доменом для выравнивания DMARC, применяйте over-signing для критических заголовков, выполняйте ротацию ключей каждые 6–12 месяцев и никогда не используйте тег l= для ограничения длины тела.
Ответы на эти вопросы могут быть для вас полезными
Чем DKIM отличается от SPF и почему он надёжнее при пересылке?
SPF проверяет IP-адрес отправляющего сервера, и при пересылке письма через третий сервер проверка ломается. DKIM привязан к криптографической подписи в заголовке письма, которая сохраняется при пересылке — именно поэтому DKIM считается более устойчивым механизмом аутентификации.
Можно ли использовать несколько ключей DKIM для одного домена одновременно?
Да, именно для этого существует механизм селекторов. Каждый селектор указывает на отдельную TXT-запись в DNS с собственным открытым ключом. Это позволяет одновременно использовать разные ключи для разных ESP или поддерживать двойную подпись RSA и Ed25519.
Что произойдёт, если не выполнять ротацию ключей DKIM?
Если закрытый ключ будет скомпрометирован, злоумышленник сможет подписывать письма от имени вашего домена неограниченно долго. Ротация каждые 6–12 месяцев ограничивает окно возможного ущерба и является требованием ряда корпоративных политик безопасности.
Почему DKIM не защищает от изменения содержимого письма в пути?
DKIM подписывает только выбранные заголовки и тело на момент отправки. Если промежуточный сервер изменит тело — например, добавит нижний колонтитул — хэш bh= не совпадёт и подпись не пройдёт верификацию. Именно поэтому канонизация relaxed/relaxed снижает количество ложных сбоев от незначительных изменений пробелов.
Как проверить, что DKIM настроен корректно?
Отправьте тестовое письмо и просмотрите полные заголовки в почтовом клиенте получателя. В строке Authentication-Results Gmail покажет dkim=pass при успешной верификации. Для проверки DNS-записи используйте команду dig TXT selector._domainkey.example.com или инструмент DKIM Record Checker.
