Проверка подлинности электронной почты в EOP

  • Статья
  • Чтение занимает 8 мин

Совет

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

Область применения

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

Email проверка подлинности проверяет, что сообщения электронной почты от отправителя (например, laura@contoso.com) являются допустимыми и поступают из ожидаемых источников для этого домена электронной почты (например, contoso.com).

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

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

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

Однако записи DNS для SPF, DKIM и DMARC (совместно именуемых "политики проверки подлинности электронной почты") являются необязательными. Домены с надежными политиками проверки подлинности электронной почты, такими как microsoft.com и skype.com, защищены от спуфинга. Но домены, имеющие менее надежные политики проверки подлинности электронной почты или не имеющие вообще никакой политики, являются основной целью спуфинга.

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

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

Общее извещение корпорации Майкрософт см. в статье Море фишинга, часть 2 — Улучшенные средства борьбы со спуфингом в Microsoft 365.

Многофакторная аутентификация

Если в домене отсутствуют традиционные записи SPF, DKIM и DMARC, проверка записей не передает достаточно сведений о состоянии проверки подлинности. Поэтому корпорация Майкрософт разработала алгоритм неявной проверки подлинности электронной почты. Этот алгоритм объединяет несколько сигналов в одно значение, которое называется многофакторной аутентификацией, или сокращенно compauth. Значение compauth добавляется в заголовок Authentication-Results в заголовках сообщений.

Authentication-Results:
   compauth=<fail | pass | softpass | none> reason=<yyy>

Эти значения описываются в разделе Заголовок сообщения Authentication-results.

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

Почему проверки подлинности электронной почты может быть недостаточно для борьбы со спуфингом

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

  • В отправляющем домене могут отсутствовать необходимые записи DNS, или же они могут быть неправильно настроены.

  • Записи DNS исходного домена настроены правильно, но он не совпадает с доменом в адресе отправителя. SPF и DKIM не требуют использовать домен в адресе отправителя. Злоумышленники или надежные службы могут зарегистрировать домен, настроить для него записи SPF и DKIM и использовать совершенно другой домен в адресе отправителя. Сообщения от отправителей в этом домене пройдут проверку SPF и DKIM.

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

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

Например, для домена fabrikam.com записи SPF, DKIM или DMARC отсутствуют. Сообщения от отправителей в домене fabrikam.com могут не пройти многофакторную аутентификацию (обратите внимание на значение compauth и причину):

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=none
  action=none header.from=fabrikam.com; compauth=fail reason=001
From: chris@fabrikam.com
To: michelle@contoso.com

Если для fabrikam.com настроить запись SPF без записи DKIM, сообщение может пройти многофакторную аутентификацию. Домен, прошедший проверку SPF, соответствует домену в адресе отправителя.

Authentication-Results: spf=pass (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=none
  (message not signed) header.d=none; contoso.com; dmarc=bestguesspass
  action=none header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

Если для fabrikam.com настроить запись DKIM без записи SPF, сообщение может пройти многофакторную аутентификацию. Домен в подписи DKIM соответствует домену в адресе отправителя.

Authentication-Results: spf=none (sender IP is 10.2.3.4)
  smtp.mailfrom=fabrikam.com; contoso.com; dkim=pass
  (signature was verified) header.d=outbound.fabrikam.com;
  contoso.com; dmarc=bestguesspass action=none
  header.from=fabrikam.com; compauth=pass reason=109
From: chris@fabrikam.com
To: michelle@contoso.com

Если домен в записи SPF или подписи DKIM не соответствует домену в адресе отправителя, сообщение может не пройти многофакторную аутентификацию.

Authentication-Results: spf=none (sender IP is 192.168.1.8)
  smtp.mailfrom=maliciousdomain.com; contoso.com; dkim=pass
  (signature was verified) header.d=maliciousdomain.com;
  contoso.com; dmarc=none action=none header.from=contoso.com;
  compauth=fail reason=001
From: chris@contoso.com
To: michelle@fabrikam.com

Решения для добросовестных отправителей, которые отправляют письма без проверки подлинности

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

Настройка проверки подлинности электронной почты для доменов, которыми вы владеете

Этот метод можно использовать для устранения спуфинга внутри организации, а также междоменного спуфинга, если вы владеете несколькими клиентами или взаимодействуете с ними. Он также позволяет устранить междоменный спуфинг, когда сообщения отправляются пользователям в среде Microsoft 365 или третьим сторонам, размещенным другими поставщиками.

Майкрософт не предоставляет подробные рекомендации по реализации для записей SPF, DKIM и DMARC. Однако большой объем информации доступен в Интернете. Существуют также сторонние компании, которые могут помочь вашей организации настроить записи для проверки подлинности электронной почты.

Вы не знаете все источники ваших писем

Многие домены не публикуют записи SPF, так как они не знают все источники сообщений электронной почты. Начните с публикации записи SPF, содержащей все источники электронной почты, о которых вы знаете (особенно при наличии корпоративного трафика), и опубликуйте нейтральную политику SPF ?all. Например:

fabrikam.com IN TXT "v=spf1 include:spf.fabrikam.com ?all"

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

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

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

Настройка разрешенных отправителей непроверенной электронной почты

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

Для внешних доменов поддельный пользователь — это домен в адресе отправителя, а отправляющая инфраструктура — одно из следующих значений:

  • Исходный IP-адрес (разделенный на /24 диапазона CIDR)
  • Организационный домен обратной записи DNS (PTR).
  • Проверенный домен DKIM.

Создание разрешающей записи для пары отправитель-получатель

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

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

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

  • Даже если им не нужно было публиковать записи проверки подлинности в прошлом, они придется сделать это сейчас, если они отправляют электронную почту в корпорацию Майкрософт.

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

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

  • Убедитесь, что указанные ниже расположения (если они используют их) включены в запись SPF:

    • Локальные почтовые серверы.
    • Электронная почта, отправленная SaaS-поставщиком (программное обеспечение как услуга).
    • Электронная почта, отправленная службой размещения в облаке (Microsoft Azure, GoDaddy, Rackspace, Amazon Web Services и т. д.).

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

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

Сведения для поставщиков инфраструктуры (поставщики услуг Интернета, ESP и службы размещения в облаке)

Если вы размещаете электронную почту для домена или предоставляете инфраструктуру для размещения, которая позволяет отправлять почту, выполните указанные ниже действия.

  • Убедитесь, что у ваших клиентов есть документация, в которой объясняется, как пользователи могут настраивать записи SPF.

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

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

Дополнительные сведения о рекомендациях поставщиков услуг см. в статье M3AAWG: Рекомендации по обмену мобильными сообщениями для поставщиков услуг.

Подробнее о том, как Office 365 использует SPF и поддерживает проверку подлинности DKIM: