Как проверить DKIM для писем приложения?

Рассматривайте проверку DKIM как четыре отдельных теста

Одного DNS-запроса недостаточно для полной проверки DKIM. Во-первых, убедитесь, что в письме есть поле DKIM-Signature, и определите подпись, которую собираетесь проверить. Во-вторых, получите и разберите запись открытого ключа, на которую указывает эта подпись. В-третьих, проверьте, что подписанные заголовки и канонизированное тело по-прежнему соответствуют криптографической подписи. В-четвёртых, определите, выровнен ли прошедший проверку домен подписи с видимым доменом From для DMARC. Эти уровни отвечают на разные вопросы. Опубликованная запись может не использоваться, письмо может ссылаться на отсутствующий селектор, подпись может не пройти проверку после изменения содержимого, а криптографически успешная проверка может остаться невыровненной с доменом автора. Фиксируйте каждый результат, а не показывайте один зелёный значок. Также разделяйте транспортные состояния и состояния почтового ящика: приём провайдером, приём принимающим сервером и попадание во «Входящие» не являются результатами проверки DKIM.

Начинайте с подписи реального письма

Получите исходный текст письма у контролируемого получателя, которому оно пришло обычным путём через приложение. В каждом поле DKIM-Signature зафиксируйте домен подписи `d=`, селектор `s=`, алгоритм `a=`, режимы канонизации `c=`, список подписанных заголовков `h=`, хеш тела `bh=`, данные подписи `b=` и временные метки, если они есть. RFC 6376 определяет теги домена подписи и селектора и использует их для поиска открытого ключа. Не угадывайте селектор по панели провайдера и не запрашивайте `_domainkey` без него. Письмо может содержать несколько подписей от отправителя, промежуточного узла или системы рассылок, поэтому сохраняйте результат для каждой подписи. Не вставляйте письма из продакшена в публичные сервисы проверки: исходные заголовки и тела могут раскрыть получателей, идентификаторы писем, детали маршрутизации, токены отписки и содержимое приложения. Используйте хранилище с ограниченным доступом и обезличенную диагностическую копию, если полное содержимое не нужно.

Запрашивайте точный селектор и домен подписи

Составьте DNS-имя на основе подписи в виде `<selector>._domainkey.<signing-domain>`. Если заголовок содержит `s=app2026` и `d=notify.example.test`, запросите TXT по имени `app2026._domainkey.notify.example.test`. Зафиксируйте исходное имя, резолвер, ответ, TTL и цепочку CNAME, если она есть. Разбирайте полученную запись формата «тег — значение», а не ищите в ней фрагмент текста. Запись может объявлять версию, тип ключа, ограничение сервиса, флаги, алгоритмы хеширования и данные открытого ключа. Пустое значение открытого ключа означает отзыв ключа. Различайте NXDOMAIN, пустой ответ, некорректное содержимое, неподдерживаемый алгоритм, непригодный ключ и временный сбой резолвера. После изменения повторите запрос по истечении TTL через независимый резолвер, но не считайте, что все получатели обновились сразу. Успешный DNS-ответ доказывает лишь то, что запись была возвращена в этот момент; он не доказывает, что тестовое письмо проходит проверку или что провайдер подписывает текущий трафик этим селектором.

Проверяйте заголовки, хеш тела и подпись

Проверка DKIM выполняется по правилам канонизации, объявленным в подписи. Верификатор канонизирует тело, вычисляет его хеш и сравнивает с `bh=`. Он также канонизирует подписанные заголовки, перечисленные в `h=`, включает поле DKIM-Signature так, как предписано спецификацией, и проверяет `b=` открытым ключом. Используйте поддерживаемую библиотеку верификации или доверенный результат аутентификации от получателя, а не воспроизводите эти преобразования строковыми операциями. Несовпадение хеша тела часто означает, что тело изменилось после подписания, а ошибка подписи заголовков может указывать на изменение подписанных заголовков, неверный ключ, повреждённые данные подписи или ошибку реализации. Фиксируйте, на каком этапе произошёл сбой. Проверьте, подписаны ли важные поля, такие как From, Subject, Date и Message-ID, но не придумывайте универсальную политику подписанных заголовков. Канонизация допускает определённые изменения форматирования; она не делает безопасными произвольное добавление футеров, переписывание MIME, повреждение окончаний строк или изменения при передаче.

Читайте результаты получателя в пределах его границы доверия

RFC 8601 определяет заголовок Authentication-Results и результаты DKIM: none, pass, fail, policy, neutral, temperror и permerror. Pass означает, что получатель нашёл приемлемую подпись, прошедшую проверку. Temperror может отражать условие, которое, вероятно, изменится, например временный сбой запроса ключа; permerror вряд ли исчезнет при повторной попытке без исправления. Фиксируйте указанные в результате сервис аутентификации, домен подписи, селектор и алгоритм. Доверяйте только результатам, добавленным внутри документированной границы принимающей системы, потому что отправитель может добавить поддельное поле Authentication-Results ещё до передачи. Изучайте самый верхний доверенный результат для конечной принимающей среды и учитывайте промежуточные узлы. Если разные получатели расходятся во мнениях, сравните точную версию письма, представление DNS, время проверки, поддерживаемые алгоритмы и локальную политику. Не превращайте `dkim=pass` в утверждение, что почтовый провайдер одобрил содержимое или поместил письмо во «Входящие».

Проверяйте выравнивание DMARC отдельно от прохождения DKIM

