Настройка DKIM важна для надежной конфигурации отправки со своего домена. Отсутствующий, поврежденный или обрезанный ключ и неподходящий домен подписи могут ухудшить результаты аутентификации и попадание во входящие. Здесь описан рабочий порядок: создать ключ, опубликовать запись DNS, проверить ее из командной строки и найти ошибки согласования, из-за которых DMARC может не пройти даже при зеленой отметке в панели.
Для общей настройки MX, SPF, ящиков и почтовых клиентов начните со статьи создание почты со своим доменом. Если сначала выбираете платформу, поможет обзор корпоративной почты.
Большинство ошибок DKIM связано не с криптографией. Причины обычно проще: неверное копирование DNS, повторное добавление домена панелью, повреждение 2048-битного ключа или подпись доменом почтового сервиса вместо вашего. Поиск не той причины отнимает часы. Повторяемая инструкция помогает этого избежать.
Что на самом деле делает настройка DKIM
При настройке DKIM открытый ключ публикуется в DNS, а почтовый сервер подписывает сообщения соответствующим закрытым ключом. Получатель проверяет подпись, подтверждает ответственность подписывающего домена и выявляет изменения подписанных заголовков и охваченного подписью содержимого.
DKIM использует асимметричную криптографию. Закрытый ключ хранится у отправляющей системы, открытый публикуется в DNS. Исходящее письмо получает заголовок DKIM-Signature с доменом подписи (d=) и селектором (s=). Принимающий сервер запрашивает селектор в DNS и проверяет подпись по содержимому письма. Механизм определен в RFC 6376.
С февраля 2024 Google ужесточил требования для массовых отправителей. Для них нужны SPF и DKIM; как минимум один должен быть согласован с доменом видимого заголовка From для прохождения согласования DMARC. Актуальная формулировка приведена в ответах Google о требованиях к отправителям.
Технически действительная подпись не всегда решает нужную задачу. Ошибки DKIM или отсутствие согласования могут по-прежнему сопровождаться проблемами DMARC и попаданием в спам.
Что проверить до изменения DNS
Хорошая настройка DKIM начинается с определения системы, которая действительно подписывает письма. Особенно легко ошибиться при миграции, изменении пересылки и смене поставщика. Где создавать или получать записи DKIM, полностью зависит от маршрута отправки.
Сначала ответьте: кто отправляет исходящую почту этого домена?
- Если Google Workspace, создайте ключ DKIM в Google Admin.
- Если Microsoft 365, включите DKIM там.
- Если SendGrid, Mailgun или Amazon SES, аутентифицируйте домен у этого поставщика.
- Если управляемый SMTP TrekMail, используйте значения DKIM, показанные в TrekMail.
- Если TrekMail хранит ящики, а отправка идет через внешний SMTP, следуйте инструкции SMTP-поставщика по подписи и при необходимости настройте SMTP в TrekMail.
TrekMail описывает оба маршрута. Nano использует BYO SMTP, а платные тарифы могут использовать управляемый SMTP. Документация Bring Your Own SMTP содержит примеры SES, SendGrid и Mailgun. В руководстве по доставляемости указано, что управляемый SMTP подписывает почту ключом DKIM вашего домена. Это может помочь DMARC при пересылке и релеях, если подпись остается действительной и согласованной. Уточните актуальные возможности тарифа.
Пример: ящик находится в TrekMail, но исходящая почта идет через SendGrid. Подписывать должен SendGrid. Хранение ящика в TrekMail не настраивает DKIM у SendGrid автоматически.
Первое обязательное правило: создавайте ключи в системе, которая подписывает сообщение. Иначе запись может существовать в DNS, но не использоваться при отправке.
Типы записей DKIM: TXT или CNAME
Обычно настройка DKIM означает публикацию TXT с открытым ключом. Некоторые поставщики вместо этого требуют одну или несколько CNAME-записей, указывающих на размещенные у них ключи. Оба варианта допустимы. Главное: точно следовать данным отправляющего сервиса.
Классическая TXT-запись DKIM размещается по адресу:
selector._domainkey.example.comЗначение выглядит примерно так:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...Управляемые сервисы часто используют CNAME, чтобы менять ключи без новых правок DNS со стороны клиента. TXT дает прямой контроль, но требует самостоятельно обновлять запись при необходимой ротации.
| Метод | Что публикуется | Для чего подходит | Основной риск |
|---|---|---|---|
| TXT | Полный открытый ключ в DNS | Google Workspace, многие самостоятельные и прямые конфигурации поставщиков | Длинный ключ обрезан или неверно скопирован |
| CNAME | Псевдоним записи DKIM у поставщика | Управляемые платформы и упрощенная ротация ключей | Неверная цель или отсутствие одной из требуемых записей |
Частая ловушка: поле имени хоста. Для домена example.com и селектора k1 обычно нужно указать:
k1._domainkeyА не:
k1._domainkey.example.comМногие панели DNS автоматически добавляют основной домен. Полное имя в такой панели может превратиться в k1._domainkey.example.com.example.com. Запись окажется не там, где ее ищут принимающие серверы.
Справочник TrekMail необходимые DNS-записи также объясняет, что некоторые провайдеры требуют делить DKIM TXT на части в кавычках.
Пошаговая настройка DKIM в DNS
Рабочий порядок короткий: получить селектор, опубликовать запись, дождаться обновления DNS, проверить точный ответ и включить подпись, если у поставщика предусмотрена отдельная активация. Без проверки результат остается предположением.
Следуйте этой инструкции:
- Откройте сервис отправки и создайте или покажите запись DKIM.
- Точно скопируйте селектор. Не переименовывайте его без поддержки такой функции поставщиком.
- Создайте запись DNS по имени
selector._domainkey. - Вставьте полный TXT или цель CNAME без изменений.
- Установите TTL 3600, если нет других требований.
- Дождитесь обновления DNS.
- Перед рабочей отправкой проверьте через
digилиnslookup. - Включите подпись у поставщика, если в интерфейсе есть завершающий переключатель.
Пример настройки через TXT:
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."Пример настройки через CNAME:
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.Изменения DNS могут появиться быстро, но не мгновенно повсюду. Руководство TrekMail называет примерно 5 до 15 минут как частый срок, а не гарантию. Если статус не меняется, проверьте формат, дублирующие записи и имя хоста, а также TTL и кэш ответов.
Настройка DKIM и проблема 2048-битных ключей
В современных конфигурациях стоит использовать RSA-ключи длиной 2048 бит, если их поддерживают отправляющий сервис и DNS-провайдер. Они криптографически сильнее, но длиннее, из-за чего старые панели могут создавать проблемы. Обрезанный ключ особенно обманчив: запись есть, а проверка не проходит.
Документация Google также рекомендует 2048 бит при наличии поддержки, с 1024 битами как запасным вариантом для хостов, не принимающих длинные записи. На практике часто виноват не DNS, а административная панель.
Ошибки настройки DKIM с ключом 2048 бит обычно выглядят так:
- Панель незаметно сокращает значение.
- Требует частей в кавычках, но не объясняет это.
- Добавляет переносы строк внутрь Base64.
- Экранирует символы не так, как ожидает поставщик.
Если DNS-провайдер требует разделенных строк, публикуйте значение так:
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"Получатель соединяет части. Это штатное поведение. Лишние пробелы внутри самого ключа, напротив, могут нарушить проверку. Даже один неверный символ способен сделать конфигурацию неработоспособной.
При управлении множеством доменов появляется заметная эксплуатационная нагрузка. Один регистратор правильно обрабатывает длинные TXT, другой нет, третий изменяет их. Поэтому агентства часто сокращают число используемых регистраторов или переходят на ключи поставщика через CNAME, где возможно. Для многоклиентской работы общий подход описан в статье почтовый хостинг нескольких доменов.
Проверка DKIM по DNS и реальным письмам
Статус «активно» в панели сам по себе не доказывает правильность. Полная проверка означает прямой запрос публичного DNS, проверку записи и подтверждение ожидаемых домена подписи и селектора в заголовках реальных писем. Все остальное лишь часть проверки.
Сначала используйте командную строку:
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.comНужна полная запись v=DKIM1 либо части в кавычках, соединяющиеся в полный ключ. Если ответ пустой, проверьте по порядку:
- Правильный ли селектор.
- Не продублирован ли домен в поле хоста.
- Соответствует ли тип записи инструкции поставщика.
- Полное ли значение, не обрезано ли оно.
- Не закэширована ли старая запись.
Затем отправьте тестовое письмо в Gmail или другой ящик, где можно посмотреть заголовки. Найдите результаты аутентификации и строку DKIM:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...Если DNS исправен, но письма все равно плохо попадают во входящие, проверьте следующий уровень. Руководство TrekMail о попадании в спам указывает на состояние DNS, прогрев домена, качество списка и содержимое. DKIM исправляет часть аутентификации, но не создает хорошую репутацию автоматически.
Учитывайте пересылку: при ней SPF часто не проходит. Действительная и согласованная подпись DKIM во многих таких случаях позволяет сохранить успешный DMARC, если подписанные данные не изменились. Прочитайте о пересылке почты, чтобы не принять ошибку SPF при пересылке за полный провал аутентификации.
Настройка DKIM и ловушка согласования
Именно согласование часто мешает «рабочей» конфигурации DKIM. Подпись может пройти проверку, а DMARC нет, если домен подписи не соответствует видимому From и нет успешного согласованного SPF. Иногда причина в DNS, но чаще в настройках поставщика.
Типичный случай:
From: ceo@example.com
Домен подписи DKIM:d=sendgrid.net
Результат: DKIM может пройти, но согласование DMARC может не выполниться, поскольку домен подписи не согласован сexample.com.
Для массовых отправителей Google требует согласования видимого From с SPF или DKIM как минимум на уровне организационного домена. Если почтовый сервис подписывает только своим доменом, эта подпись не обеспечивает согласование DKIM для вашего домена.
В зависимости от поставщика нужная функция называется аутентификацией домена или white-labeling. Собственный Return-Path относится прежде всего к согласованию SPF и не заменяет домен подписи DKIM. Для DKIM итоговая подпись должна выглядеть примерно так:
DKIM-Signature: ... d=example.com; s=s1; ...Согласованный DKIM помогает пройти DMARC. Это важный элемент настройки, но не гарантия попадания во входящие.
Старый и новый подход к настройке DKIM
Старый подход ручной и хрупкий: каждый домен, поставщик, селектор и особенность DNS обрабатываются отдельно. Новый подход основан на стандартизации: повторяемый маршрут отправки, общие проверки DNS и одна инструкция вместо повторного поиска решения для каждого домена.
| Старый подход | Новый подход |
|---|---|
| Создавать ключи в случайных инструментах и надеяться на соответствие отправителю | Настраивать DKIM там, где работает фактический отправляющий сервис |
| По очереди вставлять TXT и ждать обращений в поддержку | По возможности использовать подпись поставщика и проверять через CLI |
| Считать каждый домен отдельным особым случаем | Использовать одну инструкцию для клиентских и командных доменов |
| Искать причины спама после провала кампании | Проверять DNS, согласование и заголовки до первой рабочей отправки |
TrekMail описывает такую модель: несколько собственных доменов в одной панели, общее хранилище вместо оплаты за каждый ящик, перенос существующих ящиков через IMAP и выбор BYO SMTP либо включенного SMTP в зависимости от тарифа. Указанная стоимость платных тарифов начинается от $3.50 в месяц; актуальные цены и возможности следует уточнить. Платформа ориентирована на команды, малый и средний бизнес, агентства и MSP, желающие снизить нагрузку по обслуживанию почты.
Если главная проблема в процессе, а не в DNS, прочитайте управление почтой клиентов. В многодоменных средах неясные обязанности часто становятся важной причиной проблем доставки.
Итоговый список проверки DKIM
Надежная настройка включает правильную систему подписи, корректное имя DNS, полный неповрежденный ключ, проверку публичного DNS и согласование для DMARC. Ошибка в любом из этих элементов ослабляет всю конфигурацию.
- Определите систему, подписывающую исходящую почту.
- Точно опубликуйте селектор и тип записи поставщика.
- Укажите
selector._domainkeyв поле хоста, если DNS-провайдер прямо не требует полное имя. - Сохраните 2048-битные ключи целиком. Делите строки в кавычках только по требованию панели DNS.
- Проверьте через
digилиnslookup. - Отправьте тест и найдите в заголовках
dkim=passи согласованныйheader.d. - Проверьте результаты DMARC после запуска.
Главное в DKIM не сложность, а точность. Чтобы сократить число зависимостей, можно стандартизировать домены и маршруты отправки в TrekMail и сделать проверки DNS видимыми в одном месте. При этом проверяйте каждый реально используемый путь отправки.
