DKIM-запись: селекторы, ротация ключей и диагностика

Если открываемость падает, проверяйте не только темы и ограничения измерения, но и DNS, в частности DKIM-запись. Само снижение открытий не доказывает ошибку DKIM.

SPF проверяет подключившийся IP для домена конверта, а DKIM, DomainKeys Identified Mail, похож на печать для подписанных данных. Он позволяет криптографически проверить их, но не удостоверяет личность человека или неизменность всех данных при доставке в папку «Входящие». С 2024 года Google и Yahoo усилили требования к соответствующим массовым отправителям. Отсутствие действительного DKIM может приводить к фильтрации или отказам, но не делает все письма автоматически невидимыми.

Для основателя небольшой компании настройка может быть задачей на десять минут в примере, а не гарантированным сроком. Для MSP с 500 доменами ротация, неверные селекторы и ошибки DNS являются постоянными задачами, которые могут проявиться и в пятницу в 9 вечера.

Это практическое руководство по эксплуатации DKIM: работа DKIM-записи в DNS, лимит 255 байт на строку TXT и диагностика, когда зеленая отметка ESP уже не соответствует реальной отправке.

Что такое DKIM-запись

DKIM-запись публикует открытый криптографический ключ в DNS, обычно через TXT. Получатель использует его для проверки подписи заявленного домена сервиса подписания и покрытых ею данных. Это не означает автоматического подтверждения видимого From или личности автора.

Ключ размещается по имени selector._domainkey.yourdomain.com, где selector обозначает ключ, выбранный сервисом подписания. Сокращенный пример:

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

v=DKIM1 задает версию, k=rsa алгоритм, а p= открытый ключ в Base64. Показанный фрагмент неполон и не подходит для внедрения. Соответствующий закрытый ключ защищенно хранится у сервиса подписания и никогда не публикуется в DNS. Руководство по созданию DKIM-записи объясняет поля и полный порядок действий.

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

DKIM не просто отметка безопасности. Он связывает подписанные данные с доменом сервиса подписания и позволяет проверить их целостность по заданным правилам, а не подтверждает личность и все содержимое без исключений.

Сервис подписания обрабатывает выбранные заголовки, обычно From, Subject, Date, To и Message-ID, вместе с телом по правилам каноникализации, обычно применяя SHA-256. From должен быть подписан, остальные перечисленные поля зависят от подписи. С помощью закрытого ключа формируется подпись соответствующих данных. Она помещается в DKIM-Signature и передается с письмом.

Gmail, Outlook или другой получатель выполняет, в частности, следующие шаги:

1. Читает домен сервиса подписания и селектор из DKIM-Signature.
2. Запрашивает открытый ключ по имени selector._domainkey.yourdomain.com.
3. Проверяет криптографическую подпись открытым ключом, а не расшифровывает письмо.
4. Заново вычисляет предусмотренные хеши полученных подписанных данных.
5. Сопоставляет результаты и проверяет остальные условия действительности. При успехе возможен DKIM pass, при ошибке DKIM fail.

Успех подтверждает две ограниченные характеристики: подлинность подписи относительно опубликованного ключа и целостность покрытых данных после каноникализации, с учетом объема подписи. Разрешенная нормализация не обязательно сохраняет каждый байт, и не все заголовки подписаны. Подходящий ключ делает такую проверку возможной. Механизм описан в RFC 6376, полезном и при согласовании соответствия реализации стандарту.

Пересылка и возможности DKIM

Руководитель отправляет счет корпоративному контакту, который пересылает на личный Gmail. Если исходный домен конверта сохранен, а IP посредника не разрешен его SPF, проверка может не пройти. Но DMARC не пройдет только при отсутствии как успешного выровненного SPF, так и любой действительной выровненной подписи DKIM. Спам или отказ затем зависят от правил получателя.

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

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

