Проверка DKIM-записи домена

Что такое DKIM и что именно проверяется

DKIM (DomainKeys Identified Mail, RFC 6376) добавляет к письму криптографическую подпись. Закрытый ключ хранится на сервере отправителя, открытый публикуется в DNS. Отправляющий сервер берёт тело письма и выбранные заголовки, считает от них хеш и подписывает его закрытым ключом. Получатель достаёт из подписи домен и селектор, находит по ним открытый ключ, считает хеш заново и сравнивает. Сошлось: письмо действительно подписано владельцем ключа и по дороге не менялось.

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

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

Подпись приезжает в письме отдельным заголовком:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2024; h=from:to:subject:date:message-id; bh=…; b=…

• v=1: версия подписи.
• a=: алгоритм. Сейчас это rsa-sha256 или ed25519-sha256, а rsa-sha1 RFC 8301 запретил и для подписи, и для проверки.
• d=: домен, который берёт на себя ответственность за письмо. Именно его DMARC сравнивает с адресом в From.
• s=: селектор, то есть имя конкретного ключа в DNS.
• h=: подписанные заголовки. From должен быть в списке обязательно, без него получатель отбрасывает подпись.
• bh= и b=: хеш тела и сама подпись в base64.
• c=: канонизация заголовков и тела, о ней ниже.

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

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

simple почти ничего не прощает, и именно он действует, если тега нет вовсе: по умолчанию c=simple/simple. relaxed приводит имена заголовков к нижнему регистру, разворачивает перенесённые строки, сжимает пробелы и отрезает их в конце строк. Регистр в значениях заголовков и сами слова он не меняет. Обычно выбирают c=relaxed/relaxed: такая подпись переживает мелкие правки форматирования.

Где взять селектор DKIM

Запись DKIM лежит по адресу вида селектор._domainkey.example.com. Имя селектора выбирает сервис отправки, и единого списка не существует. DNS не позволяет спросить «какие селекторы есть у этого домена», можно только проверить конкретное имя.

Надёжный источник селектора один, само письмо. Откройте у себя в ящике любое письмо от проверяемого домена, посмотрите исходник и найдите заголовок DKIM-Signature: значение s= и есть селектор, а d= показывает домен, на котором лежит ключ.

Если письма под рукой нет, чекер переберёт пару десятков имён, которые ставят популярные сервисы. Перебор находит ключ часто, но отрицательный результат ничего не доказывает. «Ни один из известных селекторов не найден» значит ровно это: среди проверенных имён записи нет, а ваш сервис вполне мог назвать ключ по-своему.

Селекторы популярных сервисов

• Google Workspace: google
• Microsoft 365: selector1 и selector2
• Mailchimp: k1, k2, k3
• SendGrid: s1 и s2
• HubSpot: hs1 и hs2
• MailerLite: litesrv
• Яндекс 360: mail

DKIM-запись в DNS: теги v, k и p

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

Тег v необязателен, без него подразумевается DKIM1. k задаёт тип ключа (по умолчанию rsa), а p содержит сам открытый ключ в base64. Ключ RSA на 2048 бит занимает 392 символа, а одна строка TXT вмещает только 255, поэтому запись делят на несколько строк в кавычках. Получатель склеивает их без пробелов. Если панель DNS при этом вставила пробел или перенос, запись остаётся на месте, а подпись перестаёт сходиться. Это самая частая поломка DKIM.

Под одним селектором должна лежать ровно одна TXT-запись. Если их несколько, результат проверки стандарт не определяет.

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

RFC 8301 требует подписывать ключом RSA не короче 1024 бит и советует брать 2048. Получатели обязаны проверять ключи от 1024 до 4096 бит, а подпись ключом короче 1024 бит считать недействительной. Ключ на 512 бит, который RFC 6376 ещё требовал принимать, сегодня равен отсутствию подписи. Gmail для писем на личные ящики тоже требует ключ от 1024 бит и советует 2048, если DNS-провайдер позволяет.

RFC 8463 добавил ключи Ed25519: при той же стойкости они намного короче и влезают в одну строку TXT. Поддерживают их не все принимающие серверы, поэтому Ed25519 публикуют вторым селектором рядом с RSA, а не вместо него. Так сделано и в примере из самого RFC: письмо подписано двумя ключами сразу. Ключ нужной длины можно выпустить в генераторе DKIM.

