Подписант и автор письма являются разными понятиями
RFC 6376 отделяет домен подписанта от предполагаемого автора. Сервис может подписать письмо своей идентичностью, а видимый From относиться к другому домену. Поэтому вопрос DKIM проходит требует уточнения: какая подпись, какой домен и какое сообщение рассматриваются. Технический результат не равен полномочию человека менять реквизиты или получать данные.
Для владельца бизнеса полезен реестр отправляющих потоков: сотрудник, CRM, сайт и рассылка. У каждого могут быть собственные настройки подписи. Нельзя распространять наблюдение одного сообщения на все потоки. Начните с назначения сервиса и ответственного за него, затем определите безопасную контрольную отправку и нужные технические сведения.
Это определение механизма, а не готовая конфигурация для любого провайдера. Для настройки и ротации применяют актуальную документацию реального сервиса, полномочия и приемку. В первый запрос достаточно включить домен и описание задачи. Закрытый ключ, пароль и полный архив переписки не нужны и не должны попадать в открытый отчет.
Домен, селектор и ключ: как связаны элементы
В подписи поля d и s указывают домен и селектор. По ним определяется соответствующее имя ключа в DNS. При этом сам факт наличия записи является только одним наблюдением. Нужно отдельно понять, использует ли нужный сервис эту подпись и что показала проверка сообщения. Таблица помогает сохранить эти уровни раздельно при обсуждении с исполнителем.
| Элемент | Что помогает установить | Чего не доказывает |
|---|---|---|
| Домен d | Какую идентичность заявил подписант | Совпадение с видимым автором во всех случаях |
| Селектор s | Какое имя ключа связано с подписью | Что любая распространенная запись относится к письму |
| Открытый ключ DNS | Доступные опубликованные данные | Что подпись включена для рабочего потока |
| Закрытый ключ | Средство подписания на стороне владельца | Необходимость отправлять его проверяющему |
| Успешная проверка | Определенные свойства подписи сообщения | Безопасность содержания и полномочий автора |
| Изменение настроек | Новую конфигурацию в конкретном объеме | Проверку всех старых и новых потоков |
Что подтверждает подпись и что остается вне ее
Проверка относится к подписанным частям сообщения и соответствующей доменной идентичности. Она не означает, что каждый заголовок и каждое бизнес-утверждение защищены одинаково. Для точного вывода нужно учитывать фактическую подпись и результат доверенной принимающей стороны. Не следует заменять эти сведения скриншотом зеленого переключателя в панели.
Изменение сообщения по пути может влиять на результат. Пересылка без определенного изменения и пересылка с обработкой содержимого являются разными условиями. Поэтому неудачная проверка сама по себе не устанавливает злоумышленника или взлом аккаунта. Разбор требует сопоставить сообщение, маршрут и доступные сведения, указав неизвестные участки.
Почему DKIM не является шифрованием и проверкой намерений
Подпись не делает текст недоступным получателю и не заменяет отдельные механизмы конфиденциальности. Она также не устанавливает, вправе ли подписавшая система отправлять конкретный счет. Законный сервис или ящик может использоваться без разрешения владельца. Важные действия бизнеса требуют независимой проверки полномочий по установленной процедуре.
Результаты в заголовках читают с учетом доверенной стороны. RFC 8601 описывает Authentication-Results и границу доверия к этим сведениям. Нельзя без проверки принимать любую добавленную строку за доказательство успешной аутентификации. Если доступна только пересланная картинка, нужно явно указать, каких данных недостаточно для вывода.
Ротация ключей и связь с DMARC
Ротация должна учитывать фактически используемые селекторы и сообщения, которые еще могут находиться в пути. Нельзя удалять старые данные только потому, что панель показывает создание нового ключа. Сначала согласуйте порядок по поддерживаемой процедуре сервиса и приемку отправки. Владелец DNS и владелец системы подписания могут быть разными участниками.
Для DMARC важна связь домена From с успешным согласованным механизмом. DKIM pass для чужой идентичности не отвечает на этот вопрос автоматически. По текущему RFC 9989 успешный согласованный SPF или DKIM может удовлетворить условию DMARC. Отдельные правила получателя и требования провайдера проверяются дополнительно, без универсальной гарантии доставки.
Как превратить определение в проверяемую задачу
Сформулируйте поток и нужный результат: найти реальный селектор, подтвердить активную подпись, проверить смену ключа или понять расхождение с доменом From. Для каждой задачи нужны доступные сведения, владелец и безопасная контрольная отправка. Не смешивайте всю доставляемость и защиту учетных записей в один положительный статус DKIM.
CyberFixCrew является израильской компанией по кибербезопасности и помогает русскоязычным бизнесам по всему миру разбирать сайты, почту и цифровую инфраструктуру. Практические израильские знания используются для согласования фактов, доступа и приемки. Если нужна работа с вашей системой, укажите домен и отправляющие сервисы без передачи секретов.
- Определить сообщение и отправляющий поток.
- Установить домен и селектор фактической подписи.
- Отделить запись DNS от активного подписания.
- Прочитать доверенный результат и его ограничения.
- Записать проверенный объем и следующие действия.