DKIM fail: проверка ключей, DNS и пути отправки

DKIM fail означает неудачную проверку подписи, а не окончательный вывод о доверии к письму. Такой результат может повлиять на приём и фильтрацию, но сам по себе не определяет доставку. Для согласованной настройки SPF, DKIM, DMARC, маршрутизации и ящиков начните с нашего материала о почте для бизнеса.

У отправителя письмо выглядит обычным. Но Gmail, Microsoft или Yahoo показывает dkim=fail. В зависимости от остальных проверок и правил получателя возможны спам, временные ограничения или отказ. Причина не всегда очевидна: DNS, отправляющая система или защитный шлюз, который изменяет письмо после подписи.

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

Что на самом деле означает dkim fail?

DKIM fail означает, что получатель не смог успешно проверить криптографическую подпись письма. Возможны изменения тела или подписанных заголовков, несовпадение ключей и другие ошибки обработки. Отсутствие ключа и сбой DNS могут дать отдельный постоянный либо временный результат; их важно различать.

RFC 6376 определяет, среди прочего, хеш тела в bh= и подпись заголовков в b=. Неудачная проверка не обязательно означает подделку. Возможно, письмо подписали до последующих изменений или опубликовали ключ, не соответствующий отправителю.

DKIM можно сравнить с контрольной пломбой на посылке. Несовпадение означает, что проверка не удалась, но ещё не объясняет причину и не даёт полного заключения о содержимом.

Начните с заголовка Authentication-Results проблемного письма. В нём указано точное заключение проверки, иногда с пояснением. Следующий пример показывает поля диагностики, но не является согласованной обычной ситуацией: успешный SPF для того же выровненного домена обычно обеспечил бы успешный DMARC.

Authentication-Results: mx.google.com;
  dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
  spf=pass smtp.mailfrom=example.com;
  dmarc=fail header.from=example.com

Если сначала нужно проверить записи домена, сравните их с обязательными записями DNS TrekMail.

Четыре типичных класса проблем DKIM

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

Результат аутентификации	Возможное значение	Что проверить сначала
`dkim=fail (body hash did not verify)`	Подписанная часть тела не совпадает после каноникализации	Исходящие реле, подписи внизу, замена ссылок, каноникализация
`dkim=fail (signature did not verify)`	Ключи не совпадают либо изменены подписанные заголовки	Селектор, замена ключей, отправитель, обработка заголовков
`dkim=permerror (no key for signature)`	Не найден пригодный открытый ключ	Имя селектора, доступность DNS, формат записи
`dkim=temperror`	Временная проблема запроса DNS	Авторитетный DNS, TTL, доступность серверов имён

Таблица помогает сузить поиск. Конкретную причину нужно подтвердить проверками.

Класс ошибки 1: несовпадение хеша тела

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

RFC 6376 описывает неудачную проверку, если пересчитанный хеш тела не совпадает с bh=. Частая причина состоит в изменениях после подписи, но также нужно учитывать обработку сообщения.

Распространённые причины:

Microsoft 365, Exchange или защитный шлюз добавляют юридическое уведомление после подписания.
Mimecast, Barracuda, Proofpoint и похожие фильтры переписывают ссылки.
Ретранслятор меняет пробелы или окончания строк за пределами допуска каноникализации.
Приложение подписывает письмо до того, как шлюз изменит границы MIME или добавит отметку [External].

Проверьте c=. Значение c=simple/simple задаёт более строгую обработку, чем мягкая каноникализация. Мягкая каноникализация тела по RFC 6376 игнорирует завершающие пробельные символы и объединяет последовательности пробелов внутри строк. Это помогает с некоторыми изменениями форматирования, но не исправляет содержательные изменения.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=example.com; s=tm1; h=from:to:subject:date:mime-version;
 bh=...; b=...

Проверьте расположение подписывающей системы: по возможности подписывайте после всех изменений, на последнем контролируемом вами этапе отправки. Это сокращает внутренние нарушения подписи, но не защищает от дальнейших изменений во внешних системах.

Для пересылки полезны материалы о настройке пересылки почты и о пересылке доменной почты в Gmail. Прямой тест может проходить, хотя реальный путь через пересылку нарушает аутентификацию.

Класс ошибки 2: несовпадение селектора или ключа

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

Найдите домен и селектор в заголовке:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...

Запросите именно этот селектор:

dig txt k1._domainkey.example.com +short

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

Например, приложение отправляет через SES, поддержка через Microsoft 365, а рассылки через другой ESP. Изменение общего селектора при продолжающейся подписи старым ключом приводит к ошибкам только у части сообщений.

Для управляемого пути TrekMail проверьте Managed TrekMail SMTP и фактическую работу подписи на выходе. Для Nano или другого отправителя изучите собственный SMTP (BYO): TrekMail выступает SMTP-клиентом, а подпись должна быть настроена у действительного отправителя.

Класс ошибки 3: длинный ключ в DNS

