Как Microsoft 365 использует инфраструктуру политики отправителей (SPF) для предотвращения спуфинга

Примечание

Хотите попробовать Microsoft 365 Defender? Узнайте больше о том, как оценить и выполнить пилотное Microsoft 365 Defender.

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

Сводка: В этой статье описывается Microsoft 365 использование записи TXT-записи TXT отправительной политики (SPF) в DNS для обеспечения доверия почтовых систем назначения к сообщениям, отправленным из настраиваемого домена. Это относится к исходящие сообщения, отправленные из Microsoft 365. Сообщения, отосланные Microsoft 365 получателю в Microsoft 365 всегда будут передаваться SPF.

Запись TXT инфраструктуры политики отправителей — это запись DNS, которая помогает предотвратить спуфинг и фишинг путем проверки доменного имени, с которого отправляются сообщения. Инфраструктура политики отправителей проверяет источники сообщений, сверяя IP-адрес отправителя с предполагаемым владельцем отправляющего домена.

Примечание

Рабочая группа IETF признала типы записей SPF устаревшими в 2014 г. Вместо них для публикации данных инфраструктуры политики отправителей необходимо использовать записи TXT в службе DNS. Далее в этой статье для простоты используется термин "запись SPF TXT".

Администраторы доменов публикуют данные инфраструктуры политики отправителей в записях типа TXT в DNS. Эти данные позволяют определить уполномоченные серверы исходящей почты. В свою очередь, конечные почтовые системы проверяют, были ли сообщения отправлены уполномоченными серверами исходящей почты. Если вы уже знакомы с SPF или у вас есть простое развертывание, и просто необходимо знать, что включить в запись SPF TXT в DNS для Microsoft 365, вы можете перейти к Настройка SPFв Microsoft 365, чтобы помочь предотвратить спуфинг . Если у вас нет развертывания, полностью размещенного в Microsoft 365, или вы хотите получить дополнительные сведения о том, как работает SPF или как устранить проблемы SPF для Microsoft 365, продолжайте чтение.

Примечание

Раньше, если вы также использовали SharePoint Online, в личный домен нужно было добавить другую запись SPF TXT. Этого больше не требуется. Это изменение необходимо для того, чтобы уведомления SharePoint Online не попадали в папку нежелательной почты. Вам не нужно вносить изменения сразу, но если вы получаете ошибку "слишком много просмотров", измените запись SPF TXT, как описано в настройках SPF в Microsoft 365,чтобы предотвратить спуфинг .

Работа SPF для предотвращения подмены и фишинга в Microsoft 365

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

Каждая запись SPF TXT содержит объявления типа записи, IP-адреса, которым разрешено отправлять сообщения из домена, и внешние домены, которым разрешено отправлять сообщения от его имени, а также правило принудительного применения. В допустимой записи SPF TXT должны присутствовать все три элемента. В этой статье описывается форма записи SPF TXT, а также описаны наилучшие методы работы с Microsoft 365. Кроме того, представлены ссылки на инструкции по работе с регистратором доменов для публикации записей в службе DNS.

Основные сведения об инфраструктуре политики отправителей: IP-адреса, которым разрешено отправлять сообщения из личного домена

Рассмотрим базовый синтаксис правила для инфраструктуры политики отправителей:

v=spf1 <IP> <enforcement rule>

Допустим, для домена contoso.com имеется следующее правило инфраструктуры политики отправителей:

v=spf1 <IP address #1> <IP address #2> <IP address #3> <enforcement rule>

В этом примере правило инфраструктуры политики отправителей разрешает почтовому серверу получать сообщения только со следующих IP-адресов для домена contoso.com:

  • IP-адрес №1

  • IP-адрес №2

  • IP-адрес №3

Это правило инфраструктуры политики отправителей указывает почтовому серверу получателя, что если сообщение поступает из домена contoso.com, но не с одного из этих IP-адресов, то сервер получателя должен применять к этому сообщению правило принудительного применения. Обычно используется одно из следующих правил:

  • Серьезный сбой. В конверт сообщения добавляется отметка "серьезный сбой", а затем соблюдается политика нежелательной почты, настроенная на сервере для этого типа сообщений.

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

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

В следующих примерах показано, как инфраструктура политики отправителей работает в различных ситуациях. В этих примерах contoso.com является отправителем, а woodgrovebank.com — получателем.

Пример 1. Проверка подлинности сообщения электронной почты, отправленного непосредственно от отправителя к получателю

Инфраструктура политики отправителей лучше всего работает с прямыми маршрутами от отправителя к получателю, например:

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

Когда woodgrovebank.com получает сообщение, то оно проходит проверку инфраструктуры политики отправителей и проверку подлинности, если IP-адрес №1 указан в записи SPF TXT для contoso.com.

Пример 2. Поддельный адрес отправителя не проходит проверку инфраструктуры политики отправителей

Допустим, злоумышленнику удалось найти уязвимость в домене contoso.com:

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

