Содержание12
DKIM — цифровая подпись письма. Сервер отправителя подписывает письмо закрытым ключом, а открытый ключ лежит в DNS домена, и получатель по нему проверяет, что письмо отправлено от имени этого домена и не изменено в пути. Настроенный DKIM помогает письмам компании доходить до получателей и усложняет подделку вашего домена.
Что такое DKIM-подпись?
DKIM расшифровывается как DomainKeys Identified Mail. Стандарт RFC 6376 позволяет владельцу домена взять ответственность за письмо: прикрепить к нему подпись, которую получатель проверит через DNS. Подпись привязывает письмо к домену, а не к конкретному человеку: DKIM отделяет вопрос «кто подписал письмо» от вопроса «кто его автор».
Для читателя письма подпись невидима. Её проверяет принимающий почтовый сервер, и результат попадает в служебные заголовки. Google в справке Workspace пишет, что DKIM помогает защитить ваш домен от подделки, аутентифицируя письма с помощью DKIM-подписи.
DKIM отвечает на один вопрос: подписано ли письмо ключом, который опубликован у домена. Что делать с письмом, если подписи нет, решает политика DMARC, а список разрешённых серверов задаёт SPF. Это три разные записи, и DKIM не заменяет остальные.
Нужен ли DKIM, если почта работает и так?
Нужен, если вы хотите, чтобы письма доходили до людей. Требования крупных почтовых сервисов ужесточились, и Google прямо формулирует их в справке: все отправители на личные аккаунты Gmail должны настроить SPF или DKIM, а отправители массовых рассылок, более 5000 сообщений в день, — SPF, DKIM и DMARC.
Для обычной компании со счетами клиентам, уведомлениями о заказах и рассылкой это означает: даже если порог в 5000 писем вам далёк, подпись стоит настроить. Письма с формы заявки, CRM и сервиса рассылки уходят с вашего домена, и получатель сравнивает их с вашей подписью.
Исключение — домен, с которого вы вообще не отправляете почту: подписывать там нечего.
Как работает подпись
Принцип одинаков у всех почтовых сервисов. Пара ключей создаётся один раз: закрытый ключ остаётся на почтовом сервере, открытый публикуется в DNS.
Google описывает это так: закрытый ключ загружается на ваш почтовый сервер и добавляет подпись к каждому исходящему сообщению, а открытый хранится в DNS TXT-записи домена.
Факт. По RFC 6376 подписывающим рекомендован алгоритм rsa-sha256, а проверяющие обязаны уметь проверять подписи ключами длиной от 512 до 2048 бит.
Из чего состоит DKIM: заголовок и запись в DNS
У DKIM два видимых элемента: заголовок письма и TXT-запись в зоне домена. Заголовок выглядит так (значения bh и b сокращены):
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=site.ru; s=mail; h=from:to:subject:date; bh=...; b=...
Основные теги заголовка по RFC 6376:
| Тег | Что означает |
|---|---|
| d | домен, который подписал письмо и в чьей зоне лежит ключ |
| s | селектор: подраздел пространства имён ключей этого домена |
| a | алгоритм подписи, например rsa-sha256 |
| h | список подписанных заголовков, через двоеточие |
| bh | хеш тела письма |
| b | сама подпись |
| c | способ канонизации: simple или relaxed |
Открытый ключ лежит в DNS по адресу, который собирается из селектора и домена. По RFC 6376 все ключи DKIM хранятся в поддомене _domainkey. Для заголовка выше сервер получателя запросит TXT-запись mail._domainkey.site.ru. Значение выглядит примерно так, ключ сокращён:
mail._domainkey.site.ru. 21600 IN TXT "v=DKIM1; k=rsa; p=ОТКРЫТЫЙ_КЛЮЧ"
Версия, тип ключа и сам ключ — в одной строке. Готовое значение вам выдаёт почтовый сервис, придумывать его не нужно.
Селектор: зачем он нужен и как его найти
Селектор — короткое имя, которое стоит перед _domainkey. Он нужен, чтобы у одного домена было несколько ключей одновременно. RFC 6376 объясняет: для поддержки нескольких открытых ключей на один домен подписи пространство имён ключей делится селекторами.
На практике это значит, что у домена может быть ключ почтового сервиса, отдельный ключ сервиса рассылок и отдельный ключ CRM, и они не мешают друг другу. У Яндекс 360 селектор называется mail, а Google Workspace по умолчанию использует префикс google. Если ключ с таким префиксом у домена уже есть, при создании нового вводят другой.
Узнать селектор любого письма можно самому. Отправьте себе тестовое письмо, откройте его исходный код и найдите значение s в заголовке DKIM-Signature: так советует справка Google.
Селекторы удобны и при смене ключа. RFC 6376 рекомендует подписывать новым закрытым ключом сразу, а старый открытый ключ какое-то время держать в DNS, пока письма в пути проверяются.
Как настроить DKIM
Порядок зависит от того, где живёт ваша почта.
Домен делегирован почтовому сервису. Если вы передали домен на серверы Яндекса, по справке Яндекс 360 DKIM-подпись с публичным ключом настроится автоматически. Ничего добавлять в DNS не нужно.
Яндекс 360 и DNS у регистратора. Порядок из справки:
Если панель регистратора требует полное имя, пишут mail._domainkey.site.ru: справка Яндекс 360 отдельно отмечает, что в некоторых панелях к имени нужно добавлять домен.
Google Workspace. Здесь ключ создаёт консоль администратора:
По справке Google, после добавления ключа DKIM может начать работать до 48 часов. Если у вас несколько доменов, ключ нужно получить для каждого отдельно.
Какую длину ключа выбрать
Google предлагает два варианта: 2048 и 1024 бита. Рекомендация простая: если регистратор домена принимает 2048-битные ключи, выбирайте их, более длинные ключи надёжнее коротких. Если регистратор 2048-битные ключи не принимает, выбирайте 1024.
Нижняя граница задана в RFC 6376: подписывающие должны использовать RSA-ключи не короче 1024 бит для долгоживущих ключей. Ключи длиннее 2048 бит принимают не все проверяющие: стандарт гарантирует проверку только в диапазоне от 512 до 2048 бит.
Практический вывод: 2048 бит, если запись помещается, иначе 1024. Ключи в 512 бит проверяющие обязаны уметь читать, но для долгоживущей подписи они слишком короткие. Граница применимости такая: если ваш почтовый сервис выдаёт готовый ключ, длину выбирать вам не придётся, и этот раздел можно пропустить.
Есть и техническая оговорка. Ключ в 2048 бит длиннее, и некоторые провайдеры доменов ограничивают длину TXT-записей. Если вставка не проходит, проверьте у провайдера лимит и способ разбивки записи на части.
Как проверить DKIM
Начать проще с DNS. Выполните запрос TXT для имени с селектором, подставив свой домен:
nslookup -type=txt mail._domainkey.site.ru
В ответе должна быть строка, начинающаяся с v=DKIM1. Если ответа нет, запись не опубликована или имя хоста указано с ошибкой.
Затем проверяйте письмом. Отправьте письмо со своего домена на ящик в Gmail или Google Workspace и откройте оригинал письма: в Gmail это пункт «Показать оригинал». В заголовке Authentication-Results ищите dkim=pass и свой домен в параметре header.d. Справка Google отдельно предупреждает: проверить, включён ли DKIM, отправив тестовое письмо самому себе, нельзя, нужен другой получатель.
Повторите тест для каждого сервиса, который отправляет письма от имени домена: почтового сервиса, CRM, сервиса рассылок, формы на сайте. Подпись нужна каждому из них, и ключ у каждого свой.
Когда подпись ломается
DKIM проверяет, что письмо не изменилось, поэтому любое изменение в пути может сломать подпись. Чаще всего это пересылка и рассылки. RFC 6376 прямо оговаривает: сохранность подписи после передачи не гарантируется, и подписи могут не проходить без вины отправителя.
Этот факт важен для понимания результатов проверки. По RFC 6376 письмо с неверной подписью не следует обрабатывать иначе, чем письмо без подписи. Один dkim=fail ещё не делает письмо спамом, а политику на этот случай задаёт DMARC.
Частые причины проблем с DKIM:
- Исходящий шлюз меняет письмо — например, добавляет нижний колонтитул в конец каждого сообщения. Google просит проверить, что настройки шлюза не мешают DKIM.
- Ключ скопирован с лишними символами — перенос строки, лишние кавычки или пробелы в значении искажают ключ, и подпись не проходит проверку.
- Запись создана не на то имя — в панели нужно выбрать между mail._domainkey и mail._domainkey.site.ru, а не дублировать домен дважды.
- Новый сервис отправляет без своей подписи — CRM или рассылка шлют письма от вашего домена, но ключ для них не добавлен.
- Ключ удалён раньше времени — при смене ключа старую запись убрали сразу, и письма в пути перестали проходить проверку.
Мнение. Если DKIM не проходит только у писем, пересланных через сторонние ящики и рассылки, это нормально: подпись ломается в чужой инфраструктуре. Если же он падает у каждого вашего письма в Gmail, ищите ошибку в записи или в шлюзе.
С чего начать
Составьте список сервисов, которые отправляют письма от имени вашего домена. Для каждого найдите в справке, как включить DKIM. Начните с основного почтового сервиса, а после настройки проверьте результат через заголовок письма. Если домен куплен через нас, DNS-записи для почты добавим мы: это часть регистрации домена. О том, как устроен DNS в целом, рассказывает статья что такое домен сайта.
Источники
- Настройте DKIM — Справка Google Workspace
- DKIM-подпись — Яндекс 360 для бизнеса
- RFC 6376. DomainKeys Identified Mail (DKIM) Signatures — IETF