Генератор записей DKIM: настройка и проверка DNS

Если вы ищете генератор записей DKIM из-за ошибок аутентификации в Gmail или Google Postmaster Tools, сначала проверьте базовую настройку. Наш материал о почте на собственном домене разбирает MX, SPF, DKIM, DMARC и ошибки DNS, способные нарушить доставку.

Веб-инструменты не всегда объясняют главное: для DKIM нужны два ключа. Открытый публикуется в DNS, закрытый остаётся в подписывающей системе. Если ключи создаются на сервере сайта, сайт получает доступ к закрытому ключу. Проверенная реализация, выполняющая всё локально в браузере, отличается от этого подхода, но без проверки ей не стоит доверять. Закрытый ключ позволяет подписывать письма от домена, а не удостоверяет личность в видимом поле From.

Здесь рассмотрены два практичных подхода к использованию генератора записей DKIM в 2025-2026: локальная генерация через OpenSSL для своего почтового сервера либо настройка по указаниям фактического провайдера отправки, например TrekMail, Amazon SES, SendGrid, Mailgun или Google Workspace.

Что такое генератор записей DKIM?

Генератор записей DKIM подготавливает данные DNS для DomainKeys Identified Mail. Это может быть пара ключей RSA с публикацией открытого ключа в TXT либо, если провайдер поддерживает делегирование, записи CNAME, ведущие к опубликованному у него ключу.

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

Согласно RFC 8301, при RSA-подписи нужно использовать rsa-sha256, ключ не короче 1024 бит, а рекомендуемая длина составляет не менее 2048 бит. Поэтому подходящий генератор записей DKIM должен ориентироваться на RSA 2048, а не 1024. Это требование к RSA не исключает других поддерживаемых алгоритмов DKIM.

Чем опасны непроверенные веб-генераторы

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

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

Открытый ключ публикуется в DNS, закрытый хранится в подписывающей системе. Если веб-форма выдаёт оба, проверьте, где они создаются и передаётся ли закрытый ключ сервису.

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

Локальная генерация через OpenSSL

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

Этот метод подходит для Postfix, Exim, Exchange, OpenDKIM и других самостоятельно обслуживаемых систем. Создайте ключ локально, установите закрытый ключ на подписывающий узел, а в DNS опубликуйте только открытый.

Создайте пару ключей RSA длиной 2048 бит:

openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key

Файл public.key будет иметь такую структуру; сокращённый ключ здесь показан только для примера:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr...
-----END PUBLIC KEY-----

Подготовьте содержимое:

Удалите строки BEGIN PUBLIC KEY и END PUBLIC KEY.
Удалите все переносы строк.
Добавьте теги DKIM.

Обычная запись TXT выглядит так; вместо сокращённого примера нужен полный собственный открытый ключ:

default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."

Самого ключа недостаточно. Генератор записей DKIM должен выдавать корректную запись: v=DKIM1 при наличии должен стоять первым, хотя этот тег необязателен; p= обязателен. Дополнительные теги s=email и t=s существуют, но для базовой настройки обычно не нужны.

Ограничение DNS: 255 октетов

Ограничения длины в панелях DNS могут испортить результат генератора записей DKIM. Открытый ключ RSA длиной 2048 бит занимает много места. Некоторые панели требуют разделить значение TXT на строки в кавычках внутри одной записи.

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

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

default._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArFirstPart"
  "SecondPartOfTheSamePublicKey"
)

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

Настройка провайдера вместо ручного управления ключами

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

Для TrekMail, Amazon SES, Google Workspace, SendGrid и Mailgun следуйте указаниям фактического отправителя. При CNAME-делегировании вы публикуете селекторы, а провайдер размещает DKIM TXT на целевом узле. Если он выдаёт TXT, используйте именно TXT.

Задача	Самостоятельное управление	Управление провайдером
Создание ключей	Вы создаёте и храните ключи RSA	Ключами управляет провайдер
Запись DNS	Длинное значение TXT	CNAME к селектору провайдера, если предусмотрено
Замена ключей	Нужно планировать и выполнять вручную	По процедуре провайдера
Причины ошибок	Синтаксис, обрезанный ключ, устаревшие ключи	Ошибки DNS, отсутствующие записи или настройка отправки
Кому подходит	Собственные MTA	Облачная почта и SMTP-сервисы

В TrekMail предусмотрен процесс настройки с проверками DNS. Но выбирать TXT или CNAME следует по реальной конфигурации отправки, а не по общему предположению. При добавлении домена начните с актуальных указаний в разделе «Добавление домена».

Настройка зависит от способа отправки. Nano использует собственный SMTP для исходящих писем; соответствующие платные тарифы могут включать управляемый SMTP. В качестве ценового ориентира указан Starter от $3.50/месяц. Для платных тарифов может действовать 14-дневный пробный период с обязательной кредитной картой. Nano предлагается без такого пробного периода и без карты. Уточните актуальные условия.

Для пользователей TrekMail выбор генератора записей DKIM зависит от пути отправки:

Если TrekMail подписывает письма через управляемый SMTP, используйте записи DNS из панели.
При собственном SMTP провайдер ретрансляции может подписывать письма, если это настроено. Публикуйте фактически необходимые записи DKIM этого провайдера.
Если провайдер выдаёт CNAME-селекторы, используйте их. Не заменяйте их TXT из-за общей инструкции в блоге.

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

Где публиковать селектор

Генератор записей DKIM подготавливает запись не для корня домена. Ключ запрашивают под именем селектора, например default._domainkey, google._domainkey или tm1._domainkey.

Панели DNS работают по-разному: одни ждут относительное имя, другие полное. Если панель сама дописывает зону, ввод полного имени может дать default._domainkey.example.com.example.com. Под таким ошибочным именем получатель не найдёт нужный ключ.

Типичные относительные имена:

default._domainkey
selector1._domainkey
tm1._domainkey

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

Как проверить результат генератора записей DKIM

Дополните положительный статус в панели прямым запросом DNS. Результат генератора записей DKIM можно проверить с помощью dig по селектору и самостоятельно изучить ответ.

Начните с прямого запроса:

dig txt default._domainkey.example.com +short

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

dig txt default._domainkey.example.com @8.8.8.8 +short

На что обратить внимание:

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

Если проблемы с Gmail остаются, проверьте актуальные требования Google для массовых отправителей к SPF, DKIM и DMARC. Ошибки DKIM могут способствовать ограничениям, но не обязательно означают ошибку DMARC при успешном выровненном SPF. Действующие подробности есть в ответах Google на вопросы о требованиях к отправителям.

Пользователям TrekMail также стоит проверить фактический путь отправки. Справочник настроек IMAP и SMTP поясняет собственный SMTP на Nano и TrekMail SMTP в соответствующих платных тарифах. Если при корректном DNS письма попадают в спам, пройдите инструкцию «Мои письма попадают в спам».

Итог: настройте DKIM под свою почтовую архитектуру

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

При собственном MTA используйте локальный OpenSSL и защищайте закрытый ключ как рабочие учётные данные. Для TrekMail, SES и других провайдеров следуйте их конкретным указаниям, а не вставляйте непроверенные ключи из веб-формы ради исчезновения предупреждения.

Согласованная настройка, управляемая аутентификация и понятная проверка могут сократить ручные ошибки. Это особенно полезно при нескольких брендах, клиентских доменах или текущей миграции. Если инфраструктура ещё создаётся, прочитайте о пересылке почты домена в Gmail, затем сравните тарифы TrekMail.

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