Настройка DMARC для проверки домена от адреса для отправителей в Microsoft 365

• Применяется к:

  ✅ Exchange Online Protection, ✅ Microsoft Defender for Office 365 Plan 1 and Plan 2, ✅ Microsoft Defender XDR

Совет

Знаете ли вы, что можете бесплатно опробовать функции в Microsoft Defender XDR для Office 365 плана 2? Используйте 90-дневную пробную версию Defender для Office 365 в центре пробных версий портала Microsoft Defender. Сведения о том, кто может зарегистрироваться и условия пробной версии , см. здесь.

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

DMARC для домена включается путем создания записи TXT в DNS. Проверка DMARC сообщения электронной почты включает в себя следующие элементы:

• Убедитесь, что домены в адресах MAIL FROM и FROM совпадают: SPF и DKIM не требуют, чтобы домены в следующих адресах электронной почты были "выровнены" (совпадают):

  • Адрес ПОЧТЫ ОТ: адрес электронной почты, используемый при передаче сообщения между SMTP-серверами электронной почты. Этот адрес также называется адресом 5321.MailFrom , отправителем P1 или отправителем конверта.
  • От адреса: адрес электронной почты в поле Из заголовка, который отображается в качестве отправителя сообщения в почтовых клиентах. Этот адрес также называется адресом 5322.From или отправителем P2.

  Дополнительные сведения о том, как эти адреса электронной почты могут находиться в разных доменах и использовать для спуфингов, см. в разделе Почему интернет-электронной почте требуется проверка подлинности.

  • DMARC использует результат из SPF для проверки обоих следующих условий:

    • Сообщение поступило из авторизованного источника для домена, используемого в адресе MAIL FROM (основное требование SPF).
    • Домены в адресах MAIL FROM и From в сообщении выравниваются. Этот результат фактически требует, чтобы допустимые источники сообщения были в домене от адреса.

  • DMARC использует результат DKIM для проверки соответствия домена, подписавшего сообщение (значение d= в поле заголовка DKIM-Signature , проверенное значением селектора s= ) с доменом в адресе From.

  Сообщение передает DMARC, если одна или обе описанные проверки SPF или DKIM пройдены. Сообщение завершается ошибкой DMARC, если обе описанные проверки SPF или DKIM завершаются ошибкой.

• Политика DMARC: указывает, что делать с сообщениями, которые не выполняют DMARC (отклонение, карантин или отсутствие инструкций).

• Отчеты DMARC. Указывает место отправки статистических отчетов (периодической сводки положительных и отрицательных результатов DMARC) и криминалистических отчетов (также известных как отчеты о сбоях; почти немедленно результаты сбоя DMARC похожи на отчет о недоставке или сообщение о отказе).

Прежде чем приступить к работе, ознакомьтесь со сведениями о DMARC в Microsoft 365 на основе домена электронной почты:

• Если вы используете только домен Microsoft Online Email Routing Address (MOERA) для электронной почты (например, contoso.onmicrosoft.com). Хотя SPF и DKIM уже настроены для вашего домена *.onmicrosoft.com, необходимо создать запись DMARC TXT для домена *.onmicrosoft.com в Центр администрирования Microsoft 365. Инструкции см. в этом разделе далее в этой статье. Дополнительные сведения о доменах *.onmicrosoft.com см. в разделе Почему у меня есть домен onmicrosoft.com?.

• Если вы используете один или несколько личных доменов для электронной почты (например, contoso.com). Если вы еще этого не сделали, необходимо настроить SPF для всех личных доменов и поддоменов, используемых для электронной почты. Кроме того, необходимо настроить подписывание DKIM с помощью личного домена или поддомена, чтобы домен, используемый для подписи сообщения, соответствовал домену в адресе From. Инструкции см. в следующих статьях:

  • Настройка SPF для предотвращения спуфинга
  • Использование DKIM для проверки исходящей почты из личного домена

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

  • Поддомены:

    • Для служб электронной почты, которые не контролируются напрямую (например, службы массовой электронной почты), рекомендуется использовать поддомен (например, marketing.contoso.com) вместо домена электронной почты main (например, contoso.com). Вы не хотите, чтобы проблемы с почтой, отправленной из этих служб электронной почты, влияли на репутацию почты, отправленной сотрудниками в вашем домене электронной почты main. Дополнительные сведения о добавлении поддоменов см. в статье Добавление пользовательских поддоменов или нескольких доменов в Microsoft 365?
    • В отличие от SPF и DKIM, запись DMARC TXT для домена автоматически охватывает все поддомены (включая несуществующие поддомены), у которых нет собственной записи DMARC TXT. Другими словами, вы можете нарушить наследование DMARC в поддомене, создав запись DMARC TXT в этом поддомене. Но для каждого поддомена требуется запись SPF и DKIM для DMARC.

  • Если вы являетесь владельцем зарегистрированных, но неиспользуемых доменов. Если у вас есть зарегистрированные домены, которые не используются для электронной почты или чего-либо вообще (также известного как припаркованные домены), настройте записи DMARC TXT в этих доменах, чтобы указать, что сообщения электронной почты не должны поступать из этих доменов. Эта директива включает домен *.onmicrosoft.com, если вы не используете его для электронной почты.