Поддерживаемая пересылка TrekMail может использовать SRS. Он переписывает отправителя конверта на домен пересылающего сервера и позволяет проверять его SPF, но не восстанавливает выравнивание с исходным From. Наличие DKIM и фактическую подпись проверяйте для конкретных управляемых или BYO SMTP-путей по текущей документации, не предполагайте охват всей отправки по умолчанию.

Селекторы для нескольких ключей DKIM

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

SPF допускает одну SPF-политику на проверяемое DNS-имя. DKIM позволяет размещать разные ключи под разными селекторами, например selector._domainkey.yourdomain.com. При необходимости можно иметь десять активных селекторов, по одному для сервиса, если это соответствует настройке и ограничениям провайдеров. Это не обещание неограниченных функций тарифа.

Зачем нужны разные селекторы

При использовании Google Workspace для корпоративной почты и Mailchimp для рассылок обычно разумны отдельные ключи и селекторы. Общий закрытый ключ технически возможен, но увеличивает круг доступа и область последствий компрометации. Настройте каждый сервис отдельно:

• Google Workspace: возможный селектор google, имя публикации google._domainkey.yourdomain.com.
• Mailchimp: примеры k1 или k2 и имя k1._domainkey.yourdomain.com. Сверяйте текущие значения сервиса.
• TrekMail: пример tm1 по имени tm1._domainkey.yourdomain.com. TXT или CNAME выбирайте по реальной инструкции провайдера.

При компрометации маркетинговой платформы можно отозвать ее селектор k1, не меняя намеренно ключ корпоративного Google. Но это не гарантирует отсутствие перебоев или полную изоляцию репутации. Руководство по селекторам объясняет синтаксис, выбор имен и поиск параметров, назначенных ESP.

Классическая ошибка публикации

Панель DNS автоматически дописывает домен. Вместо google._domainkey.yourdomain.com получается google._domainkey.yourdomain.com.yourdomain.com. Запись с неверным именем существует, а правильный запрос может вернуть NXDOMAIN. Прежняя отметка ESP этого не исключает. Материал проверка состояния DNS помогает найти ошибку точечным запросом, но не гарантирует мгновенной диагностики.

Длина ключа и ротация

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

RSA-ключи длиной 2048 бит

RSA на 1024 бита долго применялся широко. Google требует свою опубликованную минимальную длину и рекомендует 2048 бит при поддержке; требования Yahoo проверяйте отдельно. Старый cPanel или Postfix с 1024 битами, например до 2019 года, требует проверки, но не становится неверным только из-за возраста.

Ключ на 512 бит не соответствует современным требованиям. dkim=perm_fail с причиной «weak key» или «policy» может указывать на это, но конкретную диагностику нужно подтвердить. Подготовьте ключ на 2048 бит и переключайтесь контролируемо; не удаляйте старый открытый ключ без учета писем в пути. Текущие нормы описывают правила Google для отправителей.

Как часто менять ключи

Ежегодная ротация может быть внутренним правилом, а не универсальным обязательным минимумом. При раскрытии закрытого ключа из-за взлома, ошибки хранилища секретов или избыточного доступа нужны оперативные локализация инцидента, отзыв и замена. Злоумышленник может подписывать письма, пока ключ принимается, а не обязательно бесконечно или незаметно до разрушения репутации почтового домена.

Относитесь к закрытому ключу как к чувствительному секрету. Пять лет без проверки не должны быть стандартным подходом к рабочей системе. Защита доступа, ротация и реагирование дополняют друг друга.

Как учитывать ограничение TXT в 255 байт

При переходе на 2048 бит длина записи может удивить. Открытый ключ на 2048 бит в Base64 занимает примерно 400 символов. Но отдельная строка DNS TXT ограничена 255 байтами. Некоторые панели автоматически разделяют длинное значение, другие отклоняют его или могут обработать неверно. Нельзя утверждать, что большинство молча обрезает ключ.

Длинное значение можно разделять на строки в кавычках внутри одной TXT-записи. RFC 6376 предусматривает их соединение для проверки. Несколько отдельных TXT-ключей по одному селектору не равноценны такой схеме.

