Настройка клиента microsoft 365 для улучшения безопасности

Лестница Безопасности Office 365 от EOP до Microsoft Defender для Office 365

Важно!

Дополнительные сведения см. на этих страницах: Exchange Online Protection и Defender для Office 365.

С первого взгляда сложно сказать, что делает добавление Microsoft Defender для планов Office 365 преимуществом по сравнению с чистым управлением угрозами EOP. Чтобы понять, подходит ли вариант обновления для вашей организации, давайте рассмотрим возможности каждого продукта, когда речь идет о:

предотвращении и обнаружении угроз
изучении
реагировании

начиная с Exchange Online Protection:

Предотвращение/Обнаружение	Исследование	Реагирование
К технологиям относятся: спам фишинг вредоносная программа массовая рассылка аналитика спуфинга обнаружение олицетворения Карантин администратора Отправка ложных срабатываний и ложных отрицаний администратором и пользователями Разрешить или заблокировать для URL-адресов и файлов Отчеты	Поиск в журнале аудита Трассировка сообщений	Автоматическая очистка нулевого часа (ZAP) Уточнение и тестирование списков «Разрешить» и «Заблокировать»

Если вы хотите углубиться в EOP, .

Так как эти продукты являются накопительными, если вы оцените Microsoft Defender для Office 365 P1 и решите подписаться на него, вы добавите эти возможности.

Преимущества Defender для Office 365, план 1 (на данный момент):

Предотвращение/Обнаружение	Исследование	Реагирование
Технологии включают все, что включено в EOP, а также: Безопасные вложения Безопасные ссылки Защита Microsoft Defender для Office 365 для рабочих нагрузок (например, SharePoint Online, Teams, OneDrive для бизнеса) Защита во время щелчка в электронной почте, клиентах Office и Teams защита от фишинга в Defender для Office 365 Защита от олицетворения пользователя и домена Оповещения и API интеграции с SIEM для оповещений	API интеграции с SIEM для обнаружения Средство обнаружения в реальном времени Трассировка URL-адреса	Одинаковое

Таким образом, Microsoft Defender для Office 365 P1 расширяет возможности предотвращения _ и добавляет дополнительные формы _обнаружения**.

Microsoft Defender для Office 365 P1 также добавляет обнаружение в реальном времени для расследований. Название этого средства для поиска угроз выделено жирным шрифтом, потому что его наличие дает четкое представление о том, что у вас есть Defender для Office 365 P1. Оно не появляется в Defender для Office 365 P2.

Преимущества Defender для Office 365, план 2 (на данный момент):

Предотвращение/Обнаружение	Исследование	Реагирование
Технологии включают в себя все, что есть в EOP и Microsoft Defender для Office 365 P1, а также:	Обозреватель угроз Журналы учета угроз Представления кампании	Автоматическое исследование и реагирование (AIR) AIR из обозревателя угроз AIR для скомпрометированных пользователей API интеграции с SIEM для автоматических исследований

Таким образом, Microsoft Defender для Office 365 P2 расширяет возможности исследования и реагирования и добавляет новые возможности для охоты на угрозы. Автоматизация.

В Microsoft Defender для Office 365 P2 основное средство охоты на угрозы называется обозревателем угроз, а не обнаружением в реальном времени. Если вы видите обозреватель угроз при переходе на портал Microsoft 365 Defender, вы в Microsoft Defender для Office 365 P2.

Чтобы получить сведения о Microsoft Defender для Office 365 P1 и P2, .

Совет

EOP и Microsoft Defender для Office 365 также отличаются для конечных пользователей

В EOP и Defender для Office 365 P1 основное внимание уделяется информированию, поэтому эти две службы включают надстройку Outlook «Пожаловаться на сообщение», чтобы пользователи могли сообщать о сообщениях электронной почты, которые они считают подозрительными, для дальнейшего анализа

В Defender для Office 365 P2 (который содержит все, что есть в EOP и P1) фокус смещается на дальнейшее обучение для конечных пользователей, и поэтому Центр управления безопасностью имеет доступ к мощному средству симулятора угроз, а также метрикам конечных пользователей, которые он предоставляет.

Ограничения для параметров нежелательной почты

