Кто подписывает почту и кто отвечает за DNS

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

Что именно проверяет DKIM

В потоке корпоративной почты почтовый сервер может добавить к письму заголовок DKIM-Signature. Он подписывает закрытым ключом выбранные заголовки и содержимое письма; получатель берёт из подписи домен и селектор, находит соответствующий открытый ключ в DNS и проверяет подпись. Закрытый ключ не публикуют. TXT-запись с открытым ключом доступна получателям, которым нужно выполнить проверку. Это цифровая подпись, а не шифрование: содержимое письма DKIM не скрывает. В заголовке d= указывает подписывающий домен, а s= — селектор; вместе они определяют DNS-имя вида селектор._domainkey.домен. Получатель ищет открытый ключ именно по этим значениям. Нет записи, не читается формат или лежит другой ключ — подпись не подтверждается. Это точное описание результата проверки, но не прогноз папки, в которую получатель положит письмо.

Успешная проверка означает, что подписанные части письма соответствуют подписи и что подписывающий домен заявляет ответственность за сообщение. Она не удостоверяет личность автора и не доказывает, что текст безопасен. SPF проверяет отправляющий сервер, а DMARC сопоставляет результаты SPF и DKIM с доменом в From и задаёт политику обработки. Почтовый получатель применяет собственные правила, поэтому ошибка DKIM может повлиять на оценку письма, но сама по себе не означает автоматическую отправку в спам. У DKIM есть ещё одно важное ограничение: проверяется домен подписи, а не совпадение адреса From по умолчанию. Для политики DMARC такое совпадение проверяется отдельно, в режиме выравнивания доменов. Поэтому технический dkim=pass полезен, но без сопоставления с From не отвечает на вопрос, соответствует ли подпись именно видимому отправителю. Это причина читать всю строку результата, а не останавливаться на одном зелёном статусе. Если в одном письме несколько DKIM-Signature, получатель проверяет каждую отдельно. Например, один сервис может добавить подпись своего домена, а ваша система — домена организации; успешный результат первой не исправляет ошибку второй. Сопоставляйте d= и s= в каждой подписи с отдельной DNS-записью.

Облако: провайдер подписывает, DNS зависит от схемы

В облачной почте закрытый ключ обычно создаёт и хранит оператор сервиса. Это снимает с администратора часть задач: не нужно обслуживать файл ключа на собственной машине и связывать службу подписи с почтовым сервером. Но слово «облако» не отвечает на вопрос, кто меняет DNS. У одних сервисов настройка домена автоматизирована, у других администратор получает имя и значение TXT-записи и публикует их у своего DNS-провайдера. Проверяйте инструкцию именно своего сервиса, а не ждите, что запись появится сама. Обычно администратор получает точное имя записи, куда вставить ключ, и само значение; у некоторых платформ вместо TXT используют CNAME, ведущий к записи оператора. Скопируйте имя и значение без ручной правки и проверяйте их в авторитетной зоне, которой фактически пользуется домен. Панель почты может показывать «ожидает подтверждения», пока опубликована не та зона или ещё не обновились кэши. Это вопрос публикации DNS, а не генерации закрытого ключа. При сравнении облачной подписки и собственного сервера я отдельно считаю и стоимость владения — разбираю расходы на почту без подмены цены лицензии ценой всей эксплуатации.

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

• Закрытый ключ обычно у оператора сервиса
• Запись DNS настраивается по инструкции провайдера
• Уточните домен подписи и селектор
• Не рассчитывайте на экспорт закрытого ключа

Свой сервер: больше контроля, больше точек отказа

На своей инфраструктуре вы отвечаете за генерацию пары ключей, хранение закрытого, подключение подписывающего компонента и публикацию открытого ключа в DNS. Детали зависят от платформы. Например, документация Carbonio описывает хранение закрытого ключа в LDAP и публикацию открытого в DNS; у других сборок ключ может храниться в файле, доступном службе подписи. Не переносите способ хранения из одной системы в другую по аналогии: сначала сверяйтесь с документацией установленной версии. Я проверяю права не по совету из случайного примера, а по документации конкретной сборки и учётной записи службы подписи. Слишком широкие права раскрывают секрет лишним пользователям; слишком узкие не дают компоненту подписать письмо. В журнале в таком случае могут быть ошибки чтения ключа или отсутствия подходящего домена, но формулировка зависит от продукта. После изменения настройки подтвердите результат новым исходящим письмом, а не только статусом службы. В любом варианте зафиксируйте границы доступа: оператор почтового ПО, владелец DNS и специалист, который меняет настройки, могут быть разными людьми. Это не бюрократия ради галочки. При смене сотрудника или подрядчика такая запись показывает, у кого запросить публичный ключ и кто способен заменить запись, не раскрывая закрытый секрет.