Неполный пример одной строки, не готовый рабочий ключ:

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

Принцип разделения на две строки: замените заполнители полным настоящим ключом.

( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
  "...rest_of_key_here..." )

Синтаксис ввода зависит от DNS-провайдера. Скобки относятся, например, к формату файла зоны, а веб-панель может требовать другой ввод. Материал настройка DNS у популярных провайдеров рассматривает Cloudflare, Route 53, GoDaddy и другие сервисы. Убедитесь, что опубликована одна TXT-запись.

Поддерживаемое делегирование CNAME может убрать необходимость вводить длинный ключ локально. В примере имя короче 255 символов, но CNAME подчиняется другим DNS-ограничениям и не должен сосуществовать с TXT по тому же имени. Цель управляется провайдером; кеши, соответствие ключа и безопасный переход для старых подписей все равно требуют контроля.

Проверка настройки

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

Шаг 1: Запросить опубликованное имя

В Linux/macOS используйте следующие команды. В Windows запустите nslookup из командной строки:

# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short

# Windows
nslookup -q=txt selector._domainkey.yourdomain.com

Замените selector реальным селектором ESP, а yourdomain.com своим доменом.

Проверяйте найденные данные ключа. v=DKIM1 может обозначать версию, но в TXT-записи ключа этот тег необязателен. NXDOMAIN означает отсутствие имени с точки зрения опрошенного резолвера. При NXDOMAIN проверьте селектор, полное имя, ответы авторитативных DNS-серверов и кеши. Повтор через 30 минут является примером, а не гарантией глобальной готовности.

Шаг 2: Проверить содержимое ключа

Если имя существует, а проверка не проходит, изучите реальный ответ:

dig txt selector._domainkey.yourdomain.com +short

Проверьте два аспекта:

• Обрезка: строка Base64 короче 200 символов при ожидаемом ключе на 2048 бит может указывать на неполные данные, но длина сама по себе не доказывает причину. Проверьте соединение строк и декодированный ключ.
• Изменение данных: панели могут иначе отображать или обрабатывать строку Base64, переносы, пробелы и обратные косые черты. Не любой допустимый пробел ломает ключ. Сравните фактически декодированный открытый ключ с доверенной исходной версией и отличайте экранирование отображения от реальных символов.

Шаг 3: Отправить тест и прочитать заголовки

Отправьте письмо на свой Gmail, откройте меню с тремя точками и «Показать оригинал». Найдите Authentication-Results, добавленный доверенным принимающим сервером:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
  spf=pass (...);
  dmarc=pass (...)

dkim=pass подтверждает успешную проверку конкретной подписи, не гарантируя DMARC-выравнивание или входящие. fail, neutral, perm_fail и temperror оценивайте по реализации и тексту причины: обозначения могут отличаться, а Neutral не обязательно означает поломку. Полный DKIM-гид и чек-лист первой настройки TrekMail помогают проверить связанные шаги.

Ошибки DKIM: три практических случая

Запись существует, селектор верен, DNS кажется доступным, но подпись не проходит. Нужно изучать реальные данные и этапы обработки, а не останавливаться на «должно работать».

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

Случай 1: «Body Hash Did Not Verify»

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

Возможные причины:

• Баннер внешнего отправителя: шлюз добавляет предупреждение вроде «ВНЕШНЕЕ ПИСЬМО: БУДЬТЕ ОСТОРОЖНЫ». Если данные тела изменены до проверки DKIM, подпись может стать недействительной. Исследуйте порядок правил, например в Microsoft 365.
• Юридическая приписка: шлюз добавляет уведомление на 15 строк. Если подписывание произошло раньше, изменение может нарушить хеш. При необходимости перенесите подпись после последней контролируемой модификации на шлюзе.
• Переписывание ссылок защитными средствами: Mimecast, Proofpoint и Defender for Office 365 могут заменять google.com на protect.mimecast.com/s/.... Изменения покрытого тела могут нарушать проверку с учетом каноникализации и объема подписи.

