руководство · настройка dkim

Как продуктовой команде безопасно настроить DKIM?

Чтобы настроить DKIM, выберите домен подписи, которым владеет организация, и уникальный селектор для каждого провайдера или системы подписания, сгенерируйте пару ключей в защищённом сервисе, опубликуйте только открытый ключ по адресу selector._domainkey.example.com и настройте фактический путь исходящей почты так, чтобы подписывалось каждое предназначенное для этого письмо. Проверьте подпись по исходным байтам письма из внешнего почтового ящика, убедитесь, что домен d= выровнен с видимым доменом From, если от этого зависит DMARC, а затем внедряйте постепенно. Задокументируйте владельцев селекторов, ротацию, отзыв и откат до того, как переводить трафик продакшена.

Составьте карту всех реальных исходящих путей до генерации ключа

Начните с инвентаризации, а не с DNS-записи. Перечислите каждую систему, которая может отправлять почту с видимых доменов From организации: воркеры приложений, провайдеры транзакционной почты, маркетинговые платформы, инструменты поддержки, системы идентификации, ПО для тикетов, релей и аварийные пути. Для каждой зафиксируйте владельца, классы писем, отправителя конверта, видимый домен From, текущий домен DKIM d=, селектор, компонент подписи и то, изменяет ли другое реле письмо после этого. Ключ DKIM, опубликованный для одного провайдера, ничего не даёт для другого пути, который никогда не использует его закрытый ключ. Аналогично общая панель управления провайдера с одним подтверждённым доменом не доказывает, что подписаны все тенанты, регионы, потоки, шаблоны или резервные варианты. Используйте контролируемые образцы каждого пути и сохраняйте их исходные заголовки. Решите, какие пути авторизованы, до включения подписи; DKIM аутентифицирует ответственность домена за подпись, а не согласие получателя или достоверность содержания письма.

Выберите домен подписи, поддерживающий выравнивание DMARC

Тег DKIM d= определяет домен подписи. Выберите домен, который организация контролирует и сможет администрировать на протяжении всей жизни потока писем. Если DMARC будет опираться на DKIM, домен d= должен быть выровнен с доменом в видимом поле From по RFC 5322 согласно применимому мягкому (relaxed) или строгому (strict) правилу выравнивания. Домен подписи, принадлежащий провайдеру, может дать успешный результат DKIM, но при этом остаться невыровненным с доменом From организации. Решите, должен ли каждый поток подписывать корневой домен или поддомен под конкретную задачу, учитывая владение, разделение репутации, делегирование DNS и изоляцию инцидентов. Не создавайте дополнительные домены лишь для того, чтобы обойти проблему с репутацией или политикой. Зафиксируйте связь с организационным доменом и планируемый режим DMARC. Проверяйте выравнивание по заголовкам итогового полученного письма; никогда не делайте выводов о нём только по запросу селектора, потому что письмо может использовать другое значение d=.

Распределяйте селекторы как операционные идентификаторы

Селектор позволяет домену публиковать несколько ключей и менять их без замены одной глобальной записи. Создайте детерминированную политику селекторов, которая определяет провайдера или подписанта и поколение ротации, не раскрывая секреты. Например, product-a-2026q3 может быть понятнее default, но соблюдайте соглашения DNS и ограничения ваших инструментов. Никогда не используйте один закрытый ключ повторно для несвязанных провайдеров, сред или тенантов лишь ради сокращения DNS-записей. Ведите реестр с селектором, доменом d=, назначением, сервисом подписи, владельцем, временем создания, алгоритмом, отпечатком открытого ключа, состоянием развёртывания, сроком ротации и свидетельствами вывода из эксплуатации. До публикации проверьте точное имя селектора: запрос имеет вид `selector._domainkey.signing-domain`. Случайная запись в видимом домене From, домене return-path или неверной зоне DNS не подтвердит нужную подпись. Не удаляйте старый селектор, пока не истечёт время задержанных писем и повторов, подписанных им.

Сгенерируйте и защитите закрытый ключ

