DKIM fail: почему подпись письма не проходит проверку

DKIM (DomainKeys Identified Mail) добавляет к письму цифровую подпись. Сервер отправителя подписывает выбранные заголовки и тело закрытым ключом, а публичный ключ размещён в DNS домена под именем селектора. Получатель находит ключ, проверяет подпись и делает вывод, что письмо отправлено с ведома владельца домена и не менялось по пути.

В заголовке письма подпись лежит в строке DKIM-Signature, где видны домен (d=) и селектор (s=). Результат проверки указывает строка Authentication-Results: dkim=pass, fail, none или neutral. Для разбора нужны именно они.

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

Третья: письмо изменили после подписания. Это делают почтовые списки, шлюзы, которые добавляют подвал, антивирусные системы, изменение кодировки, перенаправление через сервис, переписывающий ссылки. Тело перестаёт соответствовать хэшу, и проверка не проходит. Четвёртая: сервис отправки не настроен на подпись от вашего домена и подписывает собственным. Тогда подпись валидна, но домен в ней не совпадает с адресом отправителя, что важно для DMARC.

Пятая: ключ слишком короткий или отозван, либо запись ещё не обновилась в кэшах.

Возьмите исходный текст письма и найдите DKIM-Signature: запишите значения d= и s=. Затем запросите TXT-запись по имени вида селектор._domainkey.домен и убедитесь, что она есть, начинается с v=DKIM1 и содержит публичный ключ целиком.

Отправьте письмо на другой ящик у другого провайдера и сравните результат. Если pass у одного и fail у другого, вероятно, второй получатель что-то меняет в письме. Проверьте, нет ли на пути шлюза, который добавляет подпись внизу письма или переписывает ссылки.

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

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

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

Уберите модификации письма после подписи или переместите подписание в конец цепочки. Для важных доменов периодически меняйте ключ и оставляйте старый селектор до окончания переходного периода.

После исправления проверяйте результат по заголовкам живого письма, а не только по тестам.

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

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

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

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