Что такое DKIM: подпись письма за 10 минут

SPF отвечает на один вопрос: «разрешено ли этому IP отправлять письма от этого домена?» DKIM отвечает на более сложный: «это письмо действительно написал тот, кто управляет этим доменом, и никто его не подменял в пути?» Два механизма дополняют друг друга, но gmail, Yandex и серьёзные провайдеры теперь требуют оба.

Почему DKIM вообще нужен

SPF аутентифицирует только IP соединения. Он не может сказать вам, менялось ли письмо в пути, и не сохраняется при пересылке. Если пользователь пересылает письмо с рабочей почты на личный Gmail, проверка SPF ломается — пересылающий сервер не в вашей SPF-записи. Вы видите доставку, но письмо уже попало в спам.

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

Крипто за 30 секунд

DKIM использует асимметричную криптографию. Вы генерируете пару ключей: приватный ключ остаётся на почтовом сервере, открытый ключ идёт в DNS как TXT-запись. Когда ваш сервер отправляет письмо, он хеширует определённые заголовки плюс тело, зашифровывает этот хеш приватным ключом и прикрепляет результат как заголовок DKIM-Signature.

Когда получатель получает письмо, он ищет ваш открытый ключ в DNS, расшифровывает подпись, пересчитывает хеш сам и сравнивает. Если совпадают — письмо аутентифицировано как исходящее от того, кто управляет этим приватным ключом. То есть от вас.

Что подписывает DKIM

DKIM-подпись охватывает две части:

• Список заголовков, указанных тегом h=. Обычно это From, To, Subject, Date,Message-ID и Content-Type. Заголовок From подписывается всегда.
• Хеш тела письма, сохранённый в теге bh=.

Оба значения подписываются вместе и сохраняются в теге b= заголовка DKIM-Signature. Всё, что не в h=, промежуточные серверы могут менять без нарушения подписи — поэтому заголовки Received не подписываются.

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

Реальный DKIM-Signature выглядит так:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
  b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD0...

Каждый тег:

• v=1 — версия DKIM, всегда 1.
• a=rsa-sha256 — алгоритм подписи. RSA-SHA256 — современный стандарт; старый RSA-SHA1 устарел.
• d=example.com — домен подписи. Это тег, который DMARC проверяет на выравнивание.
• s=selector1 — селектор, используется для построения DNS-запроса.
• c=relaxed/relaxed — канонизация для заголовков/тела. Relaxed игнорирует пробелы и регистр; simple — нет.
• h= — список покрытых заголовков.
• bh= — хеш тела.
• b= — сама подпись.

Селекторы

Селектор — это короткое имя, которое позволяет опубликовать несколько открытых ключей под одним доменом. Это часть DNS-запроса перед_domainkey. Если DKIM-Signature говорит d=example.com и s=mail2026, получатель ищет:

mail2026._domainkey.example.com

Селекторы служат трём целям. Они позволяют запускать несколько подписантов одновременно (разные ESP, разные ключи). Они позволяют ротировать ключи без перерыва — опубликуйте новый селектор, начните подписывать им, потом выведите старый из эксплуатации. И они изолируют взломы: если приватный ключ утёк, вы можете ротировать только этот селектор, остальное не трогая.

Хорошая практика: ротируйте ключи каждые 6–12 месяцев, держите предыдущий селектор живым неделю после переключения, чтобы письма в пути всё ещё верифицировались, потом удалите старую TXT-запись.

Домен d= против From заголовка

Домен подписи (d=) — это произвольный домен, любой может подписать письмо. Значение подписи в выравнивании: совпадает ли d= (или разделяет организационного родителя) с доменом в видимом заголовке From?

Это вся суть DMARC. Подпись от d=sendgrid.net на письме From: you@brand.com проходит DKIM, но не проходит DMARC выравнивание. Чтобы DMARC был доволен, вы настраиваете ESP подписывать с d=brand.com, что значит делегировать DKIM через CNAME-записи, которые даёт ESP. Все серьёзные ESP это поддерживают.

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

Выбор между 1024-битным и 2048-битным RSA-ключами. 2048 — современная рекомендация, это то, что Gmail и Microsoft используют внутренне. Компромисс: некоторые DNS-провайдеры всё ещё урезают TXT-записи больше 255 символов, а 2048-битный открытый ключ обычно превышает это, требуя запись как конкатенацию нескольких строк. Большинство провайдеров это делают прозрачно, некоторые — нет.

Если есть выбор — выбирайте 2048-бит. Если ваш DNS-провайдер её портит — смените провайдера раньше, чем упадёте на 1024-бит. Вендоры типа Cloudflare, Route 53 и Google Cloud DNS все правильно обрабатывают длинные TXT-записи.

Пошаговая настройка

Общий поток для любой ESP:

1. В админ-панели ESP включите DKIM для вашего домена отправки.
2. ESP генерирует пару ключей и показывает вам одну или несколько DNS-записей — обычно TXT-запись на селекторе или CNAME на запись, которую поддерживает ESP.
3. Опубликуйте эти записи в вашем DNS-провайдере ровно как показано.
4. Дождитесь распространения DNS (зависит от TTL, обычно менее 30 минут).
5. Нажмите «Проверить» в ESP. Она делает DNS-запрос, чтобы подтвердить, что открытый ключ live.
6. Отправьте тестовое письмо на Gmail и проверьте Исходный текст письма. Ищите dkim=pass в заголовке Authentication-Results.

Как проверить, что DKIM работает

Простейшая проверка: пошлите себе письмо на Gmail, откройте, нажмите меню (три точки), выберите «Исходный текст письма». В начале вы увидите:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@brand.com header.s=selector1 header.b=dzdVy...

dkim=pass с header.i=@brand.com, совпадающим с вашим From-доменом — вот хорошая подпись. Инструменты типа Mail-Tester, MXToolbox Email Headers и dmarcian автоматически это парсят.

Типичные ошибки

• Селектор не опубликован. Подписывающий сервер использует селектор s1, но вы опубликовали s2 в DNS. Каждое письмо не проходит.
• Несовпадение ключей. Вы пересоздали ключи на сервере, но забыли обновить DNS. Старый кэшированный открытый ключ больше не расшифровывает новые подписи.
• Сервисы, меняющие тело письма. Некоторые листовые серверы и шлюзы безопасности переписывают тело, добавляя юридические подписи. Это инвалидирует хеш тела. Решение: подписывайте после добавления подписи или отключите подпись.
• CNAME указывает на неправильную цель. Частая ошибка при настройке Mailchimp и SendGrid. Копируйте цель ровно как указана ESP.
• Несколько доменов, один селектор. Вы не можете иметь двух отправителей, подписывающих с d=brand.com; s=default и разными ключами — один будет падать. Используйте разные селекторы на вендора.

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