Что означает результат

• Ключ найден и корректен. Запись читается, длина достаточная. Инфраструктура готова. Подписываются ли письма на самом деле, проверьте по заголовкам реального письма.
• Пустой тег p=. Ключ отозван намеренно. Нормально для старого селектора после ротации и ошибка, если селектор действующий.
• Ключ 1024 бита. Стандарт его ещё принимает, но советует 2048. Выпустите новый ключ под новым селектором.
• Ключ короче 1024 бит. Подпись таким ключом получатель обязан отбросить. Замените ключ сразу.
• Стоит t=y. Тестовый режим: письмо считается неподписанным, даже если подпись верна. Если селектор давно в бою, уберите тег.
• Запись не читается. Почти всегда значение разорвано переносами строк при копировании или в нём потерялись символы.

Смена ключа без потери подписи

Чем дольше живёт закрытый ключ, тем дороже его утечка: пока ключ действует, им можно подписывать письма от вашего имени. Порядок такой: создайте новую пару под новым селектором, опубликуйте открытый ключ, переключите подпись и убедитесь по заголовкам, что письма уходят с новым s=. Старую запись удаляйте только через несколько дней, потому что в очередях ещё лежат письма со старой подписью. Подробности, в том числе как часто менять ключ, в статье о ротации ключей DKIM.

В письме невалидная DKIM-подпись: что проверять

Строка «невалидная DKIM-подпись» означает, что подпись в письме есть, но получатель не смог её подтвердить. Это отличается от отсутствия подписи и лечится по-другому. Проверяйте в таком порядке.

Опубликован ли ключ по тому селектору, который указан в письме. Селектор стоит в теге s= заголовка DKIM-Signature, и запись ищется по адресу селектор._domainkey.домен. Если ключ ротировали, а старую запись удалили слишком рано, письма в очереди останутся с подписью, которую уже нечем проверить.

Цел ли ключ после переносов строк. Длинное значение часть DNS-панелей разбивает на части, и при склейке добавляются лишние пробелы. Внешне запись выглядит целой, а подпись не сходится.

Дошло ли письмо в том виде, в каком его подписали. DKIM подписывает заголовки и тело, поэтому любой промежуточный узел, дописавший строку в тему или футер, ломает подпись. Так делают почтовые шлюзы, антивирусы и списки рассылки. Канонизация relaxed спасает от пробелов и переносов, но не от изменённого текста.

Подписан ли заголовок From. Если его нет в теге h=, получатель отбрасывает подпись целиком, как бы правильно она ни была посчитана.

Совпадает ли домен подписи с видимым отправителем. Тег d= показывает, чьим доменом подписано письмо. Подпись может быть валидной сама по себе и при этом не засчитываться DMARC, если домен в d= принадлежит сервису рассылок, а не вам.

DKIM сам по себе домен не защищает

Подпись подтверждает, что письмо не изменилось в пути и отправлено тем, у кого есть закрытый ключ. Но она ничего не говорит получателю о том, что делать с письмом без подписи или с подписью чужого домена. Это решает DMARC: он требует, чтобы SPF или DKIM прошли для домена из From. Настроенный DKIM без DMARC не мешает подделать письмо от вашего домена, достаточно отправить его вовсе без подписи.

Зато при пересылке DKIM надёжнее SPF. Пересылающий сервер отправляет письмо со своего IP, и SPF исходного домена не сходится, а подпись остаётся верной, если письмо по дороге не правили. Политику DMARC можно посмотреть в проверке DMARC, список разрешённых серверов в проверке SPF.

Одного селектора обычно мало

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

Полный список проще всего собрать по отчётам DMARC. Там перечислены все источники, отправлявшие от вашего домена, с результатом по DKIM для каждого. То, что в отчёте показывает dkim=fail или отсутствие подписи, и есть места, где ключ либо не настроен, либо настроен неверно.

Что делать с чужим доменом

Проверка чужого DKIM полезна в двух ситуациях. Перед холодной рассылкой: домен с настроенной аутентификацией и строгим DMARC обычно принадлежит компании, которая следит за почтой, и требования к отправителю у неё соответствующие. При разборе подозрительного письма: если DKIM-Signature ссылается на домен, не имеющий отношения к видимому отправителю, это повод присмотреться внимательнее.