Поделиться через

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

Совет

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

Проверка подлинности сообщений на основе домена, отчеты и соответствие (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. Инструкции см. в следующих статьях:

    После этого также необходимо настроить записи 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 от M3AAWG (Рабочая группа по обмену сообщениями, вредоносным по вредоносным программам, мобильной борьбе со злоупотреблением).
  • Сведения на 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 можно использовать следующий рисунок.

Изображение устранения неполадок для DMARC

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

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