Доступ к закрытому ключу ограничивают учётной записью службы, которой он нужен; резервную копию защищают так же, как сам ключ. Если ключ утечёт, злоумышленник сможет подписывать сообщения от имени домена до отзыва ключа и обновления DNS. При выборе RSA ориентируйтесь на актуальные требования стандарта: RFC 8301 требует минимум 1024 бита и рекомендует 2048. Для проверки важны не только права файла, но и то, какой селектор реально указывает отправляющая служба и соответствует ли ему TXT-запись. При подозрении на утечку ключа меняют ключ и селектор, публикуют новый открытый ключ и переключают подпись, затем выводят старый ключ из обращения. Простого удаления файла на сервере недостаточно: пока соответствующая запись доступна и подписывающая сторона использует прежний секрет, получатели могут продолжать проверять старые подписи. Заранее запишите, какие приложения хранят доступ к отправке и кому разрешено менять DNS. Это делает ротацию управляемой, а не поиском сюрпризов после инцидента. Ключ выбирают вместе с совместимостью конкретной платформы и получателей. Я не советую копировать чужой размер или алгоритм из случайного руководства: RFC задаёт минимальные требования, а установленная система должна уметь выпускать и обслуживать выбранный формат. Для большинства администраторов важнее не экзотическая настройка, а свежие пакеты, закрытый доступ к секрету и план его замены.

Селектор и DNS: как не сломать ротацию

Возьмём условную «Лагуна-Логистик» и явно обозначим это как учебный стенд, а не историю реального заказчика. Для примера зафиксирую Postfix 3.11.7, домен example.com и два селектора: laguna-a для действующей подписи и laguna-b для перехода. В контрольном заголовке есть DKIM-Signature с d=example.com и s=laguna-b, а проверка возвращает dkim=fail. Теперь я знаю, что искать: получатель запросит laguna-b._domainkey.example.com, не запись laguna-a. Версия Postfix дана для воспроизводимости сценария; причину определяют поля подписи и DNS, а не номер версии MTA.

В учебной зоне ставлю для новой записи TTL 300 секунд и публикую публичный ключ именно под именем laguna-b._domainkey.example.com. После обновления проверяю ответ DNS, затем отправляю новое тестовое письмо тем же каналом; в этом сценарии получатель видит dkim=pass. Пять минут — параметр примера, а не обещание для любого кэша: если раньше там был отрицательный ответ или другой TTL, внешний резолвер может сохранить его дольше. Итог диагностики конкретен: новый отправитель уже использовал laguna-b, но такого селектора ещё не было в DNS. Не «почта сломалась», а один недостающий шаг в переключении.

Условный кейс: разбираю сбой после переезда

Возьмём условную «Лагуна-Логистик» из этой статьи. После переноса почты сотрудник видит в тестовом письме dkim=fail и говорит: «Письма больше не работают». Это пока только симптом одной проверки. Сначала я выясняю, подписывалось ли письмо вообще, затем выписываю домен d= и селектор s= из заголовка подписи и запрашиваю именно соответствующую DNS-запись. Так быстро отделяется отсутствие подписи от неверного ключа или неправильного имени записи. Не смешивайте три исхода диагностики. Нет DKIM-Signature — отправляющая цепочка не подписала письмо. Есть подпись, но проверка не прошла — сопоставьте селектор, открытый ключ и состояние письма после отправки. Есть pass — криптографическая проверка удалась, но это не отчёт о доставке. Внешний сервис проверки полезен для видимости DNS, однако окончательным подтверждением настройки остаётся письмо, прошедшее через тот канал и приложение, которыми пользуются сотрудники. Если нужна отдельная последовательность проверок для этого симптома, вот почему DKIM не подписывает. Сначала отделяйте отсутствие заголовка подписи от ошибки её проверки — это разные места поиска.