Подписывайте после последнего изменения в своей контролируемой инфраструктуре. Поздние изменения у получателя этим не предотвратить: проверку нужно проводить до модификации или учитывать конкретный поток отдельно. Реальный этап подписывания TrekMail проверяйте для своего пути, а не считайте гарантией неизменности у получателя. Дополнительная диагностика есть в документации по ошибкам отправки.

Случай 2: Выравнивание

В доверенных заголовках может быть:

dkim=pass (signature was valid)

DKIM прошел, но DMARC может не пройти. Возможная причина: отсутствие выравнивания DKIM, если нет другого действительного выровненного пути аутентификации. Попадание в спам не следует автоматически.

DMARC проверяет не только действительность подписи, но и домен из d= относительно домена Header From. Strict требует точного совпадения, relaxed может допускать общий организационный домен.

Пример:

Header From:        ceo@yourcompany.com
DKIM d= tag:        sendgrid.net

Подпись SendGrid действительна для sendgrid.net. Получатель оценивает выравнивание с yourcompany.com по домену отправителя и его DMARC-политике. sendgrid.net != yourcompany.com показывает отсутствие выравнивания этой подписи. DMARC не пройдет только при отсутствии успешного выровненного SPF и любой другой действительной выровненной DKIM-подписи.

Поддерживаемая ESP аутентификация домена или собственная подпись могут использовать подходящий DKIM-ключ, чтобы d= содержал, например, yourcompany.com вместо sendgrid.net. Возможности и значения зависят от провайдера. Изучите его инструкцию и выравнивание DMARC, не объявляя любую подпись поставщика ошибкой.

Случай 3: Старые или слабые ключи

Устаревший ключ может вызывать постоянные DKIM-ошибки. dkim=perm_fail с «policy» или «weak key» может указывать на ключ длиной 512 или 768 бит, но не доказывает точную длину. Эти размеры не удовлетворяют действующим требованиям к длине ключа. Исследуйте ответ получателя: постоянный результат DKIM не равен автоматическому постоянному SMTP-отказу.

Подготовьте пару на 2048 бит с новым селектором, опубликуйте и проверьте до переключения подписи. Старый открытый ключ сохраняйте для еще проверяемых старых писем, если инцидент не требует срочного отзыва. Ниже разобрана локальная генерация, а руководство по DKIM-генераторам помогает выстроить безопасный процесс.

Безопасное создание ключей

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

Отображение в браузере не доказывает компрометацию само по себе, например при проверяемой локальной генерации. Но неизвестный серверный сервис может сохранять или раскрывать закрытый ключ. Без обоснованного доверия не используйте такие ключи в рабочей среде. Злоумышленник может подписывать письма, пока ключ принимается, а не обязательно вечно или без признаков.

Сравнение способов генерации

На собственном защищенно управляемом сервере можно использовать OpenSSL:

# Generate the private key
openssl genrsa -out dkim-private.key 2048

# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key

# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key

Защищайте файл закрытого ключа правами доступа, не публикуйте его в DNS и не передавайте неконтролируемо. Последняя команда лишь показывает PEM открытого ключа, не удаляя обрамление автоматически. Значение DKIM требует правильной подготовки открытого ключа. Просьба прислать закрытый ключ по почте для «проверки» является серьезным сигналом социальной инженерии.

Основатели, агентства и другие операторы могут поручить генерацию надежно защищенному провайдеру. Уточняйте меры и ответственность, а не полагайтесь только на слово «управляемый».

Ручное и автоматизированное управление

Ротация делает заметной стоимость обслуживания каждой DKIM-записи. Опубликованные ключи требуют регулярного контроля. Пример ежегодного процесса:

Ручной ежегодный пример для каждого домена

