Почему письмо из Outlook не проходит DKIM-проверку

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

Где появляется DKIM-подпись письма из Outlook

Outlook готовит сообщение и передаёт его почтовому сервису или серверу отправки. DKIM-подпись обычно добавляет уже этот узел: почтовый шлюз, облачная служба или исходящий MTA, у которого есть закрытый ключ домена. Поэтому, если нужна помощь с корпоративной почтой, я сначала выясняю, какой именно сервис принимает отправку из Outlook и куда он передаёт письмо дальше. Подпись не возникает от того, что в клиенте выбрали правильный адрес или перезапустили программу. Я разбираю именно такой маршрут, когда мы настраиваем корпоративную почту.

Слово «подпись» здесь сбивает с толку. Outlook умеет работать с пользовательской цифровой подписью S/MIME, но она служит другой задаче: подписать сообщение сертификатом конкретного человека. DKIM — доменная подпись в заголовках письма, которую создаёт отправляющая почтовая инфраструктура. Одна не заменяет другую. Если в Outlook письмо выглядит «подписанным», это ещё не говорит, что получатель увидит успешный DKIM.

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

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

Что проверять в Exchange и гибридной почте

Под словом Exchange часто смешивают разные варианты: локальный Exchange Server, Exchange Online и гибридную схему. Настройка DKIM, которую Microsoft документирует для Exchange Online, относится к облачной службе и домену, подключённому в ней. Её нельзя автоматически переносить на локальный сервер. Для локальной установки важно отдельно установить, какой транспорт выпускает письмо наружу и где в этой схеме выполняется доменная подпись. Фраза «у нас Exchange, значит DKIM включён» ничего не доказывает.

В гибридной почте я строю маршрут отдельно для каждого отправителя или потока: из какой среды ушло письмо, прошёл ли трафик через шлюз и какой узел последним передал его внешнему получателю. Затем сравниваю этот путь с DNS-настройкой DKIM именно того сервиса, который должен подписывать сообщения. Не надо угадывать, что облако ждёт подпись от локального сервера, а локальный сервер — от облака. Это проверяется по заголовкам Received и журналам отправки.

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

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

• Разделите Exchange Server и Exchange Online.
• Зафиксируйте внешний маршрут исходящего письма.
• Проверьте, какой узел добавляет DKIM-Signature.

Условный кейс: студия «Уран-Трейд»

Возьму студию «Уран-Трейд» как условный пример, а не как описание реального клиента. Сотрудник отправляет письмо из Outlook, партнёр сообщает о спаме, и команда уже собирается переустанавливать почтовый клиент. Я прошу сохранить исходное письмо, доставленное получателю, и посмотреть не на экран Outlook, а на заголовки и фактический маршрут. Если копия у отправителя и копия у получателя различаются, это тоже подсказка: между ними есть узел, который надо включить в проверку.

Допустим, получатель записал dkim=none. Это означает, что его проверка не обнаружила применимой подписи в полученном сообщении; это не диагноз конкретной неисправности на сервере отправителя. Подпись могла не добавиться, могла исчезнуть по пути, либо проверялся другой поток, чем предполагал администратор. Я сверяю заголовок DKIM-Signature, записи Received и журналы исходящего шлюза. Если же результат dkim=fail, подпись в сообщении была, но проверка не прошла; искать нужно уже ключ, DNS, изменение сообщения или соответствие подписывающего домена.

Второй пример — неверное имя DNS-записи. default само по себе не является универсальным именем DKIM-записи: имя строится из селектора и домена, например default._domainkey.example.com, если именно такой селектор указан в подписи. Но селектор может называться иначе, а облачный сервис иногда просит опубликовать CNAME. Поэтому я не копирую слово default из чужой инструкции. Беру значения из подписи и документации того сервиса, который выпускает письмо. Для общего чек-листа диагностики пригодится материал почему DKIM не подписывает.

В этом условном разборе я не назначаю виноватого по одному симптому. Сначала фиксирую результат принимающей стороны, затем проверяю запись для селектора из письма и только после этого изучаю путь через серверы. Если DNS-запись правильная, но заголовка подписи нет, возвращаюсь к исходящему узлу; если заголовок есть, но проверка провалилась, проверяю опубликованный ключ и то, менялось ли сообщение после подписи. Такая последовательность отделяет отсутствие подписи от невалидной подписи — две разные неисправности с разными владельцами.

Как проверить подпись и DNS-запись

Отправьте одно тестовое письмо на внешний ящик, к которому у вас есть доступ, и откройте исходные заголовки именно полученной копии. Ищите Authentication-Results от принимающей стороны и отдельно DKIM-Signature. По RFC 8601 результат dkim=none означает, что сообщение не подписано, dkim=pass — что подпись прошла проверку и принята политикой получателя, а dkim=fail — что подпись была, но проверка не прошла. Если нужной строки нет, не делайте вывод по её отсутствию в одном просмотрщике: разные клиенты по-разному показывают заголовки.

В заголовке DKIM-Signature нужны значения s= и d=: это селектор и подписывающий домен. Для стандартной DNS-проверки подставьте их в имя селектор._domainkey.домен; пример команды для условного домена: dig +short TXT selector._domainkey.example.com. Значение selector замените тем, что нашли после s=, а example.com — доменом из d=. Если ваш провайдер выдал CNAME для ключа, запросите именно CNAME и сравните его с инструкцией провайдера. Пустой TXT-ответ сам по себе не объясняет причину: проверьте правильность имени, DNS-зону и то, какие записи ожидает отправляющий сервис.