• Возможно, потребуется помощь в проверке DMARC для входящей почты. Если вы используете службу электронной почты, которая изменяет сообщения при передаче перед доставкой в Microsoft 365, вы можете определить службу как доверенный запечатыватель ARC, чтобы измененные сообщения автоматически не завершались сбоем проверок DMARC. Дополнительные сведения см. в разделе Дальнейшие действия в конце этой статьи.

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

Совет

Сведения о создании записи DMARC TXT для домена *.onmicrosoft.com в Центр администрирования Microsoft 365 см. в этом разделе далее в этой статье.

В Microsoft 365 нет порталов администрирования или командлетов PowerShell для управления записями DMARC TXT в личных доменах. Вместо этого вы создаете запись DMARC TXT в регистраторе доменных имен или в службе размещения DNS (часто в той же компании).

Мы предоставляем инструкции по созданию записи TXT для подтверждения владения доменом для Microsoft 365 у многих регистраторов доменов. Эти инструкции можно использовать в качестве отправной точки для создания записей DMARC TXT. Дополнительные сведения см. в разделе Добавление записей DNS для подключения к домену.

Если вы не знакомы с конфигурацией DNS, обратитесь к регистратору доменных имен и попросите о помощи.

Синтаксис для записей ТИПА TXT DMARC

Записи DMARC TXT подробно описаны в RFC 7489.

Основной синтаксис записи DMARC TXT для домена в Microsoft 365:

Имя узла: _dmarc
Значение TXT: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

Или

Имя узла: _dmarc
Значение TXT: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Например:

Имя узла: _dmarc
Значение TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

• Обязательное значение _dmarc hostname.

• v=DMARC1; определяет запись TXT как запись DMARC TXT.

• Политика DMARC. Сообщает целевой почтовой системе, что делать с сообщениями, которые не удается DMARC, как описано ранее в этой статье:

  • p=reject: сообщения должны быть отклонены. То, что на самом деле происходит с сообщением, зависит от целевой почтовой системы, но сообщения обычно удаляются.
  • p=quarantine: сообщения должны быть приняты, но помечены. То, что на самом деле происходит с сообщением, зависит от целевой почтовой системы. Например, сообщение может быть помещено в карантин как спам, доставлено в папку "Нежелательная Email" или доставлено в папку "Входящие" с идентификатором, добавленным в тему или текст сообщения.
  • p=none: не рекомендуется действие для сообщений, которые завершаются сбоем DMARC. То, что происходит с сообщением, зависит от функций защиты электронной почты в целевой системе электронной почты. Это значение используется для тестирования и настройки политики DMARC , как описано далее в этой статье.

  Совет

  Исходящая почта из доменов в Microsoft 365, которые не выполняют проверки DMARC целевой почтовой службой, направляется через пул доставки с высоким риском для исходящих сообщений , если политика DMARC для домена имеет значение p=reject или p=quarantine. Это поведение не переопределяет.

• Процент неудачных сообщений DMARC, подлежащих политике DMARC: сообщает целевой почтовой системе, сколько сообщений, которые не удалось DMARC (процент), получают примененную к ним политику DMARC. Например, означает, что все сообщения, pct=100 которые не получают DMARC, получают политику DMARC, применяемую к ним. Для тестирования и настройки политики DMARC используются значения меньше 100, как описано далее в этой статье. Если вы не используете pct=, значение по умолчанию — pct=100.