Коллекция safelist (список отправителей Сейф, список получателей Сейф и список заблокированных отправителей), хранимая в почтовом ящике пользователя, также синхронизируется с EOP. При синхронизации каталогов коллекция safelist синхронизируется с Azure AD.

Коллекция safelist в почтовом ящике пользователя имеет ограничение в 510 КБ, которое включает все списки, а также дополнительные параметры фильтра нежелательной почты. Если пользователь превышает этот предел, он получит Outlook ошибку, которая выглядит так:

Дополнительные сведения об этом ограничении и его изменении см. в kB2669081.
Синхронизированный набор безопасных списков в EOP имеет следующие ограничения синхронизации:
- 1024 записей в списке Сейф отправителей, списке получателей Сейф и внешних контактах, если включена электронная почта Trust от моих контактов.
- 500 записей в списке заблокированных отправителей и списке заблокированных доменов.
Когда будет достигнуто ограничение на вход 1024, произойдет следующее:

Список перестает принимать записи в PowerShell и Outlook в Интернете, но ошибки не отображаются.
Outlook пользователи могут добавлять более 1024 записей, пока не достигнут Outlook 510 КБ. Outlook можно использовать эти дополнительные записи, если фильтр EOP не блокирует сообщение перед доставкой в почтовый ящик (правила потока почты, анти-спуфинг и т.д.).
При синхронизации каталогов записи синхронизируются с Azure AD в следующем порядке:
1. Контакты почты, если включена электронная почта Trust от моих контактов.
2. Список Сейф и список получателей Сейф объединяются, дублируются и сортируются в алфавитном порядке при изменении первых 1024 записей.
Используются первые 1024 записи, и соответствующая информация штампуется в заглавных главах сообщений.

Записи за 1024, не синхронизированные с Azure AD, обрабатываются Outlook (не Outlook в Интернете), и никакие сведения не штампуются в заглавных главах сообщений.

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

Имя файла: outlk16.opax
Параметр политики: доверяйте электронной почте от контактов

Volgende stappen: nadat u DKIM hebt ingesteld voor Microsoft 365

Hoewel DKIM is bedoeld om spoofing te voorkomen, werkt DKIM beter met SPF en DMARC.

Als u DKIM hebt ingesteld, maar u hebt SPF nog niet ingesteld, moet u dat zeker doen. Zie voor een korte introductie van SPF en om het snel te configureren SPF in Microsoft 365 instellen om spoofing te voorkomen. Voor een beter begrip van hoe Microsoft 365 gebruikmaakt van SPF of voor het oplossen van problemen of niet-standaardimplementaties zoals hybride implementaties, begint u met Hoe Microsoft 365 gebruikmaakt van SPF (Sender Policy Framework) om spoofing te voorkomen.

Met deze test wordt gevalideerd of de configuratie voor DKIM-ondertekening correct is geconfigureerd en dat de juiste DNS-vermeldingen zijn gepubliceerd.

Знакомство с основами потока Microsoft 365 и Office 365 почты

Управление потоком обработки почты с помощью записей DNS

В Microsoft 365 и Office 365 почтового потока существует несколько компонентов DNS, которые особенно важны для проверки подлинности и доставки электронной почты: записи MX, SPF, DKIM и DMARC.

Записи MX позволяют почтовым серверам легко определять адресатов сообщений. Запись MX можно рассматривать как тип почтового адреса. Если вы хотите Microsoft 365 или Office 365 получать всю электронную почту, адресованную [email protected], запись MX для contoso.com должна указать на Microsoft 365 или Office 365, и она будет выглядеть следующим образом:

SPF (структура политики отправитель) — это специально отформатированная запись TXT в DNS. SPF проверяет, что только организация, которая владеет доменом, фактически отправляет электронную почту из этого домена. SPF — это мера безопасности, которая помогает убедиться, что кто-то не выдает себя за другую организацию. Это обезличение часто называют спуфингом. Как владелец домена вы можете использовать SPF для публикации списка IP-адресов или подсетей, уполномоченных отправлять электронную почту от имени организации. Это может быть полезным, если необходимо отправлять сообщения с нескольких серверов или служб с разными IP-адресами.

Важно!