Дальше сравниваю, каким ключом подписывает новый сервер и какой открытый ключ отдан DNS. Проверяю, не остался ли на старом канале отправки прежний подписывающий сервис, не изменяет ли письмо промежуточная система и нет ли опечатки в имени селектора. Если система выдаёт подробный журнал, сверяю его с результатом на стороне получателя. Никаких выводов про «потерянную репутацию» из одного fail не делаю: сначала нужно увидеть повторяемость ошибки и отдельно оценить доставку. В условном разборе я также отправлю отдельное сообщение напрямую и через пересылку. Если первое проходит, а второе нет, сравню подписанные заголовки и тело: почтовый список может добавить нижний колонтитул, изменить тему или переписать формат. Не всякая пересылка меняет письмо, а relaxed-каноникализация допускает некоторые нормализации пробелов; произвольное изменение подписанных данных она не исправляет. Так причина становится проверяемой, а не объясняется «плохим DNS» наугад.

• Есть ли DKIM-Signature
• Совпадают ли d= и домен отправителя
• Найден ли TXT для селектора s=
• Какой ключ использует текущий канал
• Не меняет ли письмо промежуточный узел

Проверка письма и план миграции

Начинайте с письма, реально отправленного через нужный канал. В заголовках смотрите DKIM-Signature и результат проверки, добавленный принимающей системой. Если подписи нет, ищите, почему исходящий тракт не подписал письмо; если результат fail, сверяйте домен, селектор, DNS-ключ и содержимое после отправки. Заголовок Authentication-Results помогает увидеть итог проверки, но доверяйте результату, добавленному принимающей системой: одноимённое поле можно подделать или переслать из исходного письма. Записи относятся к оценке конкретного получателя. Одна внешняя проверка DNS не доказывает, что все исходящие пути уже настроены одинаково. Для каждого источника фиксирую адрес отправителя, используемый сервис, домен из From, фактический сервер и то, кто подписывает сообщение. Особое внимание — уведомлениям сайта и приложений: они часто продолжают отправлять после переноса и подписывают другим доменом или прежним селектором. Если оставить такой канал вне списка, общий тест с почтового ящика создаст ложное чувство готовности. Переключайте маршруты по одному и сохраняйте результат проверки для каждого. По завершении зафиксируйте для каждого пути отправки его d=, s= и результат проверки; такая таблица на несколько строк полезнее общего статуса «DKIM включён». При следующем изменении она покажет, какой сервис подписывает письмо и к какой DNS-записи он привязан. Так проще проверить доставляемость после переезда без догадок и повторного аудита всей схемы.

При миграции я сначала инвентаризирую все системы, которые отправляют почту от домена: сервер, приложения, формы сайта и внешние сервисы. Затем готовлю новый селектор, публикую соответствующий открытый ключ и отдельно проверяю его доступность. После переключения отправки делаю тест с каждого канала и читаю заголовки результатов. Старый селектор оставляю на период доставки уже подписанных им сообщений; завершение перехода определяю по реальному потоку и TTL DNS, а не по универсальному обещанию «подождать три дня». Пересылка не всегда ломает подпись, но если промежуточная система меняет подписанные заголовки или тело письма, проверка может не пройти. Если планируете уменьшить TTL перед сменой записи, сделайте это заранее: новый короткий TTL не отменяет срок, который кэширующие серверы уже получили для прежнего значения. Дальше соблюдайте последовательность: опубликовать новый ключ, убедиться в доступности записи, включить подпись новым селектором, проверить реальные письма и только затем завершить старый маршрут. Старый DNS-ключ нужен не для того, чтобы «дать интернету обновиться», а для проверки писем, которые ещё идут со старой подписью. Я не удаляю старую запись сразу после первого успешного теста: письма уже могли покинуть сервер с прежней подписью и проверяться позже. Срок сосуществования выбираю по реальной очереди и времени жизни сообщений, а не подгоняю под удобный календарь. После этого удаляю старый ключ из DNS и проверяю, что ни один оставшийся канал не продолжает подписывать им. Закрытый ключ убирают из рабочего использования отдельно и по инструкции своей платформы.

Частые вопросы