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

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

Основное назначение SPF — проверка источников электронной почты для домена. В частности, SPF использует запись TXT в DNS для определения допустимых источников почты для домена. Принимающие почтовые системы используют TXT-запись SPF, чтобы проверить, что электронная почта, отправленная с адреса отправителя, используемого во время SMTP-передачи сообщения (известного как адрес MAIL FROM, 5321.MailFrom, отправитель P1 или отправитель конверта), поступает из известного, назначенного источника отправки почты для этого домена.

Например, если домен электронной почты в Microsoft 365 является contoso.com, создайте запись SPF TXT в DNS для домена contoso.com, чтобы определить Microsoft 365 как авторизованный источник почты от contoso.com. Почтовые системы получателя проверяют TXT-запись SPF в contoso.com, чтобы определить, поступило ли сообщение из авторизованного источника для электронной почты домена contoso.com.

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

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

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

  • Рекомендации по поддомену:

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

    • Для каждого поддомена, используемого для отправки электронной почты из Microsoft 365, требуется собственная запись SPF TXT. Например, запись SPF TXT для contoso.com не распространяется на marketing.contoso.com; для marketing.contoso.com нужна собственная запись SPF TXT.

      Совет

      Защита аутентификации электронной почты для поддоменов undefined обеспечивается с помощью DMARC. Все поддомены (определенные или нет) наследуют параметры DMARC родительского домена (которые можно переопределить на поддомен). Дополнительные сведения см. в разделе Настройка DMARC для проверки домена адреса в поле "От" для облачных отправителей.

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

• Одного SPF недостаточно. Чтобы обеспечить наилучший уровень защиты электронной почты для личных доменов, необходимо также настроить DKIM и DMARC в рамках общей стратегии проверки подлинности электронной почты . Дополнительные сведения см. в разделе "Дальнейшие действия " в конце этой статьи.

  Важно!

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

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

Синтаксис для записей SPF TXT

Записи SPF TXT подробно описаны в RFC 7208.

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

v=spf1 <valid mail sources> <enforcement rule>

Или:

v=spf1 [<ip4>|<ip6>:<PublicIPAddress1> <ip4>|<ip6>:<PublicIPAddress2>... <ip4>|<ip6>:<PublicIPAddressN>] [include:<DomainName1> include:<DomainName2>... include:<DomainNameN>] <-all | ~all>

Например, вы можете:

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

• v=spf1 определяет запись TXT как SPF-запись TXT.

• Допустимые источники почты: допустимые источники почты для домена. Использует домены, IP-адреса или и то, и другое:

  • Домены: include: значения указывают другие службы или домены в качестве допустимых источников почты из исходного домена. Эти значения в конечном итоге приводят к IP-адресу с использованием поиска DNS.

    Для большинства организаций Microsoft 365 требуется наличие include:spf.protection.outlook.com в SPF TXT-записи для домена. Другим службам электронной почты сторонних поставщиков часто требуется дополнительное include: значение, чтобы определить службу как допустимый источник электронной почты из исходного домена.

  • IP-адреса. Значение IP-адреса включает оба следующих элемента:

    • Значение ip4: или ip6: для определения типа IP-адреса.
    • Общедоступный IP-адрес исходной почтовой системы. Например, вы можете:
      • Отдельный IP-адрес (например, 192.168.0.10).
      • Диапазон IP-адресов в нотации CIDR (Classless Inter-Domain Routing) (например, 192.168.0.1/26). Убедитесь, что диапазон не слишком велик или слишком мал.

    В Microsoft 365 IP-адреса в записи SPF TXT обычно указывают только в том случае, если у вас есть локально развернутые почтовые серверы, которые отправляют почту от имени домена Microsoft 365 (например, гибридные развертывания Exchange Server). Некоторые почтовые службы, не относящиеся к Microsoft, также могут использовать диапазон IP-адресов вместо значения include: в TXT-записи SPF.