Так как IP-адрес №12 не указан в записи SPF TXT для домена contoso.com, сообщение не проходит проверку инфраструктуры политики отправителей, а получатель может отметить его как нежелательное.

Пример 3. Инфраструктура политики отправителей и пересылаемые сообщения

Главный недостаток инфраструктуры политики отправителей состоит в том, что она не работает с пересылаемыми сообщениями. Допустим, пользователь домена woodgrovebank.com настроил правило пересылки, которое отправляет все сообщения в учетную запись outlook.com:

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

Изначально сообщение проходит проверку инфраструктуры политики отправителей в домене woodgrovebank.com, но не проходит ее в outlook.com, так как IP-адрес №25 не указан в записи SPF TXT для домена contoso.com. Затем outlook.com может отметить сообщение как нежелательное. Чтобы обойти эту проблему, используйте инфраструктуру политики отправителей вместе с другими методами проверки подлинности, например DKIM и DMARC.

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

В запись SPF TXT можно добавлять не только IP-адреса, но и домены. Для этого используются операторы include. Например, для домена contoso.com может потребоваться включить все IP-адреса почтовых серверов на доменах contoso.net и contoso.org, которые принадлежат той же организации. Для этого на домене contoso.com публикуется запись SPF TXT следующего вида:

v=spf1 include:contoso.net include:contoso.org -all

Когда принимающий сервер видит эту запись в DNS, он также выполняет DNS-просмотр записи SPF TXT для contoso.net, а затем для contoso.org. Если в записях для contoso.net или contoso.org будет contoso.net или contoso.org, оно будет следовать и этим. Во избежание атак типа "отказ в обслуживании" для одного сообщения допускается не более 10 DNS-запросов. Каждый оператор include представляет дополнительный DNS-запрос. Если в сообщении более 10 таких запросов, оно не проходит проверку инфраструктуры политики отправителей. Как только сообщение достигнет этого предела, в зависимости от способа настройки приемного сервера, отправитель может получить сообщение, в котором говорится, что сообщение создается "слишком много просмотров" или что "максимальное количество переходов для сообщения было превышено" (что может произойти, когда цикл просмотров и превзойти времявыполнения DNS). Рекомендации по устранению неполадок см. в руб. Рекомендации по устранению неполадок для SPF в Microsoft 365.

Требования к записи sPF TXT и Microsoft 365

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

v=spf1 include:spf.protection.outlook.com -all

Если вы полностью размещены, то есть у вас нет локального почтового сервера, который отправляет исходящие сообщения, это единственная запись SPF TXT, которую необходимо опубликовать для Office 365.

Если у вас есть гибридное развертывание (то есть у вас есть некоторые почтовые ящики на месте и некоторые размещены в Microsoft 365), или если вы автономный клиент Exchange Online Protection (EOP) (то есть ваша организация использует EOP для защиты локального почтового ящика), следует добавить исходящий IP-адрес для каждого локального края почтовых серверов к записи SPF TXT в DNS.

Форма записи SPF TXT для Microsoft 365

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

Сведения о доменах, которые необходимо включить для Microsoft 365, см. в дополнительных DNS-записях,необходимых для SPF. Используйте пошаговую инструкцию для обновления записей SPF (TXT) для регистратора домена.

Синтаксис записи SPF TXT для Microsoft 365

Типичная запись SPF TXT для Microsoft 365 имеет следующий синтаксис:

v=spf1 [<ip4>|<ip6>:<IP address>] [include:<domain name>] <enforcement rule>

Например:

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 include:spf.protection.outlook.com -all

где:

  • v=spf1 — обязательный параметр. Он определяет тип записи как SPF TXT.

  • ip4 указывает, что используются IP-адреса версии 4. ip6 указывает, что используются IP-адреса версии 6. При использовании IP-адресов IPv6 ip4 в примерах следует заменить на ip6. Можно также указать диапазоны IP-адресов с использованием нотации CIDR, например ip4:192.168.0.1/26.

  • IP-адрес — это IP-адрес, который необходимо добавить к записи SPF TXT. Обычно это IP-адрес исходящие почтовые серверы для вашей организации. Вы можете перечислить несколько исходящие почтовые серверы. Дополнительные сведения см. в примере: запись SPF TXTдля нескольких исходящие почтовые серверы и Microsoft 365.

  • domain name — это домен, который требуется добавить в качестве надежного отправителя. Список доменных имен, которые необходимо включить для Microsoft 365, см. в статью Внешние записи DNS, необходимые для SPF.

  • Как правило, используется одно из указанных ниже правил принудительного применения.

    • -all

      Указывает на серьезный сбой. Если вам известны все разрешенные IP-адреса для домена, укажите их в записи SPF TXT и используйте квалификатор -all (серьезный сбой). Кроме того, если используется только инфраструктура политики отправителей, то есть не используются DMARC и DKIM, то рекомендуется использовать квалификатор -all. Рекомендуем всегда использовать этот квалификатор.

    • ~all

      Указывает на мягкий сбой. При отсутствии полного списка IP-адресов следует использовать квалификатор ~all (мягкий сбой). Кроме того, если используется DMARC с параметром p=quarantine или p=reject, вы можете использовать квалификатор ~all. В противном случае используйте квалификатор -all.

    • ?all

      Указывает на нейтральное состояние. Этот квалификатор используется при тестировании инфраструктуры политики отправителей. Не рекомендуем использовать его в рабочем развертывании.

