Тема
Проверка DKIM записи домена так, как её находят принимающие почтовые серверы, или тест подписи вставленного письма: какие селекторы отвечают, кто подписывает, насколько надёжен каждый ключ и выровнен ли он с DMARC.
Запрашивает те 140 селекторов, которые используют почтовые провайдеры, по имени selector._domainkey. плюс домен: DNS не умеет их перечислять
Введите домен выше: проверка запросит 140 селекторов, которыми пользуются почтовые провайдеры, покажет каждый найденный ключ с размером и провайдером и честно скажет, если ничего не нашла. Знаете селектор? Выберите Домен + селектор, и он проверится первым.
Вручную нужен селектор, потому что DNS не умеет их перечислять: dig +short TXT selector._domainkey.example.com, а в Windows nslookup -type=TXT с тем же именем. Селектор — это s= в DKIM-Signature любого письма (RFC 6376 §3.6.2.1).
dig показывает текст, а не его смысл: он не декодирует размер ключа, не идёт по CNAME провайдера и не отличает резервный слот от сломанного. Это и добавляет эта проверка DKIM записи.
dnsrobot.netdig +short TXT selector._domainkey.example.comВсе TXT-строки по этому имени: склейте их, чтобы прочитать ключ.
Что показывает dig, а что нет
$ dig +short TXT 20251104._domainkey.google.com 1
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQ…" "…k2A8ZfpQIDAQAB"2
$ dig +short TXT 20251104._domainkey.google.com | tr -d '" \n' | sed 's/.*p=//' | base64 -d | openssl pkey -pubin -inform DER -noout -text | head -1 3
Public-Key: (2048 bit)
$ dig +short TXT selector1._domainkey.microsoft.com 4
selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com.
Сначала идёт ответ одним предложением. Под ним — кто подписывает и сам ключ: каждый тег раскрашен поверх своих символов, а размер ключа показан на шкале RFC 8301; на тёмно-синем — каждый селектор, который запросила проверка, чтобы видно было, что пробовали.
Оценки нет: отозванный ключ или пустой резервный селектор провайдера — это нормально, а «не найдено среди распространённых селекторов» никогда не значит «нет DKIM».
ВердиктОдно предложение: сколько ключей и что нужно сделать.Кто подписываетОдна карточка на провайдера, найденного по CNAME или документированному селектору. Каждый селектор открывает свой ключ.КлючКаждый тег раскрашен поверх своих символов, а размер ключа показан на шкале RFC 8301.Перебор селекторовКаждое запрошенное имя загорается по мере ответа: зелёный — ключ, жёлтый — 1024 бита, пунктир — резервный слот.Выравнивание DMARCВыравнивается ли ключ с d= этого домена с его политикой DMARC.DKIM (DomainKeys Identified Mail) — это подпись, которую отправляющий сервер добавляет к каждому письму, а получатели проверяют открытым ключом, опубликованным доменом в DNS (RFC 6376). Действительная подпись доказывает два факта: домен из d= подписал письмо, и подписанные части с тех пор не менялись.
Отправитель хеширует тело в bh= и подписывает выбранные заголовки вместе с этим хешем своим закрытым ключом в b=. Получатель читает d= и s=, берёт ключ из s._domainkey.d и повторяет обе операции. Один изменённый байт в теле или в подписанном заголовке — и подпись не проходит.
DKIM ничего не говорит о том, что делать при сбое, и подписать может любой домен. Это работа DMARC: он требует действительную подпись, чей d= совпадает с доменом From:.
Одно письмо: подписано у отправителя и проверено у получателя
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=dnsrobot-sample; h=from:from:to:subject:…; bh=fohb/a+auh1W9cUN…; b=fF0aMr3Uo+mbgG…
dnsrobot-sample._domainkey.example.com TXT?"v=DKIM1; k=rsa; p=MIIBIjANBgkq…"RSA 2048
Письмо как отправлено
dkim=pass header.d=example.com
То же письмо, у которого по пути изменили Subject
dkim=fail (signature-mismatch)
Селектор — это имя одного ключа DKIM: s= в подписи и первая метка DNS-имени, по которому лежит ключ (s1._domainkey.github.com). У домена их может быть сколько угодно: по одному на провайдера, на сервер, на год (RFC 6376 §3.1).
Чтобы найти свой, откройте любое письмо, отправленное доменом, и посмотрите оригинал: в Gmail Ещё (⋮) › «Показать оригинал» показывает DKIM-Signature, и её s= — это селектор. Или вставьте письмо в Проверить письмо выше.
Большинство провайдеров используют фиксированные имена, поэтому перебор их находит. Amazon SES, Postmark, SparkPost и HubSpot создают имя для каждого аккаунта, и узнать его можно только из письма или панели провайдера.
От подписи к ключу и имена, которые используют провайдеры
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=s1; …
s1._domainkey.github.comCNAME s1.domainkey.u51742174.wl175.sendgrid.netRSA 2048
| Google Workspace | администратор может изменить префикс | |
|---|---|---|
| Microsoft 365 | selector1 · selector2 | CNAME в тенант; один активный, один резервный |
| Twilio SendGrid | s1 · s2 | CNAME на u<id>.wl<n>.sendgrid.net |
| Mailchimp | k2 · k3 | CNAME на dkim2/dkim3.mcsv.net |
| Fastmail | fm1 · fm2 · fm3 | три CNAME, заполнен один за раз |
| Proton Mail | protonmail · 2 · 3 | CNAME в domains.proton.ch |
| Amazon SES | 3 случайных токена | по 32 случайных символа: не угадать |
| Postmark | 20240101000000pm | дата и «pm»: не угадать |
| SparkPost | scph + MMYY | scph и месяц создания ключа |
| HubSpot | hs1-<HubID> | номер вашего аккаунта |
Запись DKIM — это TXT-запись из пар тег=значение, разделённых точкой с запятой; обязателен только p=, открытый ключ. v=DKIM1 необязателен, но если есть, должен идти первым (RFC 6376 §3.6.1).
k= задаёт тип ключа (rsa, если не указано ed25519), t= несёт флаги (y — тестирование, s — строгий), h= ограничивает хеши, а s= — службы. Пустой p= намеренно отзывает ключ.
Имена тегов чувствительны к регистру, а повторяющийся тег делает запись недействительной. Неизвестные теги игнорируются.
Запись по тегам
v=DKIM1; k=rsa; t=s; h=sha256; p=MIIBIjANBgkqhkiG9w…IDAQAB
| Тег | Задаёт | Значения | По умолчанию | Примечание |
|---|---|---|---|---|
| v= | Версия | DKIM1 | DKIM1 | рекомендуется; первый, если есть |
| k= | Тип ключа | rsa · ed25519 | rsa | неизвестные типы: ключ игнорируется |
| p= | Открытый ключ (base64) | ключ или пусто | обязателен | пусто = отозван |
| t= | Флаги | y тестирование · s строгий | нет | y: считается неподписанным |
| h= | Допустимые хеши | sha256 (sha1 запрещён) | все | один sha1 не проходит (RFC 8301) |
| s= | Тип службы | * | только другие службы: игнорируется | |
| n= | Заметки для людей | любой текст | – | программы не читают |
Какой длины p= и сколько TXT-строк ему нужно
границы TXT-строк по 255 байт (считая «v=DKIM1; k=rsa; p=»)
Используйте RSA на 2048 бит. RFC 8301 по-прежнему требует от проверяющих принимать ключи в 1024 бита, но просит от подписывающих не менее 2048 и велит проверяющим отвергать ключи короче 1024 бит. M3AAWG называет 1024 бита «на грани взлома» и сообщает, что ключ на 512 бит взломали примерно за 72 часа и примерно за 75 долларов.
Ключ Ed25519 невелик (44 символа p=), и для обратной совместимости RFC 8463 позволяет подписывающим добавить рядом подпись RSA: два селектора, две подписи (RFC 8463).
Меняйте так: опубликуйте новый ключ в новом селекторе, переключите подпись, держите старый ключ от 7 до 30 дней для писем в пути, затем опустошите его p=. M3AAWG советует делать это раз в полгода. Провайдеры вроде Fastmail и Microsoft 365 делают это за вас с помощью резервных селекторов.
Где настоящие ключи лежат на шкале RFC 8301
Замена без перерыва (M3AAWG)
DKIM не проходит, когда подписанные байты изменились, когда ключ не найден или когда ключ не подходит к подписи. Пересылка, которая не меняет письмо, сохраняет DKIM (в отличие от SPF); рассылки обычно его ломают, потому что добавляют футеры или помечают тему.
Проверка на этой странице смотрит хеш тела и подпись заголовков отдельно, поэтому отличает футер, добавленный по пути, от подделки.
Рассылка добавила футер размером 153 Б. Заголовки по-прежнему проверяются ключом project.example, так что это не подделка.
Что делать Рассылки, которые не меняют тело, или ARC (RFC 8617), чтобы последующие получатели видели исходный результат.
body-hash-mismatchПодписанный заголовок изменили после подписания (рассылка дописала своё название в Subject) или в селекторе теперь другой ключ.
Что делать Не переписывайте подписанные заголовки; публикуйте новый ключ в новом селекторе, а не заменяйте имеющийся.
signature-mismatchs=2023old._domainkey.shop.example — NXDOMAIN: селектор удалили, пока письма с ним ещё были в пути.
Что делать Держите старые ключи опубликованными 7–30 дней после переключения; опустошайте p=, а не удаляйте.
key-not-foundПересылка: пересылающий сервер, который передаёт письмо без изменений, сохраняет DKIM действительным, поэтому DMARC обычно переживает пересылку благодаря DKIM, даже когда SPF не проходит.
SPF говорит, какие серверы могут отправлять почту от имени домена, DKIM доказывает, что домен подписал письмо и оно не менялось, а DMARC привязывает оба к адресу From: и говорит, что делать при сбое.
Они отвечают на разные вопросы, поэтому нужны все три: Gmail и Yahoo требуют от массовых отправителей SPF и DKIM плюс запись DMARC, а RFC 9989 просит домены с p=reject подписывать DKIM, а не полагаться на SPF.
Три записи, три вопроса
| Три записи, три вопроса | SPF | DKIM | DMARC |
|---|---|---|---|
| Что доказывает | Этот сервер может отправлять почту от домена MAIL FROM | Домен d= подписал; подписанные части не менялись | From: совпадает с доменом, прошедшим SPF или DKIM |
| Где лежит | TXT у github.com | TXT у s1._domainkey.github.com | TXT у _dmarc.github.com |
| github.com сегодня | v=spf1 … ~all | 12 ключей, 6 провайдеров | p=quarantine; sp=reject |
| Переживает пересылку | Нет: IP пересылающего сервера не указан | Да, если письмо пришло без изменений | Да, благодаря выровненной подписи DKIM |
| Ломается, когда | новый сервис отправки не внесён в запись | меняется тело или подписанный заголовок | ни SPF, ни DKIM не проходят для домена From: |
Проверка SPF записиПроверка DMARC
Откройте исходное письмо и найдите заголовок DKIM-Signature: d= — кто подписал, s= — каким ключом, h= перечисляет подписанные заголовки, а bh= и b= — два хеша, которые проверяет получатель.
Вердикт получателя — отдельный заголовок, добавляемый при получении: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Страница «Показать оригинал» в Gmail (на английском) резюмирует его как «DKIM: 'PASS' with domain example.com».
В письме может быть несколько подписей, по одной на каждого подписывающего (ваш домен и ваш почтовый сервис или рассылка). Для DMARC достаточно одной действительной подписи с выровненным d=.
Подпись примера письма по тегам
v=11; a=rsa-sha2562; c=relaxed/relaxed3; d=example.com4; s=dnsrobot-sample5; t=17928331206; h=from:from:to:subject:date:message-id:mim…7; bh=fohb/a+auh1W9c…8; b=fF0aMr3Uo+mbgG…9
Authentication-Results: mx.example.net; dkim=pass header.d=example.com header.s=dnsrobot-sample
Чего-то не хватает?Предложите функцию или новый инструмент
Проверка политики DMARC и настроек выравнивания для любого домена
Проверка записей SPF и подсчёт DNS запросов по RFC 7208
Создание пары ключей DKIM прямо в браузере и TXT-записи selector._domainkey для публикации
Разбор необработанных заголовков email и отслеживание пути письма
Проверка записей BIMI, логотипов SVG Tiny PS и сертификатов VMC, и где виден логотип
Поиск записей mail exchange и данных почтового сервера