• Правило принудительного применения. Сообщает целевым почтовым системам, что делать с сообщениями из источников, которые не указаны в записи SPF TXT для домена. Допустимые значения:

  • -all (жесткий сбой). Источники, не указанные в записи SPF TXT, не имеют прав на отправку почты для домена, поэтому сообщения должны быть отклонены. То, что на самом деле происходит с сообщением, зависит от целевой почтовой системы, но сообщения обычно удаляются.

    Для доменов Microsoft 365 мы рекомендуем -all (жёсткий отказ), поскольку для этого домена мы также рекомендуем DKIM и DMARC. Политика DMARC указывает, что следует делать с сообщениями, которые завершаются сбоем SPF или DKIM, а отчеты DMARC позволяют проверять результаты.

    Совет

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

  • ~all (мягкий сбой): Источники, не указанные в SPF TXT-записи, вероятно не имеют права отправлять почту от имени домена, поэтому сообщения следует принимать, но помечать. То, что на самом деле происходит с сообщением, зависит от целевой почтовой системы. Например, сообщение может быть помещено в карантин как спам, доставлено в папку "Нежелательная Email" или доставлено в папку "Входящие" с идентификатором, добавленным в тему или текст сообщения.

    Примечание.

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

  • ?all (нейтральный): не предлагает никаких конкретных действий в отношении сообщений из неопознанных источников. Это значение используется для тестирования, и мы не рекомендуем это значение в рабочих средах.

Важные моменты, которые следует помнить:

• Для каждого определенного домена или поддомена в DNS требуется запись SPF TXT, и для каждого домена или поддомена допускается только одна запись SPF. Email защиту проверки подлинности для неопределенных поддоменов лучше всего обрабатывать с помощью DMARC.
• Вы не можете изменить существующую запись SPF TXT для домена *.onmicrosoft.com.
• Когда почтовая система получателя проверяет разрешённые источники отправки электронной почты в записи SPF, проверка SPF завершается ошибкой, если для неё требуется слишком много DNS-запросов. Дополнительные сведения см. в разделе "Устранение неполадок записей SPF TXT".

Записи SPF TXT для личных доменов в Microsoft 365

Сценарий: только электронная почта Microsoft 365

Вы используете contoso.com для электронной почты в Microsoft 365 и Microsoft 365 является единственным источником электронной почты из contoso.com.

• TXT-запись SPF для contoso.com в Microsoft 365 и Microsoft 365 GCC — облаке для государственных организаций:

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

• Запись SPF типа TXT для домена contoso.com в Microsoft 365 Government Community Cloud High (GCC High) и Microsoft 365 Department of Defense (DoD):

  v=spf1 include:spf.protection.office365.us -all
  

• TXT-запись SPF для contoso.com в Microsoft 365 под управлением 21Vianet:

  v=spf1 include:spf.protection.partner.outlook.cn -all
  

Сценарий: Припаркованные домены

Вы являетесь владельцем доменов contoso.net и contoso.org, но не используете их для электронной почты. Вы хотите указать, что никто не имеет прав на отправку электронной почты из contoso.net или contoso.org.

• TXT-запись SPF для contoso.net:

  v=spf1 -all
  

• TXT-запись SPF для contoso.org:

  v=spf1 -all
  

Сценарий: электронная почта Microsoft 365 с локальной электронной почтой и службой электронной почты сторонних поставщиков

Вы используете contoso.com для электронной почты в Microsoft 365. Вы планируете отправлять почту из следующих источников:

• Локальный почтовый сервер с внешним адресом электронной почты 192.168.0.10. Так как вы напрямую контролируете этот источник электронной почты, мы считаем, что можно использовать сервер для отправителей в домене contoso.com.

• Служба массовой рассылки Adatum. Так как у вас нет прямого контроля над этим источником электронной почты, рекомендуется использовать поддомен, чтобы создать marketing.contoso.com для этой цели. Согласно документации по службе Adatum, необходимо добавить include:servers.adatum.com в запись SPF TXT для вашего домена.

  TXT-запись SPF для contoso.com:

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

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

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

Устранение неполадок с записями TXT SPF

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

• Одна запись SPF для каждого домена или поддомена: несколько записей SPF TXT для одного домена или поддомена вызывают возврат permerror SPF (получающая система не может определить, какую запись следует оценить), поэтому используйте только одну запись SPF для каждого домена или поддомена.

• Время жизни (TTL): мы рекомендуем минимальное значение TTL 3600 секунд (один час) для записей SPF TXT, чтобы избежать тайм-аутов DNS-запросов.

