Настройте DMARC для проверки домена адреса в поле "От" для облачных отправителей

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

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

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

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

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

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

    • Сообщение поступило из авторизованного источника для домена, используемого в адресе MAIL FROM (основное требование SPF).
    • Домены в адресах MAIL FROM и 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. Инструкции см. в разделе "Использование Центр администрирования Microsoft 365" для добавления записей TXT DMARC для доменов *.onmicrosoft.com в Microsoft 365. Дополнительные сведения о доменах *.onmicrosoft.com см. в разделе Почему у меня есть домен onmicrosoft.com?.

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

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

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

  • Поддомены:

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

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

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

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

Синтаксис для записей ТИПА 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.

• 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. Значения менее 100 используются для тестирования и настройки политики DMARC. Если вы не используете 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 в каталоге Ассоциация информационной безопасности Майкрософт (MISA) по адресу https://www.microsoft.com/misapartnercatalog. Службы отчетов DMARC описывают все пользовательские значения, необходимые в записи DMARC TXT.

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

  Совет

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

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

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

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

Используйте центр администрирования Microsoft 365, чтобы добавить TXT-записи DMARC для доменов *.onmicrosoft.com в Microsoft 365

Выполните следующие действия, чтобы добавить запись TXT DMARC для домена *.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.

   • TTL: Убедитесь, что выбран 1 час.

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

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

Рекомендуется постепенно настраивать 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

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

Следующие функции и поведение влияют на то, как Microsoft 365 оценивает DMARC для входящих сообщений и отправляет ли отчеты DMARC.

• Следующие встроенные функции безопасности для всех облачных почтовых ящиков влияют на проверки DMARC для входящей почты:

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

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

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

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

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

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

  Совет

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

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

Краткую справочную таблицу ошибок, причин и исправлений DMARC см. в статье Устранение неполадок с проверкой подлинности электронной почты в Microsoft 365.

Этот раздел поможет вам диагностировать и устранить распространенные сбои DMARC, понять, как Microsoft 365 работает с различными политиками DMARC, а также интерпретировать статистические и криминалистические отчеты DMARC.

Диагностика сбоя выравнивания

Как описано в разделе Настройка DMARC для проверки домена адреса From для облачных отправителей, сообщение проходит проверку DMARC, если по крайней мере одна из проверок согласования выполняется успешно (SPF или DKIM). Сообщение не проходит проверку DMARC только в том случае, если обе проверки согласования не пройдены.

Режимы выравнивания

Теги aspf (SPF) и adkim (DKIM) в записи DMARC TXT определяют, насколько строго домен From должен соответствовать домену, прошедшему проверку подлинности. Оба параметра необязательны, и по умолчанию используется значение r (нестрогий режим), но также доступно значение s (строгий режим). В следующем примере показана запись TXT DMARC, использующая строгое выравнивание SPF (aspf=s) и расслабленное выравнивание DKIM (adkim=r):

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com

• Расслабленный (rпо умолчанию): домены организации (корневые домены) должны совпадать. Поддомены разрешены.
• Strict (s): полное доменное имя должно точно соответствовать. Поддомен не совпадает.

Примеры:

Распространенные сценарии сбоя выравнивания

В следующей таблице перечислены распространенные сценарии сбоя выравнивания DMARC, их симптомы, первопричины и рекомендуемые исправления.

Диагностируйте сбои согласования по заголовкам сообщений

Шаг 1. Откройте заголовки сообщений и найдите заголовок Authentication-Results из Microsoft 365. В следующем примере показан заголовок Authentication-Results, в котором проверки SPF и DKIM по отдельности проходят успешно, но проверка DMARC не проходит, поскольку ни один из доменов не совпадает с доменом адреса в поле From:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

Шаг 2. Определите сбой выравнивания.

Шаг 3. Определите исправление, ответив на следующие вопросы:

1. Можно ли изменить адрес MAIL FROM на домен (например, bounces.contoso.com вместо bounces.adatum.com)?
   • Да. Настройте изменение MAIL FROM в службе, чтобы исправить выравнивание SPF.
   • Нет. Вместо этого используйте выравнивание DKIM (перейдите к шагу 2).
2. Может ли служба подписывать, используя ваш домен (d=contoso.com)?
   • Да: Настройте пользовательскую подпись DKIM в службе.
   • Нет. Рассмотрите стратегию поддомена:
     • Отправка из поддомена (например, sub.contoso.com).
     • Публикация отдельной записи DMARC для этого поддомена.
     • Настройте службу для подписи DKIM с d=sub.contoso.com.