Для каждого домена можно использовать только одну запись SPF. Одновременное использование нескольких записей SPF делает их недействительными и приводит к ошибкам потока обработки почты.

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

в Microsoft 365 или Office 365 spoofing. Чтобы получить более подробное представление о том, как Microsoft 365 и Office 365 использовать SPF, а также для устранения неполадок или нестандартных развертывания, таких как гибридные развертывания, начните с того, как Microsoft 365 и Office 365 использовать sender Policy Framework (SPF)для предотвращения подмены.

DomainKeys Identified Mail (DKIM). позволяет прикрепить цифровую подпись к сообщениям электронной почты в загонах сообщений, которые вы отправляете. Системы электронной почты, получающая электронную почту из домена, используют эту цифровую подпись, чтобы определить, является ли входящие сообщения электронной почты законными. Сведения о DKIM и Microsoft 365 или Office 365 см. в ссылке Использование DKIMдля проверки исходящие сообщения электронной почты, отправленной из домена в Microsoft 365 или Office 365 .

Проверка подлинности, отчетности и соответствия на основе доменных сообщений (DMARC). помогает получать почтовые системы определить, что делать с сообщениями, которые не проверяют SPF или DKIM, и обеспечивает другой уровень доверия для ваших партнеров по электронной почте. Сведения о настройке DMARC см. в сообщении Use DMARC дляпроверки электронной почты в Microsoft 365 или Office 365.

Используйте SPF, DKIM и DMARC вместе для наилучшего использования.

Как записи MX влияют на фильтрацию спама

Для наилучшего потока почты (особенно для фильтрации нежелательной почты) рекомендуется указать запись MX для домена вашей организации на Microsoft 365 или Office 365. Сканирование нежелательной почты является начальной точкой подключения к Microsoft 365 или Office 365 службе. Отправитель сообщения, IP-адрес сервера, с которого отправлено сообщение, а также поведение подключающегося почтового сервера все эти данные позволяют определить, является сообщение допустимым или нежелательным. Если запись MX вашего домена не означает Microsoft 365 или Office 365, фильтры нежелательной почты будут не так эффективны. Если запись MX не означает Microsoft 365 или Office 365, будут некоторые допустимые сообщения, которые служба неправильно классифицирует как спам, а некоторые сообщения нежелательной почты, которые служба неправильно классифицирует как легитимную электронную почту.

С учетом этого существуют законные бизнес-сценарии, которые требуют, чтобы запись MX вашего домена была указать на другое место, кроме Microsoft 365 или Office 365. Например, электронной почте, предназначенной для организации, может потребоваться сначала прибыть в другой пункт назначения (например, в стороне решение для архивизации), а затем перенаправление через Microsoft 365 или Office 365, а затем доставить в почтовые ящики на почтовом сервере организации. Эта схема может максимально отвечать требованиям вашей компании.

Независимо от ваших потребностей, это руководство поможет вам понять, как необходимо настроить записи MX, SPF и, возможно, соединители.

1. Setup a catch-all mailbox

Create dynamic distribution list of all users

In the , navigate to -> :

Under , click the arrow on the right of to drop down a list of group types, and select :

Name your distribution list ( and ), enter a note, and click :

Alter mail flow

In , navigate to -> :

Highlight your domain, and click the pencil icon to edit it:

Under , choose , and click Save:

Navigate to -> :

Click the sign to add a new rule, and choose from the dropdown:

Use the interface to create a rule with the following:

Apply this rule if the sender is located.. Outside the organization
Do the following..
- Redirect the message to <your catch-all mailbox>
- Prepend the subject of the message with: » » (indicate to the recipient that this email has been «caught»)
Except if.. The recipient is a member of all-users (the dynamic group you created)

Save the rule:

Steps to manually upgrade your 1024-bit keys to 2048-bit DKIM encryption keys

Note

Microsoft 365 automatically sets up DKIM for onmicrosoft.com domains. No steps are needed to use DKIM for any initial domain names (like litware.onmicrosoft.com). For more information about domains, see .

Since both 1024 and 2048 bitness are supported for DKIM keys, these directions will tell you how to upgrade your 1024-bit key to 2048 in Exchange Online PowerShell. The steps below are for two use-cases, please choose the one that best fits your configuration.

