Исходящая подпись DKIM в Office 365 (часть 2)

Опубликовано: 11 Марта, 2023

Включение исходящего DKIM в Office 365 — продолжение

Теперь, когда мы создали все необходимые записи DNS, нам нужно включить DKIM-подпись для домена в Office 365. Мы делаем это, войдя на портал Office 365 с учетной записью администратора и перейдя в наш Exchange Admin Center (EAC):

фигура 1

Оказавшись в Центре администрирования Exchange, перейдите к защите, а затем к dkim:

фигура 2

Здесь мы выбираем домен, для которого мы хотим включить исходящую DKIM-подпись, и нажимаем «Включить»:

Рисунок 3

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

Рисунок 4

Когда все будет готово, DKIM будет включен:

Рисунок 5

В качестве альтернативы мы также можем использовать PowerShell для этого. Начнем с подключения к Exchange Online:

Рисунок 6

После подключения к нашему Exchange Online мы используем командлет для включения DKIM:

В этом случае я использую так как DKIM уже включен:

Рисунок 7

Мы также можем легко проверить, включен ли DKIM в данный момент или нет, с помощью командлета :

Рисунок 8

И это все, что нам нужно сделать, чтобы включить DKIM! Теперь пришло время протестировать его.

DKIM-тестирование

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

Рисунок 9

Обратите внимание на разные и по сравнению с нашим примером перед включением DKIM:

Рисунок 10

Теперь и домен изменились и выровнены с адресом

Помните, что если у вас есть другой почтовый сервер, расположенный после Office 365, который ретранслирует в Интернет, он может изменить содержимое сообщения и привести к тому, что подпись DKIM не будет проверена. Если это произойдет, вы должны убедиться, что Office 365 является последней службой, которая ретранслирует в Интернет, иначе вы можете получить некоторые отказы электронной почты из-за сломанной подписи DKIM.

Отключение DKIM в Office 365

Если по какой-то причине вы решите отключить DKIM, это можно сделать через Центр администрирования Exchange так же, как мы использовали для включения DKIM:

Рисунок 11

Или с помощью следующих командлетов PowerShell:

Однако нужно понимать, что это не отключает DKIM полностью. Помните, что Office 365 уже подписывает электронные письма, используя конфигурацию подписи DKIM по умолчанию, как мы видели в начале этой серии статей. Если, например, сейчас я отключу DKIM для своего домена, электронные письма снова начнут рассылаться с использованием следующей конфигурации DKIM:

Рисунок 12

В этом случае и домен содержат значения, на которые CNAME указывала бы, если бы для все еще была включена DKIM-подпись.

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

Селекторы DKIM и ротация ключей

Чтобы включить DKIM, нам пришлось настроить две «сущности» DKIM Selectors, и я упомянул, что это было для смены ключей.

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

В качестве метода проверки подлинности электронной почты ключи DKIM проверяют, что электронная почта не была изменена во время передачи;
Как правило, но не в случае с Office 365, владельцы доменов генерируют пару ключей: открытый и закрытый, которые используются для подписи электронных писем;
Открытый ключ существует в виде файла TXT в записи DNS домена;
Закрытый ключ хранится на почтовом сервере домена;
Когда электронное письмо отправляется, исходящий сервер добавляет цифровую подпись, используя закрытый ключ;
Эта цифровая подпись добавляется в заголовок подписи DKIM в электронном письме;
При получении электронного письма получатель проверяет подпись ключей DKIM с помощью открытого ключа отправителя (который публикуется в общедоступном DNS);
Совпадающая подпись означает успешную проверку.

Как и в случае со всеми паролями, чем дольше они остаются неизменными, тем выше риск их взлома. То же самое относится и к ключам DKIM. Рекомендуется менять ключи DKIM каждые несколько месяцев. Обычно это делается путем создания нового набора селектор/закрытый ключ/открытый ключ. После создания ключей открытый ключ публикуется в общедоступной записи DNS, а сервер исходящей почты перенастраивается для использования нового закрытого ключа (старый ключ следует хранить не менее недели, после чего его можно быть безопасно удалены).

Однако многие организации пренебрегают этим, главным образом потому, что это непростая задача, и некоторые вещи могут пойти не так:

Отрицательное кэширование DNS может вызвать некоторые проблемы. Если преобразователь DNS запрашивает наш открытый ключ до того, как мы его опубликуем, то он закэширует, что ключа не существует (хотя, надеюсь, закэширует это только на короткое время);
При повторном использовании селектора, который мы использовали в прошлом (но на этот раз с новым ключом), нам следует подождать 24 часа после публикации нового открытого ключа, прежде чем мы начнем подписывать электронные письма с новым закрытым ключом. Это позволит избежать кэширования несуществующего ключа у удаленных интернет-провайдеров, которые ищут его на основе старого сообщения, в котором использовался тот же селектор;
Предположим, мы ротируем наши ключи DKIM в 10:00. За пару минут до этого пользователь отправил электронное письмо, которое все еще было подписано старым ключом. Когда это электронное письмо поступает в систему электронной почты получателя в 10:05, оно больше не может быть проверено.

Что, с Office 365 таких проблем нет? Как уже упоминалось, основная причина, по которой мы создали две записи CNAME, заключается в ротации ключей. Поскольку мы используем записи CNAME, EOP может менять ключи всякий раз, когда это необходимо. Поскольку EOP контролирует открытый и закрытый ключи, когда ему нужно чередовать ключи, он просто обновляет закрытый ключ на серверной части и открытый ключ на DNS-серверах Microsoft. CNAME в нашей (клиентской) записи DNS по-прежнему указывает на Microsoft, но на новый ключ. Мы, как заказчик, ничего не должны делать!

Давайте посмотрим на предыдущий пример выше, где мы хотим повернуть наши ключи DKIM. В Office 365 это работает следующим образом:

3 апреля в 10:00 Microsoft публикует открытый ключ № 2 в CNAME № 2 (на самом деле, как мы видели, он уже там);
10 апреля в 10:00 EOP начинает подписывать исходящие электронные письма с помощью ключа № 2;
17 апреля в 10:00 предполагается, что все электронные письма, подписанные ключом №1, находятся вне системы, а также в системе всех остальных (поскольку мы уже неделю подписываем все электронные письма ключом №2);
Затем EOP обновляет ключ №1. Электронные письма, отправленные более недели назад, больше не могут быть проверены, но в любом случае их не нужно повторно подтверждать;
В следующий раз, когда EOP обновляет ключи через несколько месяцев, он повторяет тот же процесс: возвращается к ключу №1 (который содержит повернутый ключ), а через неделю обновляет ключ №2.

Используя этот подход, Microsoft позволяет своим клиентам автоматически менять свои ключи DKIM без каких-либо действий.

Эти изменения происходят автоматически за кулисами, поскольку EOP чередует изменения селектора подписи DKIM ( vs ), которые соответствуют CNAME 1 и CNAME 2. Поскольку в нашем домене эти две записи CNAME предварительно заполнены, нам не нужно знать об этом. какой селектор или клавиша активны, потому что EOP находится под управлением.

Несмотря на то, что весь этот процесс выполняется автоматически, клиенты по-прежнему могут заставить EOP менять ключи DKIM. Это делается через центр администрирования Exchange и путем перехода к защите, а затем к dkim. Выберите домен, для которого вы хотите чередовать ключи, и нажмите «Повернуть»:

Рисунок 13

Затем EOP сообщит, что ключи DKIM для этого домена ротируются:

Рисунок 14

Прежде чем менять наши ключи, мы использовали Selector1:

Рисунок 15

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

Рисунок 16

Вывод

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