Генерируйте пару ключей внутри управляемого сервиса ключей или строго контролируемой системы подписания, если провайдер это поддерживает. Закрытый ключ никогда не должен попадать в публичный DNS, систему контроля версий, браузерный код, вывод CI, аналитику, обычные логи, тикеты, документы, промпты или общие чаты. Предоставляйте доступ к подписанию только тому почтовому компоненту, которому нужен ключ, отделяйте продакшен от нижних окружений и фиксируйте административный доступ. RFC 8301 обновляет криптографические требования DKIM: подписывающие стороны обязаны использовать ключи RSA длиной не менее 1024 бит и должны использовать ключи длиной не менее 2048 бит; в нём также отмечены операционные ограничения DNS для более длинных ключей. Ориентируйтесь на текущие возможности и рекомендации выбранной подписывающей системы и получателей, а не копируйте устаревший пример. Если рассматривается Ed25519, его использование в DKIM определяет RFC 8463, но совместимость нужно протестировать и при необходимости сохранить совместимую стратегию подписания. Ротация должна быть возможна без экспорта закрытого ключа.

Точно опубликуйте открытый ключ

Опубликуйте TXT-запись с точным именем владельца `selector._domainkey.signing-domain`. Запись ключа DKIM содержит теги, такие как v=DKIM1, тип ключа при необходимости и p= с материалом открытого ключа без обёрток закрытого ключа. Соблюдайте точный формат записи подписанта и поведение DNS-провайдера с кавычками. Перед сохранением проверьте, не добавляет ли интерфейс DNS автоматически зону, не разбивает ли длинные строки и не экранирует ли символы. После публикации запросите авторитетные серверы имён напрямую, затем независимые рекурсивные резолверы и восстановите полное значение TXT. Несколько символьных строк в одной TXT-записи объединяются DNS-клиентами, а несколько конкурирующих ресурсных записей могут создавать неоднозначность. Сохраните предыдущий ответ и TTL для отката. Не снижайте безопасность, публикуя более широкий ключ или оставляя тестовый флаг в продакшене лишь для устранения предупреждения проверяющего инструмента. Видимая запись доказывает публикацию DNS, а не использование отправителем соответствующего закрытого ключа.

Настройте итоговую подписывающую систему и подписываемые поля

Настройте компонент, который передаёт итоговое письмо исходящему транспорту, или убедитесь, что ни один последующий компонент не изменяет подписанное содержимое. Подпись DKIM покрывает хеш тела и поля заголовков, перечисленные в h=. RFC 6376 требует, чтобы для действительной подписи было подписано поле заголовка From. Включайте заголовки, критичные для идентификации в вашем продукте, разберитесь, как выбираются повторяющиеся заголовки, и не подписывайте поля, которые обязательно переписывает последующая система, если это преобразование не контролируется. Выбирайте канонизацию осознанно. Мягкая (relaxed) канонизация допускает определённые изменения пробелов и форматирования заголовков, но не разрешает произвольные правки тела. Простая (simple) канонизация более хрупкая. Добавление футера, переписывание ссылок, изменение границ MIME, преобразование кодировки передачи, теги в теме и нормализация окончаний строк после подписания могут нарушить проверку. Подписывайте полностью отрендеренное письмо после одобренных преобразований и не позволяйте недоверенным пользователям выбирать d=, s=, списки заголовков или ключи.

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

Отправляйте контрольные письма по каждому реальному пути, повторяющему продакшен, во внешние тестовые почтовые ящики, которыми управляет команда. Сохраняйте исходное письмо целиком, а не скопированное тело или пересериализованное вложение в тикете. Проверьте значения d= и s= в DKIM-Signature, список подписанных заголовков, хеш тела, алгоритм, канонизацию, временную метку и срок действия, если он указан. Запросите открытый ключ из независимой сети и запустите верификатор, соблюдающий стандарты, на исходных байтах. Сравните заголовок Authentication-Results доверенного получателя с результатом вашего верификатора, соблюдая границы доверия по RFC 8601. Тестируйте обычный текст, multipart/alternative, ожидаемые вложения, темы в Unicode, длинные заголовки, шаблоны, преобразования для трекинга, повторы и пути через релеи. Негативные тесты должны включать намеренно изменённый подписанный заголовок в тестовых данных, отсутствующий селектор, просроченный или выведенный из эксплуатации селектор и путь в обход подписания. Никогда не изменяйте реальные письма клиентов ради теста.