• Менее 10 DNS-запросов: когда целевые системы электронной почты запрашивают запись SPF TXT, чтобы определить допустимые источники для домена адреса MAIL FROM, при запросе проверяются IP-адреса и include: операторы в записи, пока источник сообщения (в конечном итоге IP-адрес) не будет сопоставлен с одним из указанных источников. Если число обращений к DNS (которое может отличаться от числа DNS-запросов) превышает 10, сообщение не проходит проверку SPF с постоянной ошибкой (также известной как permerrorpermerror). Почтовая система получателя отклоняет сообщение и отправляет отчет о недоставке (также известный как NDR или сообщение о возврате) с одной из следующих ошибок:

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

  В записи SPF TXT отдельные IP-адреса или диапазоны IP-адресов не вызывают поиск DNS. Каждая инструкция include: требует как минимум одного DNS-запроса, а если значение include: указывает на вложенные ресурсы, может потребоваться больше DNS-запросов. Другими словами, если инструкций include: меньше 10, это не гарантирует, что DNS-запросов тоже будет меньше 10.

  Кроме того, помните: целевые почтовые системы оценивают источники в записи SPF TXT слева направо. Оценка останавливается при проверке источника сообщения и больше не проверяются источники. Таким образом, запись SPF TXT может содержать достаточно информации, чтобы вызвать более 10 поисков DNS, но проверка некоторых источников почты в некоторых местах назначения не проходит достаточно глубоко в записи, чтобы привести к ошибке.

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

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

Что считается DNS-запросом

Следующие механизмы и модификаторы SPF засчитываются как один DNS-запрос:

• include:
• a
• mx
• exists
• redirect

Следующие элементы не засчитываются в лимит из 10 запросов поиска:

• ip4: значения (отдельные адреса или диапазоны CIDR)
• ip6: значения (отдельные адреса или диапазоны CIDR)
• Механизм all

Имейте в виду, что вложенные инструкции include: добавляют дополнительные DNS-запросы сверх прямых DNS-запросов в вашей SPF-записи. Например, элемент include:, указывающий на другую SPF-запись, содержащую ещё три механизма include:, в сумме добавляет четыре DNS-запроса (один для исходного запроса и ещё три для вложенных запросов).

Сократите количество DNS-запросов

Если ваша SPF-запись превышает лимит в 10 DNS-запросов, используйте следующие стратегии, чтобы сократить их количество:

• Замените значения include на IP-адреса: если сторонний поставщик имеет стабильный документированный набор IP-адресов отправителей, замените их инструкцию include: значениями ip4: или ip6:. Этот подход требует отслеживания изменений IP-адресов поставщика.
• Используйте поддомены: перемещение служб электронной почты, отличных от Microsoft, в поддомены. Например, используйте marketing.contoso.com для маркетинговых рассылок с отдельной записью SPF. У каждого поддомена есть собственный лимит в 10 запросов.
• Консолидируйте службы электронной почты: Если возможно, сократите количество служб, отличных от Microsoft, которые отправляют электронную почту от имени вашего домена.

Распространенные синтаксические ошибки в записях SPF

Проверка SPF завершается ошибкой, если запись TXT содержит ошибки форматирования. В следующих примерах показаны распространенные ошибки:

Если домен include: не разрешается или не имеет SPF-записи, проверка SPF возвращает permerror, и сообщения могут быть отклонены. Проверьте include: записи, запрашивая запись DNS TXT для указанного домена.

Выравнивание SPF

Уплощение SPF состоит в замене include: механизмов на соответствующие IP-адреса, чтобы сократить количество DNS-запросов.

Если выравнивание соответствует следующим требованиям:

• Сторонние поставщики со стабильными документированными диапазонами IP-адресов.
• Службы, у которых IP-адреса отправки меняются редко.
• Когда вы приближаетесь к пределу в 10 поисковых запросов или превышаете его, а другие стратегии (поддомены, консолидация) неприменимы.

Когда не следует объединять слои:

• Microsoft 365 (include:spf.protection.outlook.com). инфраструктура отправки Microsoft использует динамические IP-адреса, которые часто изменяются.
• Любая облачная служба с динамическими или часто изменяющимися IP-адресами.

Если вы уплощаете свою SPF-запись:

• Задокументируйте, какие include: записи вы заменили и когда.
• Следите за изменениями IP-адресов в документации поставщика.
• Просматривайте и обновляйте плоские записи не реже одного раза в квартал.
• Проверьте проверку SPF после каждого изменения.

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

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

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

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

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