DKIM

DKIM (DomainKeys Identified Mail) — это технология проверки электронной почты, предназначенная для подтверждения подлинности отправителя и целостности содержимого письма. DKIM позволяет получающей стороне (почтовому серверу) убедиться, что письмо действительно было отправлено с домена, указанного в поле «From», и не было изменено в процессе передачи. Технология основана на криптографической подписи и является одним из ключевых механизмов борьбы с подделкой писем (спуфингом), фишингом и спамом.

История создания и развития

Идея использования криптографической подписи для проверки почты возникла в начале 2000-х годов в ответ на рост числа поддельных писем. Первой попыткой стала технология DomainKeys, разработанная компанией Yahoo! в 2004 году. Она использовала асимметричное шифрование: закрытый ключ ставил подпись на исходящем письме, а открытый ключ публиковался в DNS-записях домена. Параллельно компания Cisco разрабатывала протокол Identified Internet Mail (IIM), который решал схожие задачи.

В 2006 году Yahoo! и Cisco объединили усилия, представив на рассмотрение IETF (Internet Engineering Task Force) объединённый стандарт — DomainKeys Identified Mail. В 2007 году был опубликован первый RFC (4871), а в 2011 году — обновлённый стандарт RFC 6376, который является действующим. С 2013 года DKIM входит в набор обязательных рекомендаций для почтовых систем наряду с SPF и DMARC.

Принцип работы

DKIM работает по схеме «асимметричного шифрования» с парой ключей: закрытым и открытым.

Подпись письма (на стороне отправителя)

1. Почтовый сервер отправителя генерирует цифровую подпись для определённых полей письма (заголовков и тела). Обычно подписываются поля From, Subject, Date, Message-ID, а также тело письма.
2. Для создания подписи используется закрытый ключ, который хранится на сервере отправителя и не разглашается.
3. Подпись добавляется в письмо в виде нового заголовка DKIM-Signature. Этот заголовок содержит:

• v= — версия DKIM (обычно 1);
• a= — алгоритм подписи (например, rsa-sha256);
• d= — домен отправителя (например, example.ru);
• s= — селектор — идентификатор записи с открытым ключом в DNS;
• h= — список подписанных заголовков;
• bh= — хеш тела письма;
• b= — сама цифровая подпись (в кодировке Base64).

Проверка подписи (на стороне получателя)

1. Получающий почтовый сервер извлекает из заголовка DKIM-Signature домен (d=) и селектор (s=).
2. По этим данным сервер выполняет DNS-запрос к записи вида: s._domainkey.d.example.ru. В ответе возвращается TXT-запись, содержащая открытый ключ.
3. Используя открытый ключ, сервер проверяет подпись, указанную в поле b=. Для этого он повторно вычисляет хеш подписанных заголовков и тела письма и сравнивает его с расшифрованным значением подписи.
4. Если подпись верна и хеши совпадают — письмо считается подлинным и не изменённым. Если нет — подпись считается недействительной, и письмо может быть отклонено или помечено как подозрительное.

Структура DKIM-записи в DNS

Для работы DKIM в DNS-зоне домена публикуется TXT-запись, содержащая открытый ключ и параметры. Формат записи:

`` s._domainkey.d.example.ru. TXT "v=DKIM1; p=MIGfMA0GCSqGSIb4...; t=y;" ``

Основные теги:

• v= — версия (обязательно DKIM1);
• p= — открытый ключ в кодировке Base64;
• t=y — тестовая подпись (письма с такой подписью не должны блокироваться);
• t=s — подпись строго ограничена доменом (не может использоваться для поддоменов);
• k= — тип ключа (rsa, ed25519 и др.);
• s= — тип сервиса (например, email).

Классификация и варианты использования

DKIM применяется в различных контекстах:

• Индивидуальные домены — компании и частные лица настраивают DKIM для своих почтовых серверов (например, на базе Postfix, Exim, Microsoft Exchange).
• Почтовые провайдеры — крупные сервисы (Яндекс, Mail.ru, Gmail, Outlook) автоматически подписывают письма, отправляемые через их системы, если домен настроен корректно.
• Сервисы массовых рассылок — платформы (SendGrid, Mailchimp, Amazon SES) требуют настройки DKIM для подтверждения домена отправителя.
• Поддомены — можно настроить отдельные ключи для разных поддоменов (например, news.example.ru, support.example.ru).

Преимущества и ограничения

Преимущества

• Защита от подделки — DKIM позволяет отличить легитимное письмо от поддельного, даже если злоумышленник подделал обратный адрес.
• Целостность — любое изменение письма в пути (вставка ссылок, изменение текста) делает подпись недействительной.
• Независимость от маршрута — DKIM проверяет содержимое, а не IP-адрес, поэтому письмо может проходить через релеи и не терять подлинность.
• Совместимость с DMARC — DKIM является одним из двух (наряду с SPF) механизмов, которые использует протокол DMARC для принятия решения о доставке письма.

Ограничения

• Не защищает от компрометации ключа — если злоумышленник получит закрытый ключ, он сможет подписывать письма от имени домена.
• Не проверяет контент — DKIM не анализирует, является ли письмо вредоносным или спамом, а лишь подтверждает, что оно отправлено с авторизованного сервера.
• Зависимость от DNS — для проверки требуется доступ к DNS-серверу; если DNS недоступен или запись настроена неверно, проверка не сработает.
• Не решает проблему с фишингом полностью — злоумышленники могут использовать похожие домены (например, example-russia.ru вместо example.ru) с собственными DKIM-ключами.

Взаимодействие с другими протоколами

DKIM часто используется в связке с двумя другими технологиями:

• SPF (Sender Policy Framework) — проверяет, что IP-адрес отправителя разрешён в DNS-записях домена. DKIM дополняет SPF, так как не зависит от IP-адреса.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) — политика, которая указывает получающему серверу, что делать с письмами, не прошедшими проверку DKIM или SPF (например, помещать в спам или отклонять). DMARC также предоставляет отчёты о попытках подделки.

Совместное использование SPF, DKIM и DMARC считается современным стандартом безопасности электронной почты.

Настройка DKIM

Процесс настройки включает несколько шагов:

1. Генерация ключевой пары — на почтовом сервере создаётся закрытый и открытый ключи (обычно с помощью утилит opendkim-genkey или через панель управления хостингом).
2. Публикация открытого ключа — TXT-запись с открытым ключом добавляется в DNS-зону домена через панель управления DNS.
3. Настройка почтового сервера — в конфигурацию MTA (Mail Transfer Agent) добавляется модуль подписи (например, opendkim для Postfix).
4. Тестирование — отправка тестового письма и проверка заголовков (наличие DKIM-Signature). Сервисы, такие как Mail-Tester или DKIMvalidator, помогают проверить корректность настройки.

Проблемы и ошибки

• Неверный селектор — если селектор в заголовке не соответствует записи в DNS, подпись не пройдёт проверку.
• Истечение ключа — некоторые реализации требуют обновления ключей раз в несколько лет.
• Длина ключа — слабые ключи (менее 1024 бит) могут быть взломаны; рекомендуется использовать ключи длиной 2048 бит.
• Подпись тела — если письмо проходит через почтовые серверы, которые изменяют его (например, добавляют подпись или ссылку на веб-версию), подпись может стать недействительной. Для решения используется канонизация (простая или расслабленная).

Интересные факты

• DKIM используется не только для email, но и для подписи других сообщений, например, в протоколах DomainKeys для веб-форм.
• В 2022 году компания Google начала требовать DKIM для всех массовых рассылок (более 5000 писем в день), что привело к активному внедрению технологии.
• Алгоритм RSA остаётся самым распространённым для DKIM, но в последних версиях стандарта (RFC 8463) добавлена поддержка Ed25519 — более современного и быстрого алгоритма.

Источники

• RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures (2011)
• RFC 8463 — Ed25519-SHA256 for DKIM (2018)
• RFC 7489 — Domain-based Message Authentication, Reporting and Conformance (DMARC) (2015)
• IETF — Internet Engineering Task Force, рабочие материалы по DKIM
• Материалы конференций по безопасности электронной почты (M3AAWG, 2010–2023)
• Документация почтовых серверов (Postfix, Exim, OpenDKIM)