1. Создать новую RSA-пару с новым селектором, например s2026.
2. Опубликовать открытый ключ по имени s2026._domainkey.yourdomain.com.
3. 48 часов являются примером запаса; проверяйте реальную публикацию и кеши используемых резолверов перед переключением.
4. Контролируемо переключить сервис подписания на новый закрытый ключ и проверить тестовые письма.
5. В примере оставлять оба открытых селектора 7 дней; реальная длительность зависит от очередей, писем в пути и срока проверки подписей.
6. Удалить старый открытый селектор после подходящего переходного срока либо обоснованного срочного отзыва.
7. Безопасно уничтожить старый закрытый ключ по правилам хранения и реагирования после завершения перехода.

Это 7 примерных шагов на домен в год. Для 50 доменов получается 350 операций, но реальный труд и устойчивость к ошибкам зависят от инструментов. Пропуск шага 5 может нарушить проверку старых писем. В шаге 6 нужно отличать нужное переходное сохранение от неоправданно долгого доверия.

Один домен обычно можно сопровождать вручную. Для 50 доменов учет, мониторинг и автоматизация помогают не пропускать ротацию. Без них пятничный инцидент возможен, но не неизбежен.

Управление DKIM в TrekMail

TrekMail предназначен для нескольких доменов, например пяти дополнительных проектов основателя или 800 клиентских доменов MSP. Возможности управления DKIM проверяйте по текущей инструкции.

Ротация через CNAME

При поддерживаемой схеме CNAME мастер может предложить такой пример. Используйте реально назначенные имена и цели:

tm1._domainkey.yourdomain.com  CNAME  tm1._domainkey.trekmail.net

Делегирование может сокращать локальные изменения DNS при ротации. Провайдер сопровождает цель, но процесс должен учитывать кеши и старые подписи; замена ключа под тем же селектором без перехода может нарушить их. Неизменный CNAME не гарантирует отсутствие простоя или необходимости контроля. Для 80 доменов централизованное управление может помогать, не отменяя все проверки.

Источник приводит Pro по $8 в месяц с 100 доменами и сравнивает 700 ручных операций в год. Проверяйте нынешние цены, ограничения и фактические трудозатраты: эта арифметика не является гарантированной экономией.

Мастер настройки DNS

Доступный мастер может готовить MX, SPF, DKIM и DMARC в одном месте и помогать проверять их. Учет источников, значения, публикация, кеши и реальные письма все равно требуют проверки. Отметка не дает универсальной гарантии. Детали описывают обязательные DNS-записи.

Фиксированные планы вместо оплаты только за пользователя

В источнике Starter указан как $3.50 в месяц, 50 доменов и 100 пользователей на домен; Pro как $8 в месяц, 100 доменов и 300 пользователей на домен; Agency как 1,000+ доменов. Это исторические условия, как и модель общего хранилища: сверяйте текущие тарифы. Много ящиков не означает неограниченное использование или отсутствие любых доплат.

Наличие DKIM, настройка и подписывание конкретных потоков могут зависеть от текущего тарифа и SMTP-модели. Проверяйте состав услуг, не выводите одинаковую аутентификацию всех путей из фиксированной цены.

Собственное управление и TrekMail

Вывод

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

Начните с подходящего RSA-ключа на 2048 бит при поддержке, верного селектора, полного содержимого TXT и выравнивания с видимым From. Затем добавьте контролируемую ротацию, подходящую DMARC-политику и доступные данные Google Postmaster Tools, которые могут быть неполными или запаздывать.

Сравнение SPF, DKIM и DMARC объясняет взаимосвязи и порядок подготовки. При текущих проблемах материал как не допускать попадания писем в спам дает исходную последовательность, которую нужно адаптировать к подтвержденным причинам.

Для многих доменов ручное управление DKIM увеличивает работу и риск ошибок. Неправильные имена, обрезанные ключи или неверная ротация могут влиять на отдельные потоки. CNAME помогает уменьшать локальные задачи, но не устраняет весь класс таких ошибок. Посмотрите тарифы или изучите бесплатный продукт: 10 доменов и отсутствие требования банковской карты являются данными источника, актуальные условия нужно подтвердить.