Пример: запись SPF TXT для использования, когда вся ваша почта отправляется Microsoft 365

Если вся ваша почта отправляется Microsoft 365, используйте ее в записи SPF TXT:

v=spf1 include:spf.protection.outlook.com -all

Пример: запись SPF TXT для гибридного сценария с одной локальной Exchange Server и Microsoft 365

В гибридной среде, если IP-адрес локального сервера Exchange Server — 192.168.0.1, чтобы настроить правило принудительного применения для инфраструктуры политики отправителей на серьезный сбой, создайте следующую запись SPF TXT:

v=spf1 ip4:192.168.0.1 include:spf.protection.outlook.com -all

Пример: запись SPF TXT для нескольких исходящие почтовые серверы и Microsoft 365

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

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.0.3 include:spf.protection.outlook.com -all

Далее: настройка SPF для Microsoft 365

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

Несмотря на то что инфраструктура политики отправителей призвана предотвратить спуфинг, существуют некоторые методики, которые позволяют обойти ее. Чтобы защититься от них, после настройки SPF необходимо также настроить DKIM и DMARC для Microsoft 365. Чтобы начать работу, см. в этой ссылке Использование DKIM для проверки исходящие сообщения электронной почты, отправленной из настраиваемого домена в Microsoft 365. Затем см. статью Использование протокола DMARC для проверки электронной почты в Microsoft 365.

Устранение неполадок: лучшие практики для SPF в Microsoft 365

Для личного домена можно создать только одну запись SPF TXT. Создание нескольких записей приводит к ситуации циклического перебора и сбою инфраструктуры политики отправителей. Чтобы избежать этого, вы можете создать отдельные записи для каждого поддомена. Например, создайте одну запись для домена contoso.com и еще одну для поддомена bulkmail.contoso.com.

Если перед доставкой сообщения электронной почты выполняется более 10 DNS-запросов, почтовый сервер получателя сообщит о постоянной ошибке ( permerror), а сообщение не пройдет проверку инфраструктуры политики отправителей. Сервер получателя также может отправить отчет о недоставке, включающий ошибку примерно следующего содержания:

  • Превышено максимальное количество прыжков для сообщения.

  • Для сообщения потребовалось слишком много запросов.

Предотвращение ошибки "слишком много смотров" при использовании сторонних доменов с Microsoft 365

Некоторые записи SPF TXT для сторонних доменов поручают серверу получателя выполнять большое количество DNS-запросов. Например, на момент написания этой статьи запись домена Salesforce.com содержит 5 операторов include:

v=spf1 include:_spf.google.com
include:_spfblock.salesforce.com
include:_qa.salesforce.com
include:_spfblock1.salesforce.com
include:spf.mandrillapp.com mx ~all

Чтобы избежать ошибки, вы можете реализовать политику, согласно которой (к примеру) для отправки массовых рассылок все должны использовать специальный поддомен. Затем вы можете задать для поддомена отдельную запись SPF TXT, включающую массовые рассылки.

В некоторых случаях, таких как пример с доменом salesforce.com, необходимо указывать домен в записи SPF TXT, но в остальных случаях сторонний поставщик уже создал поддомен специально для этой цели. Например, для домена exacttarget.com создан поддомен, который необходимо использовать с записью SPF TXT:

cust-spf.exacttarget.com

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

Как просмотреть текущую запись SPF TXT и определить необходимое количество запросов

С помощью команды nslookup можно просматривать записи DNS, включая запись SPF TXT. Для просмотра содержимого записи SPF TXT доступно несколько бесплатных сетевых средств. Просмотрев запись SPF TXT и проследив цепь операторов include, вы можете определить, сколько DNS-запросов требуется для записи. Некоторые веб-средства даже считают и показывают эти запросы. Отслеживание этого номера поможет предотвратить срабатывение постоянной ошибки, называемой пермской ошибкой, от сервера получения сообщений, отправленных из организации.

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

Нужна помощь, чтобы добавить запись TXT инфраструктуры политики отправителей? Ознакомьтесь со статьей Создание записей DNS в любом поставщике DNS-хостинга для Microsoft 365 подробных сведений об использовании системы политики отправитель с настраиваемого домена в Microsoft 365. Заглавы сообщений для борьбы со спамом включают поля синтаксиса и загона, используемые Microsoft 365 проверки SPF.