Некорректная публикация открытого ключа может нарушить проверку, например если панель DNS неправильно сохранила 2048-битный ключ. Возможны permerror, ошибка формата или ответ с неполным ключом.

RFC 8301 требует ключи RSA не короче 1024 бит и рекомендует не менее 2048 бит. Не стоит отказываться от рекомендуемой длины из-за панели: сначала разберитесь с её правилами ввода.

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

; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
  "restOfThePublicKeyContinuesHere..."
)

Проверьте все строки одной записи TXT, а не только первый фрагмент:

dig txt k1._domainkey.example.com +short

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

Класс ошибки 4: пересылка, ретрансляторы и выравнивание

Пересылка может нарушить SPF, а изменения подписанных данных также нарушить DKIM. DMARC завершится ошибкой, если не останется другого успешного выровненного результата аутентификации. Решение о доставке дополнительно зависит от получателя.

Предположим, письмо от example.com поступает в университет и пересылается в Gmail. SPF может не пройти для сервера пересылки. DKIM может сохраниться, если подписанные данные не меняются с учётом каноникализации. Добавление нижней подписи, замена ссылки или изменение подписанной темы может нарушить DKIM. Без другой успешной выровненной проверки DMARC тогда не пройдёт.

Для обычных прямых отправителей в личные ящики Gmail Google требует SPF или DKIM. Для массовых отправителей нужны SPF и DKIM, а также DMARC с выравниванием хотя бы через один успешный путь. Для пересылки и списков рассылки рассматривается ARC. Он может передать сведения об исходной аутентификации, но доверять им или нет решает получатель.

Важны также SRS и продуманная маршрутизация. SRS помогает проверять SPF для переписанного адреса отправителя в конверте, но не восстанавливает выравнивание SPF с исходным From. Уточните поддержку SRS в TrekMail и настройки конкретной пересылки. SRS не заменяет DKIM и выравнивание DMARC.

При большом числе псевдонимов полезны материалы о пересылке через почтовый псевдоним и создании почты на своём домене. Причина непонятных ошибок DKIM может скрываться в пути пересылки, а не в самом имени псевдонима.

Последовательная диагностика dkim fail

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

Откройте исходное письмо и найдите Authentication-Results. Запишите точный результат DKIM.
Найдите теги d=, s= и c= в заголовке DKIM-Signature.
Запросите селектор через dig. Проверьте имя selector._domainkey.example.com.
Установите, какая платформа действительно подписывает. Разные отправители могут давать разные результаты.
Проверьте изменения тела и подписанных заголовков шлюзами, фильтрами и пересылкой.
Проверьте выравнивание: домен d= должен быть выровнен с видимым доменом From:, чтобы DKIM обеспечивал успешный DMARC.

Копирование фрагментов в сторонний проверяющий сервис может изменить формат и создать ложные ошибки хеша тела. Используйте полное исходное письмо или экспортированный файл .eml.

Как согласованный путь отправки TrekMail помогает диагностике

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

Проблемный подход	Контролируемый подход
Внутренние узлы меняют письмо после подписи	Подпись после изменений на последнем контролируемом этапе
Ручная замена ключей в нескольких инструментах	Подпись и обслуживание ключей по процедуре управляемого SMTP
Произвольные правки DNS с дубликатами SPF или неверными именами DKIM	Согласованная схема и проверка каждой записи
Пересылка без учёта SRS и ARC	По возможности сохранять аутентификацию и учитывать решение получателя

TrekMail предлагает Nano как бесплатный тариф с собственным SMTP. Платные тарифы предлагаются от $3.50 в месяц с управляемым SMTP. Выбирайте фактического отправителя в соответствии с нужным способом управления ключами. Если отправляет SES, SendGrid или Mailgun, проверяйте DKIM у него. Для платных тарифов может действовать 14-дневный пробный период с обязательной кредитной картой. Актуальные цены, функции и условия смотрите в тарифах TrekMail.

При собственном SMTP проверяйте весь путь отправки. Селектор, ключ и изменения после подписи стоит исследовать в первую очередь, но по одному результату DKIM нельзя окончательно исключить другие проблемы.

Итоговый список проверок при dkim fail

Рассматривайте DKIM fail как конкретный результат проверки. Прочитайте подробности, проверьте селектор и путь подписи и только после обоснованной диагностики меняйте настройки.

Перед изменениями рабочей системы:

Прочитайте весь заголовок аутентификации, а не только краткий текст возврата.
Различайте ошибку хеша тела, подписи, permerror и temperror.
Запросите точный селектор в DNS.
Проверьте полный ключ и корректное оформление строк TXT.
Если внутренние системы изменяют письмо, перенесите подпись после этих изменений.
Оцените пригодность c=relaxed/relaxed, не ожидая защиты от содержательных изменений.
Проверьте выравнивание DMARC между d= и видимым доменом From:.

Если ошибки продолжаются, последовательно исследуйте подписывающую систему, селектор и изменяющие письмо ретрансляторы. При временной ошибке DNS полезна повторная проверка; постоянная ошибка настройки требует подходящего исправления.