Успешная проверка DKIM аутентифицирует домен подписи в `d=`; она не требует, чтобы этот домен совпадал с видимым доменом From по RFC 5322. RFC 9989 учитывает для DMARC идентификатор, прошедший аутентификацию DKIM, только если он выровнен с доменом автора в применимом строгом (strict) или мягком (relaxed) режиме выравнивания. Например, письмо от `billing.example.test`, подписанное с `d=provider.test`, может пройти DKIM, но остаться невыровненным. Действительная подпись с `d=example.test` может быть выровнена в мягком режиме — в зависимости от вычисления организационного домена и политики. Сообщайте три поля: результат DKIM, домен подписи и решение о выравнивании. Письмо также может пройти DMARC за счёт выровненного SPF, если DKIM не прошёл или не выровнен, поэтому прохождение DMARC не доказывает, что конкретная подпись DKIM прошла проверку. Текущие рекомендации Gmail для отправителей включают требования к аутентификации и выравниванию для соответствующего трафика, но их выполнение всё равно не гарантирует ни приём принимающим сервером, ни попадание во «Входящие».

Проверяйте актуальность алгоритмов и ротацию ключей

RFC 8301 обновляет криптографические требования DKIM: подписывающие стороны обязаны использовать `rsa-sha256`, верификаторы обязаны его поддерживать, а `rsa-sha1` использоваться не должен. Он также требует ключи подписи RSA длиной не менее 1024 бит и объясняет, почему более длинные ключи предпочтительнее, когда это возможно с операционной точки зрения. Средство проверки должно определять алгоритм и помечать устаревший или непригодный ключевой материал, не утверждая при этом, что одна лишь длина ключа делает поток писем заслуживающим доверия. Процессы у провайдеров различаются. Amazon SES документирует, что Easy DKIM по умолчанию использует 2048-битные ключи, и предупреждает, что смена метода подписи без промежуточного шага может привести к периоду, когда письма не подписываются DKIM. Планируйте ротацию с двумя действующими селекторами или с документированным механизмом перекрытия провайдера, убедитесь, что новые письма используют новый селектор, сохраняйте старый открытый ключ, пока ещё может приходить задержавшаяся почта, и удаляйте его только после окончания периода перекрытия. Никогда не публикуйте закрытый ключ подписи в DNS, логах, тикетах или промптах.

Диагностируйте сбои, начиная с самого письма

Если проверка не прошла, сохраните исходное письмо и результат получателя до изменения DNS. Убедитесь, что письмо действительно отправлено ожидаемым приложением и провайдером. Если подписи нет, проверьте, включено ли подписание для этого адреса отправителя, региона, тенанта или класса писем. Если запрос селектора не удался, сравните точные значения `d=` и `s=`, DNS-зону, цель CNAME, TTL и недавнюю ротацию. Если ключ разбирается, но хеш тела не совпадает, проверьте шлюзы, футеры списков рассылки, переписывание ссылок для трекинга, MIME-преобразования, окончания строк и средства безопасности, которые могут изменять содержимое после подписания. Если криптографическая подпись не проходит при совпадающем хеше тела, проверьте изменения подписанных заголовков, несоответствие ключа и реализацию подписания. Если DKIM проходит, а DMARC нет, проверьте выравнивание, а не публикуйте тот же ключ заново. Повторите тест через контролируемых получателей после истечения соответствующего TTL или распространения конфигурации и фиксируйте доказательства для каждого класса писем, а не объявляйте весь домен исправленным по одному успешному образцу.

Ведите проверяемый журнал проверок DKIM

Для каждого контрольного письма сохраняйте нечувствительный идентификатор корреляции, систему отправки, аккаунт провайдера или рабочее пространство, видимый домен From, принимающую систему, время письма и полный результат по каждой подписи. Включайте `d=`, `s=`, `a=`, канонизацию, подписанные заголовки, имя DNS-запроса, время DNS-ответа и TTL, статус записи ключа, результат проверки хеша тела, результат проверки подписи, доверенное значение Authentication-Results, решение о выравнивании DMARC и ответственного за исправление. Храните исходные письма только там, где есть надлежащий контроль доступа и сроков хранения. Добавляйте сценарий теста: обычная отправка из приложения, миграция провайдера, ротация ключа, путь через шлюз или пересылка. Так регрессии становятся сопоставимыми, а скриншот не превращается в вечное доказательство после изменения селекторов или обработки писем. Проверяйте заново после изменений в настройке провайдера, DNS, методе подписи, маршрутизации или появления нового класса писем. Операционный дашборд должен явно показывать неизвестные и недоступные состояния, а не молча считать их успехом или провалом.

Какое место в проверке занимает SendHQ

SendHQ требует подтверждённый домен From и предоставляет события доставки. Для проверки DKIM отправьте контролируемое письмо по целевому пути приложения, изучите полученную подпись, запросите фактические значения `d=` и `s=` и отдельно зафиксируйте выравнивание. Не делайте вывод о селекторе, длине ключа, алгоритме подписи, попадании во «Входящие» или гарантии доставки только по документации продукта.

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

Источники

• RFC 6376: подписи DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8301: обновление криптографических алгоритмов и размеров ключей для DomainKeys Identified Mail (DKIM) — RFC Editor
• RFC 8601: поле заголовка Authentication-Results — RFC Editor
• RFC 9989: аутентификация, отчётность и соответствие сообщений на основе домена (DMARC) — RFC Editor
• Рекомендации Gmail для отправителей писем — Google
• Easy DKIM в Amazon SES — Amazon Web Services
• Контракт OpenAPI SendHQ — SendHQ