When you already have DKIM configured, you rotate bitness by running the following command:

or
For a new implementation of DKIM, run the following command:

Stay connected to Exchange Online PowerShell to verify the configuration by running the following command:

Tip

If you want to rotate to the second selector, after four days and confirming that 2048-bitness is in use, manually rotate the second selector key by using the appropriate cmdlet listed above.

For detailed syntax and parameter information, see the following articles: Rotate-DkimSigningConfig, New-DkimSigningConfig, and Get-DkimSigningConfig.

Начало работы с Cloud App Security или Office 365 Cloud App Security

Используйте Office 365 Cloud App Security для оценки риска, оповещения о подозрительной активности и автоматического принятия действий. Требуется Office 365 E5 плана.

Или используйте Microsoft Cloud App Security для получения более глубокой видимости даже после предоставления доступа, комплексного управления и улучшенной защиты для всех облачных приложений, включая Office 365.

Так как это решение рекомендует план EMS E5, рекомендуется начать с Cloud App Security, чтобы использовать его с другими приложениями SaaS в среде. Начните с политик и параметров по умолчанию.

Дополнительные сведения:

Развертывание Cloud App Security
Дополнительные сведения о Microsoft Cloud App Security
Что такое Cloud App Security?

Как DKIM работает лучше, чем один SPF, для предотвращения злонамеренного подмены

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

В этом примере, если бы вы опубликовали только запись типа TXT инфраструктуры политики отправителей для домена, почтовый сервер получателя мог бы пометить ваше сообщение как спам, что привело бы к ложному срабатыванию. Добавление DKIM в этом сценарии позволяет снизить количество ложных срабатываний. Поскольку в технологии DKIM для проверки подлинности используются не только IP-адреса, но и шифрование с помощью открытого ключа, она считается более надежным способом проверки подлинности, чем SPF. Рекомендуем использовать в вашей инфраструктуре одновременно SPF и DKIM, а также DMARC.

Совет

DKIM использует закрытый ключ для вставки зашифрованной подписи в заголовки сообщений. Имя подписывающего домена (или домена исходящей почты) вставляется в заголовок в качестве значения поля d=. Проверяющий домен (или домен получателя) затем использует поле d= для поиска открытого ключа в DNS и проверки подлинности сообщения. Так сообщение проходит проверку DKIM.

Параметры Spoof

Спуфинг — это когда адрес From в сообщении электронной почты (адрес отправитель, показанный в клиентах электронной почты) не соответствует домену источника электронной почты. Дополнительные сведения о подмене см. в Microsoft 365.

Следующие параметры подмены доступны в политиках защиты от фишинга в EOP и Defender для Office 365:

Включите подмену сведений: включается или выключается подмена сведений. Рекомендуется оставить его включенным.

Когда включена разведка подмены, в разведданных подмены показаны поддельные отправители, которые были автоматически обнаружены и разрешены или заблокированы с помощью подмены. Вы можете вручную переопредить вердикт о подмене сведений, чтобы разрешить или заблокировать обнаруженных подмена отправителей изнутри. Но когда это происходит, подмена отправитель исчезает из анализа подмены сведений и теперь видна только на вкладке Spoof в списке «Разрешить или заблокировать клиента». Вы также можете вручную создавать записи для подмены отправителей или блокировать их в списке разрешить или заблокировать клиента. Дополнительные сведения см. в следующих статьях:
- Spoof intelligence insight in EOP
- Управление списком разрешить или блокировать клиента в EOP
Примечание
- Защита от спуфинга включена по умолчанию в политике защиты от фишинга по умолчанию и в любых новых настраиваемой политике защиты от фишинга, которые вы создаете.
- Вам не нужно отключать защиту от подмены, если запись MX не означает Microsoft 365; вместо этого включите усиленную фильтрацию соединители. Инструкции см. в расширенной фильтрации соединители в Exchange Online.
- Отключение защиты от спуфинга только отключает неявную защиту от подмены из композитных проверок Если отправитель не проводит явные проверки DMARC, в которых политика настроена на карантин или отклоняется, сообщение по-прежнему находится на карантине или отклоняется.
Неавентированные уведомления отправитель: Эти уведомления доступны только при включенной подмене сведений. Сведения см. в следующем разделе.
Действия. Для сообщений от заблокированных подменяющих отправителей (автоматически заблокированных подменой сведений или вручную заблокированных в списке Tenant Allow/Block), вы также можете указать действие, которое необходимо принять для этих сообщений:
- Карантин сообщения. Отправляет сообщение на карантин вместо предполагаемых получателей. Сведения о карантине см. в следующих статьях:
  - Карантин в Microsoft 365
  - Управление карантинными сообщениями и файлами в качестве администратора в Microsoft 365
  - Поиск и освобождение карантинов сообщений в качестве пользователя в Microsoft 365
  Если выбрать карантин сообщения, можно также выбрать политику карантина, которая применяется к сообщениям, которые были карантинными с помощью защиты от спуф-аналитики. Политики карантина определяют, что пользователи могут сделать для карантинов сообщений и получают ли пользователи уведомления о карантине. Дополнительные сведения см. в статье Политики карантина.