Не путайте три разных результата. Наличие DKIM-Signature говорит только о том, что подпись вложена в письмо; успешный DKIM у получателя говорит, что она прошла проверку; совпадение домена подписи с адресом в From важно для DMARC. Письмо может иметь dkim=pass, но не пройти DMARC alignment, если подписал его посторонний домен. Я сохраняю полный заголовок, потому что обрезанный скриншот скрывает значения d=, s= и результат, без которых диагностика превращается в гадание.

Если читаете письмо в Outlook, найдите команду просмотра свойств или исходных заголовков в своей версии клиента; названия меню меняются. Надёжнее также сравнить представление с исходником у принимающего почтового сервиса. При проверке не публикуйте полный заголовок в открытом доступе: в нём могут быть адреса, служебные узлы и внутренние имена. Для диагностики достаточно передать их администратору по согласованному каналу.

У письма иногда бывает больше одной DKIM-Signature: например, его подписали разные сервисы или повторно обработал шлюз. Поэтому читайте весь блок Authentication-Results, а не только первое встретившееся слово fail. Принимающая система может сообщить результаты отдельно для разных подписей; одна действительная подпись может пройти, хотя другая не прошла проверку. Для DMARC дополнительно важно, какая из успешных подписей относится к домену в From. Сохраните все значения d= и s= — тогда можно проверить каждый ключ отдельно и не списывать исправную подпись из-за соседней.

• Сверьте `dkim=...` в Authentication-Results.
• Сопоставьте `s=` и `d=` с DNS.
• Проверьте, изменялось ли письмо после подписи.

Postfix и OpenDKIM: где искать разрыв

В связке Postfix и OpenDKIM важны три вещи: демон подписания запущен, Postfix обращается к его milter-интерфейсу, а у демона есть доступ к правильному закрытому ключу. Названия сокетов и пути зависят от конкретной установки; opendkim.sock не является обязательным путём для всех. Я смотрю фактическую конфигурацию обеих служб и сверяю её с владельцем процесса и правами на каталоги. Дать универсальную команду с chmod здесь опасно: она может открыть закрытый ключ лишним пользователям или, наоборот, отрезать доступ самому подписывающему демону.

Postfix различает SMTP-поток и сообщения, поступающие к нему локально: для Milter предусмотрены параметры smtpd_milters и non_smtpd_milters. Поэтому проверяйте тот путь, по которому уходит конкретное письмо. Команда postconf -n | grep -i milter покажет заданные параметры Postfix, если они есть в активной конфигурации. Затем сопоставьте адрес milter с тем, что настроено у OpenDKIM. Наличие пакетов и работающий процесс ещё не означают, что именно этот поток проходит через подписывающий фильтр.

С закрытым ключом принцип такой: он должен быть защищён от посторонних процессов и одновременно читаться службой, которая подписывает письмо. Проверяйте фактического пользователя демона, владельца ключа и права каждого родительского каталога. Если журнал сообщает об ошибке ключа или соединения, фиксируйте точное сообщение и время тестовой отправки, затем сопоставляйте их с логами MTA и OpenDKIM. Универсальная строка no key for signature не является достаточным диагнозом; формулировки и причины зависят от версии и конфигурации. Отдельный разбор доступа к DKIM-ключу есть в статье как восстановить доступ к ключу.

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

• Проверьте путь письма до Milter.
• Сверьте сокет и права службы.
• Подтвердите соответствие ключа и селектора.

DKIM проходит, а письмо всё равно в спаме

Успешный DKIM — не билет во «Входящие». Он подтверждает проверку подписи определённого домена и целостности подписанных частей сообщения, но фильтр оценивает и другие сигналы. SPF и DMARC дополняют картину, однако правила обработки задаёт принимающая сторона. Неверно утверждать, что любой сбой SPF автоматически отклонит письмо: итог может отличаться у разных получателей и зависит от политики домена и локальных фильтров.

Я проверяю, совпадает ли домен DKIM с доменом в From настолько, насколько требует политика DMARC, и перечислены ли реальные отправляющие сервисы в SPF. Затем смотрю, не меняет ли письмо шлюз, не добавлен ли новый сервис рассылки и что пишет принимающая сторона в Authentication-Results. Если все проверки аутентификации проходят, это не доказывает хорошую репутацию отправителя и не гарантирует доставку в нужную папку. Путь доставки и репутацию нужно разбирать отдельно; общий порядок такой проверки есть в материале как проверить SPF, DKIM и DMARC.

Проверяйте результат у конкретного получателя и для конкретного письма. Если один сервис принимает почту, а другой кладёт её в спам, сравните их заголовки, коды ответа и требования отправителя. Массовая рассылка, неожиданное содержимое, объём, частота и жалобы пользователей могут влиять на решение фильтра даже при корректной подписи. Не обещайте себе, что одна DNS-запись исправит доставляемость целиком. Я сначала устраняю подтверждённые ошибки аутентификации, а потом разбираю отдельные причины фильтрации.

Для DMARC проверяйте не только факт pass, но и домен, который прошёл аутентификацию. DMARC может пройти через выровненный SPF или через выровненный DKIM; оба механизма не обязаны одновременно дать pass. Обратная ситуация тоже встречается: DKIM технически верен, но подписывающий домен не совпадает с From по выбранному режиму выравнивания, и DMARC не засчитывает эту подпись. Поэтому сохраните значения smtp.mailfrom, header.from и header.d из отчёта получателя и проверьте, какой механизм прошёл и с каким доменом. Это уже проверка согласованности идентичностей, а не наличия DKIM-ключа.

• Сверьте результаты у двух получателей.
• Проверьте DMARC alignment и SPF отправителей.
• Отделите ошибку DKIM от фильтрации.

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