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

Введение

Около года назад я написал статью под названием DKIM и DMARC в Office 365, в которой я исследовал, что представляют собой ключи домена , которые я идентифицирую, почта (DKIM) и аутентификация сообщений на основе домена, отчетность и соответствие (DMARC). и как именно они работают с Exchange Online в Office 365.

На момент написания этой статьи Office 365 поддерживал только входящую проверку DKIM через IPv4 и IPv6. Исходящая подпись DKIM еще не была доступна, но планировалась. Ну, это здесь сейчас!

Краткий обзор DKIM

DKIM — это метод шифрования с открытым ключом, который работает в сочетании с Sender Policy Framework (SPF), криптографически связывая каждое сообщение с доменом отправителя, что снижает вероятность того, что наша деловая электронная почта будет обнаружена как спам.

Запись SPF указывает, какие серверы уполномочены отправлять почту для домена. Серверы-получатели выполняют проверку « »? Если нет, то рассматриваемое электронное письмо, скорее всего, является спамом. Наша DNS-запись SPF позволяет серверу-получателю выполнить эту проверку. Проверка SPF подтверждает, что письмо приходит с авторизованных серверов.

Запись DKIM добавляет цифровую подпись к электронным письмам, отправляемым нашей организацией. Серверы-получатели выполняют проверку « »? Если да, то электронное письмо не было изменено и отправлено законным отправителем. Наша DNS-запись DKIM позволяет серверу-получателю выполнить эту проверку. Проверка DKIM подтверждает, что сообщение подписано и связано с правильным доменом.

DKIM использует DNS для публикации открытого ключа, чтобы любая сторона, которая хочет проверить подпись, могла легко найти его и использовать для проверки подписи DKIM. Когда отправитель хочет отправить электронное письмо получателю, отправляющий сервер вычисляет криптографическую подпись, которая покрывает соответствующие части сообщения, используя закрытый ключ. Затем подпись помещается в заголовок электронной почты, и сообщение отправляется. В любой момент пути1 подпись проверяется с использованием открытого ключа.

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

DKIM в Office 365

Для входящей проверки нам не нужно ничего делать, так как Exchange Online Protection (EOP) автоматически проверяет DKIM с помощью заголовка в заголовках сообщений. На снимке экрана ниже мы видим этот заголовок и саму подпись DKIM электронного письма, отправленного из Gmail в Exchange Online. Мы также можем извлечь из него определенную информацию, например, тот факт, что домен подписи — gmail.com ( ).

Результат проверки отмечается в заголовке , а пока еще и во временном заголовке . На следующем снимке экрана мы видим как подпись DKIM, так и ее проверку:

фигура 1

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

Если я отправляю электронное письмо из клиента Office 365, кажется, что электронные письма уже отправляются с подписью DKIM:

фигура 2

Как видно из первых Authentication-Results, там написано ! Это связано с тем, что Microsoft добавляет подписи DKIM к исходящей электронной почте, даже если клиенты явно не включили подпись DKIM для своих доменов. Это постепенно распространялось на всех, и я предполагаю, что к моменту публикации этой статьи он, вероятно, уже будет включен для всех арендаторов.

В моем случае я еще не включил подпись DKIM, поэтому EOP создал политику подписи по умолчанию для моего домена и использует ее в и полях в подписи DKIM (обратите внимание, что в подписи DKIM для установлено значение , а не ):

Рисунок 3

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

Как мы увидим дальше, когда мы включим DKIM вручную, и домен изменятся так, чтобы они совпадали с адресом В моем случае он должен измениться на .

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

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

Итак, чтобы позволить EOP подписывать наши исходящие сообщения, сначала нам нужно опубликовать эти две DNS-записи CNAME (не записи TXT!) для каждого домена, который мы хотим подписать. Эти записи следующие:

<domainGUID>

Это то, что мы используем в наших записях MX для нашего домена, а точнее то, что появляется перед . Например, запись MX для моего домена nunomota.pt:

Таким образом, мой <domainGUID> — .

<начальный домен>

Это домен, с которым мы зарегистрировались для Office 365. Например, в моем случае это .

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

Рисунок 4

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

Опять же, в стандартной реализации DKIM запись хоста селектора DKIM реализована как запись TXT, которая содержит открытый ключ, который получатели будут использовать для проверки подписи нашего электронного письма. Поскольку Office 365 является «размещенной средой» и Microsoft не имеет доступа к нашему DNS, вместо этого мы публикуем записи CNAME, которые перенаправляют запросы DNS-запросов на специальную запись селектора DKIM Office 365 в домене , которая в очередь содержит наш открытый ключ.

Каждый домен получает свои DKIM-ключи, они не раздаются клиентам (по понятным причинам). Эти ключи даже не используются совместно доменами одного и того же клиента.

Мы можем проверить правильность создания этих записей, используя различные методы, например, с помощью полезного MXToolbox:

Рисунок 5

Мы также можем запросить запись , чтобы увидеть, что именно она разрешает. Как и ожидалось, это записи TXT, содержащие наши открытые ключи:

Рисунок 6

Те же запросы на этот раз выполняются с помощью MXToolbox:

Рисунок 7

Еще раз нам нужно создать эти 2 записи CNAME для каждого домена, который у нас есть в Exchange Online, для которого мы хотим включить подпись DKIM.

Вывод

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