• Отчеты DMARC:

  • Универсальный код ресурса (URI) агрегатного отчета DMARC. Значение rua=mailto: определяет, куда следует отправлять статистический отчет DMARC. Агрегатный отчет имеет следующие свойства:

    • Сообщения электронной почты, содержащие сводный отчет, обычно отправляются один раз в день (отчет содержит результаты DMARC за предыдущий день). Строка Тема содержит целевой домен, отправляющий отчет (отправитель), и исходный домен для результатов DMARC (домен отчета).
    • Данные DMARC отображаются в XML-вложении электронной почты, которое, скорее всего, сжато GZIP. Схема XML определена в приложении C к RFC 7489. Отчет содержит следующие сведения:
      • IP-адреса серверов или служб, которые отправляют почту с помощью вашего домена.
      • Указывает, проходят ли серверы или службы проверку подлинности DMARC.
      • Действия, выполняемые DMARC для почты, которые не проходят проверку подлинности DMARC (на основе политики DMARC).

    Совет

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

    • Создайте автоматизацию с помощью PowerShell или Microsoft Power BI.
    • Используйте внешнюю службу. Список служб можно найти по запросу DMARC в каталоге Microsoft Intelligent Security Association (MISA) по адресу https://www.microsoft.com/misapartnercatalog. Службы отчетов DMARC описывают все пользовательские значения, необходимые в записи DMARC TXT.

  • Универсальный код ресурса (URI) судебного отчета DMARC. Значение ruf=mailto: определяет место отправки отчета DMARC Forensic (также известного как отчет о сбоях DMARC). Отчет создается и отправляется сразу после сбоя DMARC, например отчета о недоставке (также известного как сообщение о недоставке или отказе).

  Совет

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

  Отдельные целевые почтовые системы отвечают за отправку вам отчетов DMARC. Объем и разнообразие отчетов DMARC различаются так же, как объем и разнообразие сообщений, отправляемых из вашей организации. Например, ожидается меньший объем почты во время праздников и больший объем почты во время организационных мероприятий. Рекомендуется назначить определенных пользователей для мониторинга отчетов DMARC и использовать определенный почтовый ящик или группу Microsoft 365 для получения отчетов DMARC (не доставляйте отчеты в почтовый ящик пользователя).

Дополнительные сведения о DMARC см. в следующих ресурсах:

• Серия обучения DMARC от M³AAWG (Рабочая группа по обмену сообщениями, вредоносным по вредоносным программам, мобильной борьбе со злоупотреблением).
• Контрольный список в dmarcian.
• Сведения на DMARC.org.

Использование Центр администрирования Microsoft 365 для добавления записей DMARC TXT для доменов *.onmicrosoft.com в Microsoft 365

1. В Центр администрирования Microsoft 365 в https://admin.microsoft.comвыберите Показать все>параметры Домены>. Или, чтобы перейти непосредственно на страницу Домены , используйте https://admin.microsoft.com/Adminportal/Home#/Domains.

2. На странице Домены выберите домен *.onmicrosoft.com из списка, щелкнув в любом месте строки, кроме поля проверка рядом с доменным именем.

3. На открывающейся странице сведений о домене выберите вкладку Записи DNS .

4. На вкладке Записи DNS выберите Добавить запись.

5. Во всплывающем окне Добавление настраиваемой записи DNS настройте следующие параметры:

   • Тип: убедитесь, что выбран параметр TXT (Text).

   • ИМЯ TXT: введите _dmarc.

   • Значение TXT: введите v=DMARC1; p=reject.

     Совет

     Чтобы указать назначения для отчетов DMARC Aggregate и DMARC Forensic, используйте синтаксис v=DMARC1; p=reject rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>. Например, v=DMARC1; p=reject rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

     Поставщики отчетов DMARC в каталоге https://www.microsoft.com/misapartnercatalog MISA упрощают просмотр и интерпретацию результатов DMARC.

   • Срок жизни: убедитесь, что выбран 1 час .

   По завершении во всплывающем окне Добавление настраиваемой записи DNS выберите Сохранить.

Настройка DMARC для активных личных доменов в Microsoft 365

Совет

Как упоминалось ранее в этой статье, необходимо создать записи SPF TXT и настроить подписывание DKIM для всех личных доменов и поддоменов, используемых для отправки электронной почты в Microsoft 365 , прежде чем настраивать DMARC для личных доменов или поддоменов.

Мы рекомендуем постепенно настраивать DMARC для доменов Microsoft 365. Цель состоит в том, чтобы p=reject получить политику DMARC для всех ваших личных доменов и поддоменов, но вам необходимо протестировать и проверить на этом пути, чтобы предотвратить отклонение электронной почты конечными почтовыми системами из-за непреднамеренных сбоев DMARC.

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

1. Начните с политики p=none DMARC и отслеживайте результаты для домена. Например:

   Запись DMARC TXT для marketing.contoso.com:

   Имя узла: _dmarc
   Значение TXT: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   В отчетах DMARC Aggregate и DMARC Forensic содержатся номера и источники сообщений, которые проходят и завершаются сбоем проверок DMARC. Вы можете увидеть, сколько вашего допустимого почтового трафика или не охватывается DMARC, и устранить неполадки. Вы также можете узнать, сколько мошеннических сообщений отправляется и откуда они отправляются.