Неавентированный отправитель

Неавентированные уведомления отправитель являются частью параметров доступных в политиках защиты от фишинга в EOP и Defender для Office 365, как описано в предыдущем разделе. Следующие параметры доступны только при включенной подмене сведений:

Показать (?) для неавентированных отправителей для подмены: Это уведомление добавляет знак вопроса к фотографии отправителей в поле From, если сообщение не проходит проверки SPF или DKIM и сообщение не передает DMARC или композитную проверку подлинности После отключения этого параметра знак вопроса не добавляется на фотографию отправитель.
Показать тег «via»?: Это уведомление добавляет тег via ([email protected] через fabrikam.com) в поле From, если домен в адресе From (отправитель сообщений, отображаемого в клиентах электронной почты) отличается от домена в подписи DKIM или адреса MAIL FROM. Дополнительные сведения об этих адресах см.

Чтобы предотвратить добавление знака вопроса или тега в сообщения определенных отправителей, у вас есть следующие параметры:

Разрешить подмене отправитель в подмене сведений или вручную в списке Разрешить клиента / Блок. Разрешение подмены отправителю позволит предотвратить отображение тега в сообщениях от отправиющего, если неавентированное удостоверение отправитель отключено.
для домена отправитель.
- Для знака вопроса на фотографии отправитель, SPF или DKIM являются наиболее важными.
- Для тега с помощью тега подтвердим домен в подписи DKIM или в адресе MAIL FROM совпадает (или является поддоманом) домена в адресе From.

Дополнительные сведения см. в сообщении Identify suspicious messages in Outlook.com и Outlook в Интернете

Default behavior for DKIM and Microsoft 365

Also, if you disable DKIM signing on your custom domain after enabling it, after a period of time, Microsoft 365 will automatically apply the MOERA/initial domain policy for your custom domain.

In this example, the host name and domain contain the values to which the CNAME would point if DKIM-signing for fabrikam.com had been enabled by the domain administrator. Eventually, every single message sent from Microsoft 365 will be DKIM-signed. If you enable DKIM yourself, the domain will be the same as the domain in the From: address, in this case fabrikam.com. If you don’t, it will not align and instead will use your organization’s initial domain. For information about determining your initial domain, see .

Как Microsoft 365 использует Authenticated Received Chain (ARC)

Все размещенные почтовые ящики в Microsoft 365 теперь получают преимущества ARC с улучшенной надежностью доставки сообщений и защитой от спуфинга. ARC сохраняет результаты проверки подлинности писем от всех посредников (переходов), когда письмо направляется с исходного сервера в почтовый ящик получателя. До ARC изменения, вносимые посредниками в маршрут письма, например правила пересылки или автоматические подписи, могли приводить к сбоям DMARC к моменту поступления письма в почтовый ящик получателя. При использовании ARC криптографическая сохранность результатов проверки подлинности позволяет Microsoft 365 подтверждать подлинность отправителя сообщения электронной почты.

В настоящее время Microsoft 365 использует ARC для подтверждения результатов проверки подлинности, если корпорация Майкрософт является подтверждающим центром ARC, но в будущем планируется добавить поддержку сторонних подтверждающих центров.

Поведение по умолчанию для DKIM и Microsoft 365

