Что именно проверяет DKIM в холодном письме
Подпись создаётся сервером, который отправляет письмо. В заголовках появляется строка DKIM-Signature, а в DNS домена — TXT-запись с публичным ключом. Получатель находит ключ по селектору, например selector1._domainkey.company.ru, и проверяет совпадение. Если тело письма или подписанные заголовки изменили после отправки, проверка не пройдёт.
Это важно, когда письмо идёт не с корпоративного ящика вручную, а через инфраструктуру для кампании. Почтовый сервис видит не только имя в поле «От кого», но и возможность проверить домен технически. DKIM работает вместе со SPF и DMARC: один механизм не заменяет остальные.
| Ситуация | Что увидит получатель | Вывод |
|---|---|---|
| Подпись прошла | Домен подтвердил письмо | Есть один из сигналов доверия |
| Записи DKIM нет | Подлинность домена не подтверждена | Письмо не обязательно спам, но доверия меньше |
| Подпись не прошла | Ключ, содержимое или настройка не совпали | Нужна проверка отправляющего сервиса и DNS |
Как ошибка в подписи меняет результат кампании
DKIM не создаёт интерес к офферу и не исправляет нерелевантную базу. Его задача скромнее: не дать технической ошибке лишить письмо шанса на рассмотрение. В наших кампаниях мы считаем принятые письма отдельно от ответов: письмо может быть принято сервером, но остаться без диалога из-за темы, адресата или содержания.
Практический сценарий: поставщик промышленного оборудования отправляет письмо с темой «Вопрос по участку мехобработки». Внутри — два конкретных вопроса о загрузке станков и предложение прислать расчёт. ЛПР отвечает: «Пришлите, какие модели берёте в работу». Если же подпись настроена на старый домен или запись удалена при переносе DNS, тот же текст может не дойти до человека вовсе — спорить с оффером будет некому.
Перед запуском полезно проверить всю связку: домен, ящик, сервис отправки и DNS. Для этого есть проверка SPF, DKIM и DMARC; если нужен разбор инфраструктуры вместе с репутацией и маршрутами отправки, подойдёт аудит аутрича.
Три ошибки, которые ломают проверку подписи
- Добавили TXT-запись не в тот домен. Часто ключ размещают в основном домене компании, а отправка идёт с отдельного поддомена или домена для кампании.
- Подключили сервис рассылок, но не завершили подтверждение домена в его панели. Запись в DNS уже есть, а сервис подписывает письма своим техническим доменом либо не подписывает их вовсе.
- Сменили DNS-провайдера и перенесли не все записи. Сайт открывается, почта работает, но селектор DKIM остался у прежнего провайдера.
Короткая проверка перед первой отправкой
Не стоит путать DKIM с прогревом домена и ящика. Подпись — настройка идентификации. Прогрев — отдельная работа с историей и поведением ящика. Оба элемента нужны, но чинить падение подписи постепенным наращиванием объёма бессмысленно.
Где DKIM не сработает как решение
DKIM не подходит как единственный ответ на проблему «нет лидов». Он не заставит получателя открыть письмо, не найдёт ЛПР и не объяснит, почему ваше предложение полезно именно этой компании. Если письмо принято, подпись прошла, а ответов нет, искать причину нужно в списке компаний, первом сообщении и обработке входящих ответов.
Не сработает он и для домена, от имени которого вы не можете управлять DNS. Например, агентство не должно просить доступ к ключам клиента без согласованного порядка: лучше использовать отдельно подготовленный домен и фиксировать, кто владеет записями. Полную схему подготовки инфраструктуры и кампании можно собрать в email-аутриче под ключ.