Оценивайте DKIM, DMARC и доставку как отдельные результаты

Успешный DKIM означает, что проверяющий нашёл действительную подпись указанного домена подписи по подписанным полям и телу. Это не аутентифицирует каждый неподписанный заголовок, не подтверждает автора-человека, не доказывает согласие получателя, соблюдение закона, принятие или попадание во «Входящие». DMARC отдельно проверяет, выравнивается ли успешный домен DKIM или SPF с видимым доменом From, и применяет политику владельца домена. Для контролируемых тестов записывайте как минимум результат и причину DKIM, домен d=, селектор, видимый домен From, результат выравнивания, результат SPF, результат DMARC, получателя и временную метку. Не включайте полные адреса получателей и содержимое в обычные метрики. Принятие SMTP-провайдером, принятие сервером получателя, последующий отказ, размещение в папке почтового ящика и взаимодействие — это более поздние состояния. Если DKIM проходит, но письмо отклоняется или фильтруется, исследуйте выравнивание DMARC, SPF, репутацию IP-адреса и домена, долю жалоб, политику письма, скорость и рекомендации получателя вместо постоянной ротации ключей.

Проводите ротацию без разрыва в проверке

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

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

Если подписи нет, определите, использовало ли письмо неподписываемый поток, неавторизованный домен From, резервный релей или путь шаблона. Если ключ не найден, проверьте точный запрос по s= и d=, делегирование зоны, авторитетный ответ, ошибки DNSSEC или резолвера и распространение изменений. При несовпадении хеша тела сравните исходный MIME до подписания и после получения, чтобы найти преобразования после подписания. При несовпадении подписи проверьте, соответствует ли опубликованный открытый ключ активному закрытому ключу, и изучите канонизацию и подписанные заголовки. Если DKIM проходит, а DMARC нет, оцените выравнивание с видимым доменом From. Классифицируйте временные ошибки DNS-запросов отдельно от устойчивых ошибок конфигурации и используйте ограниченные повторы на транспортном уровне, только если ответ SMTP указывает на временную ошибку. Приостанавливайте затронутый поток при подписании чужим доменом, неизвестных ключах, массовых сбоях проверки или подозрении на компрометацию ключа. Сохраняйте доказательства с минимумом персональных данных и меняйте только одну переменную в каждом контрольном повторном тесте.

Используйте документацию DKIM вашей системы отправки

Настройте DKIM в фактических системах отправки и DNS-органе, проверяйте исходные полученные письма и опирайтесь на действующие стандарты IETF и документацию конкретного провайдера.

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

Где публикуется открытый ключ DKIM?

Опубликуйте его как TXT-запись по имени selector._domainkey.signing-domain, используя точно те селектор и домен d=, которые будут в исходящей подписи.

Нужно ли размещать закрытый ключ DKIM в DNS?

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

Можно ли использовать один селектор DKIM для всех почтовых провайдеров?

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

Если DKIM проходит, значит ли это, что проходит и DMARC?

Не обязательно. DMARC требует, чтобы прошедший проверку домен DKIM d= был выровнен с видимым доменом From, если только требования DMARC не выполняются за счёт успешной выровненной проверки SPF.

Почему DKIM перестаёт проходить после добавления футера или переписывания ссылок для трекинга?

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

Как проводить ротацию ключей DKIM?

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

Определяет ли DKIM попадание во «Входящие»?

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

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

Нет. Проверьте оригиналы полученных писем по опубликованному ключу и подтвердите значения d= и s= в заголовке DKIM-Signature.