Кроме того, если вы отключите подпись DKIM в личном домене после включения, через некоторое время Microsoft 365 автоматически применит политику MOERA/исходного домена для вашего личного домена.

Предположим, что в примере ниже подпись DKIM для домена fabrikam.com включена автоматически Microsoft 365, а не администратором домена. Это означает, что в DNS нет нужных записей CNAME. Подписи DKIM для электронной почты из этого домена будут выглядеть примерно так:

В этом примере имя узла и доменное имя содержат значения, на которые указывала бы запись CNAME, если бы администратор домена настроил подпись DKIM для домена fabrikam.com. Каждое сообщение, отправленное из Microsoft 365, будет подписано с помощью DKIM. Если вы включили DKIM самостоятельно, то домен будет совпадать с доменом, указанным в адресе отправителя (в этом случае fabrikam.com). В противном случае будет использоваться исходный домен организации. О том, как узнать свой исходный домен, читайте в разделе .

DMARC

What is it?

Be aware that lots of receiving server will send you a report.

Depending on the volume of mail you’re sending (and how attractive your domain is to spoofers), this can result in hundreds of DMARC reports a day from different servers. This can become a little overwhelming to manage. This is why there are so many DMARC reporting toolsN.

My advice sign up with a tool that can help you process and interpret your DMARC reports, let them handle the heavy processing of parsing hundreds of reports a day and making actionable graphs based on the information they parse.

Here’s an example of a correctly configured domain:

And here’s an example of an unconfigured domain:

Общие параметры политики

Следующие параметры политики доступны в политиках защиты от фишинга в EOP и Defender для Office 365:

Имя. Нельзя переименовать политику защиты от фишинга по умолчанию. После создания настраиваемой политики защиты от фишинга переименовать политику на портале Microsoft 365 Defender.
Описание Вы не можете добавить описание в политику защиты от фишинга по умолчанию, но вы можете добавить и изменить описание для созданных вами пользовательских политик.
Пользователи, группы и домены: определяет внутренних получателей, к которые применяется политика защиты от фишинга. Это значение требуется в настраиваемой политике и не доступно в политике по умолчанию (политика по умолчанию применяется ко всем получателям).

Условие или исключение можно использовать только один раз, но можно указать для них несколько значений. Указать несколько значений в одном условии или исключении можно с помощью оператора OR (например, <recipient1> or <recipient2>). Между разными условиями и исключениями используется оператор AND (например, <recipient1> and <member of group 1>).
- Пользователи: один или несколько почтовых ящиков, почтовых пользователей или почтовых контактов в вашей организации.
- Группы. Одна или несколько групп в вашей организации.
- Домены. Один или несколько настроенных принятых доменов в Microsoft 365.
- Исключить этих пользователей, группы и домены: Исключения для политики. Параметры и поведение в точности похожи на условия:
  - Пользователи
  - Группы
  - Домены
Примечание

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

DNS records needed for Office 365 DKIM

Before we enable DKIM signing we need to create two CNAME records in our external DNS zone. This may appear to contradict the TXT record described in the diagram at the beginning of the article. That’s because it does. Traditionally a TXT record would contain your public encryption key. Microsoft does not give you this key. Instead, they take care of it for you on the back end. This is similar to how they handle certificates for your client access services. All you need to do is to create a CNAME record to forward DKIM requests from your DNS to Microsoft. This makes configuring DKIM incredibly easy.

Tip: The drawback with Microsoft maintaining this key pair is that you can not export your DKIM key for use in other applications. Nor can you import a key pair you may already be using elsewhere. For these scenarios, you would need to maintain a separate key pair and set of DNS records. We will try to cover that in a future article.

The CNAME records will be in the form of:

In our example, these will look like the following.

I think the easier way to get this value is to click Enable in the DKIM task pane. This will give you an error. But it will tell you exactly what record Office 365 is looking for.

To do this, select the domain you plan to enable DKIM signing on and click Enable in the task pane. You should see an error similar to the following. This error gives us the same values we identified above.

The final DNS records should look similar to the following.

Keep in mind that you will need two CNAME records for each domain you plan to enable DKIM on. For example, our CNAME records for exchangeservergeek.com would look like the following. Here you can see the domain guid changes but the initial service domain remains the same.