Проверка выравнивания для последних сообщений в PowerShell

Подключитесь к Exchange Online PowerShell и выполните следующие команды:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

Влияние политики DMARC на поведение Microsoft 365

Как описано в разделе DMARC для входящей почты, поведение Microsoft 365 зависит от параметра политики записи Honor DMARC . Подробные сведения см. в разделе Защита от подделки и политики DMARC отправителя.

В следующей сводке показано общее поведение входящих сообщений, которые завершаются ошибкой DMARC , когда политика записи Honor DMARCвключена (рекомендуется):

Значения действий DMARC в Authentication-Results

В заголовке Authentication-Results могут отображаться следующие значения действий DMARC:

Интерпретация отчета DMARC

В этом разделе объясняется, как интерпретировать агрегированные и форензические отчеты DMARC, которые получатели отправляют на ваши адреса rua и ruf. Сведения о настройке rua и ruf значений в записи TXT DMARC см. в разделе Синтаксис записей DMARC TXT.

Агрегированные отчеты

В следующем примере показана XML-структура агрегатного отчета:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Чтение статистических отчетов

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

Общие шаблоны и исправления агрегатных отчетов

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

Судебно-медицинские отчеты

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

В следующем примере показана структура судебного отчета DMARC (в формате AFRF/RFC 6591), который получатель отправляет на ваш адрес ruf, если сообщение не проходит проверку DMARC. Найдите поля Feedback-Type, Source-IP и Authentication-Results, чтобы определить подробности сбоя:

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

Рекомендации по отчетам DMARC

Используйте следующие рекомендации для эффективного управления отчетами DMARC.

Междоменные отчеты

Если DMARC rua или ruf адрес находится в домене, отличном от отслеживаемого домена, принимающий домен должен опубликовать запись DNS TXT, разрешающую доставку отчета:

Пример: DMARC для contoso.com отправляет отчёты в dmarc@fabrikam.com

Чтобы авторизовать fabrikam.com получение отчетов DMARC от имени contoso.com, администратор fabrikam.com должен опубликовать следующую запись DNS TXT:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Без этой записи получатели не доставляют отчеты DMARC на внешний адрес.

Краткий справочник по устранению неполадок DMARC

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

Рабочий процесс диагностики DMARC

Выполните следующие действия для диагностики сообщения с помощью dmarc=fail:

1. Определение домена From: найдите header.from= значение в заголовке Authentication-Results .

2. Проверка выравнивания SPF: соответствует ли smtp.mailfrom= домен домену header.from= ?

   • Да (тот же домен организации с aspf=r): SPF выравнивается.
   • Нет. Сбой выравнивания SPF.
   • Прошел ли SPF вообще (spf=pass против spf=fail)? Если spf=fail, сначала исправьте SPF, добавив отправителя в запись SPF.

3. Проверка выравнивания DKIM: соответствует ли header.d= значение в DKIM-Signature домену header.from= ?

   • Да (тот же домен организации с adkim=r): DKIM выровнен.
   • Нет. Сбой выравнивания DKIM.
   • Прошел ли DKIM вообще (dkim=pass против dkim=fail)? Если dkim=fail, исправьте DKIM, опубликовав ключ и проверив подписание.

4. Если оба выравнивания не проходят, проверка DMARC не проходит. Варианты разрешения:

   • Исправьте согласование SPF: измените адрес MAIL FROM, указав адрес вашего домена.
   • Исправьте согласование DKIM: подписывайте с помощью d=contoso.com.
   • Использование поддомена: отправка из sub.domain.com с собственной записью DMARC.
   • Если сообщение переадресовано: настройте доверенный запечатыватель ARC.

5. Проверьте действие политики:

   • p=none: не влияет на доставку (только монитор).
   • p=quarantine: сообщение отправляется в папку Нежелательная Email (если включена политика Honor DMARC).
   • p=reject: сообщение отклоняется (если включена политика Honor DMARC ). Если легитимные сообщения отклоняются, используйте ARC, список разрешённых отправителей или исправьте аутентификацию на стороне отправителя.

Полезные команды PowerShell для устранения неполадок DMARC

Подключитесь к Exchange Online PowerShell и выполните следующие команды, чтобы проверить параметры политики DMARC, проверить записи DNS DMARC и DKIM, просмотреть последние сбои DMARC и проверить конфигурацию ARC:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

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

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

Сведения о диагностике и устранении ошибок проверки подлинности электронной почты см. в статье Устранение неполадок с проверкой подлинности электронной почты в Microsoft 365.