2. Увеличьте политику DMARC до p=quarantine и отслеживайте результаты для домена.

   По истечении достаточного p=noneвремени вы можете увеличить политику DMARC до p=quarantine домена. Например:

   Запись DMARC TXT для marketing.contoso.com:

   Имя узла: _dmarc
   Значение TXT: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Вы также можете использовать значение, pct= чтобы постепенно влиять на большее количество сообщений и проверять результаты. Например, можно перемещаться следующими шагами:

   • pct=10
   • pct=25
   • pct=50
   • pct=75
   • pct=100

3. Увеличьте политику DMARC до p=reject и отслеживайте результаты для домена.

   По истечении достаточного p=quarantineвремени вы можете увеличить политику DMARC до p=reject домена. Например:

   Запись DMARC TXT для marketing.contoso.com:

   Имя узла: _dmarc
   Значение TXT: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

   Вы также можете использовать значение, pct= чтобы постепенно влиять на большее количество сообщений и проверять результаты.

4. Повторите предыдущие три шага для остальных поддоменов увеличения объема и (или) сложности, сохранив родительский домен для последнего.

   Совет

   Блокировка допустимой электронной почты в любом значительном объеме неприемлема для пользователей, но почти неизбежно, что вы получите некоторые ложные срабатывания. Медленно и методично решать проблемы, выявленные в отчетах DMARC. Поставщики отчетов DMARC в каталоге MISA упрощают https://www.microsoft.com/misapartnercatalog просмотр и интерпретацию результатов DMARC.

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

Записи DMARC TXT для припаркованных доменов в Microsoft 365

Совет

Рекомендуемая запись SPF TXT для припаркованных доменов, которые не отправляют почту, описана в разделе Записи SPF TXT для личных доменов в Microsoft 365. Как описано в разделе Настройка DKIM для подписи почты из домена Microsoft 365, мы не рекомендуем использовать записи DKIM CNAME для припаркованных доменов.

1. Если у вас есть зарегистрированные домены, из которых никто в Интернете не должен получать почту, создайте следующую запись DMARC TXT у регистратора доменов для домена:

   Имя узла: _dmarc
   Значение TXT: v=DMARC1; p=reject;

   • Значение pct= не включается, так как по умолчанию используется pct=100значение .
   • Значения rua=mailto: и ruf=mailto: , возможно, не требуются в этом сценарии, так как от отправителей в домене не должны поступать допустимые сообщения.

2. Если вы не используете домен *.onmicrosoft.com для отправки почты, необходимо также добавить запись DMARC TXT для домена *.onmicrosoft.com.

DMARC для входящей почты в Microsoft 365

• На проверки DMARC почты, поступающей в Microsoft 365, влияют следующие функции в Exchange Online Protection (EOP):

  • Включена или отключена ли аналитика спуфинга в политике защиты от фишинга, проверяющей сообщение. Отключение спуфинга отключает неявную защиту от спуфинга только от составных проверок проверки подлинности .
  • Включена или отключена политика записи Honor DMARC при обнаружении сообщения как спуфинговая политика в политике защиты от фишинга, проверяющей сообщение, и указанные действия на основе политики DMARC исходного домена (p=quarantineили p=reject в записи DMARC TXT).

  Полные сведения см. в разделе Защита от подделки и политики DMARC отправителя.

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

• Microsoft 365 не отправляет отчеты по судебной экспертизе DMARC (также известные как отчеты о сбоях DMARC), даже если в записи DMARC TXT исходного домена существует допустимый ruf=mailto: адрес.

• Microsoft 365 отправляет статистические отчеты DMARC во все домены с допустимым rua=mailto: адресом в записях DMARC TXT при условии, что запись MX для домена Microsoft 365 указывает непосредственно на Microsoft 365.

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

  Совет

  Когда сторонняя служба или устройство находится перед почтой, которая проходит в Microsoft 365, расширенная фильтрация для соединителей (также известная как пропустить список) правильно определяет источник интернет-сообщений для SPF, DKIM (если служба изменяет сообщения) и проверки DMARC.

Устранение неполадок DMARC

Для устранения неполадок с проверкой подлинности DMARC можно использовать следующий рисунок.

Дальнейшие действия

Для почты , поступающей в Microsoft 365, также может потребоваться настроить надежные запечатывщики ARC, если вы используете службы, которые изменяют сообщения при передаче перед доставкой в организацию. Дополнительные сведения см. в разделе Настройка доверенных запечатывщиков ARC.