Настройка SPF для предотвращения спуфинга

  • Статья

В этой статье описывается, как обновить запись службы доменных имен (DNS), чтобы вы могли использовать проверку подлинности электронной почты платформы политики отправителей (SPF) с личным доменом в Office 365.

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

Предварительные условия

Важно!

Если вы являетесь небольшим бизнесом или не знакомы с IP-адресами или конфигурацией DNS, позвоните своему регистратору доменов в Интернете (например, GoDaddy, Bluehost, web.com) & попросите помощь с настройкой DNS SPF (и любым другим способом проверки подлинности электронной почты).

Если вы не используете настраиваемый URL-адрес (а URL-адрес, используемый для Office 365 заканчивается на onmicrosoft.com), инфраструктура политики отправителей уже настроена для вас в службе Office 365.

Итак, приступим!

Запись SPF TXT для Office 365 будет сделана во внешней службе DNS для любых пользовательских доменов или поддоменов. Для записи необходимы некоторые сведения. Подготовьте указанные ниже данные.

  • Запись SPF TXT для личного домена, если он существует. Инструкции см. в статье Сбор необходимых сведений для создания DNS-записей Office 365.

  • Перейдите на свой сервер обмена сообщениями и найдите внешние IP-адреса (требуются со всех локальных серверов обмена сообщениями). Например, 131.107.2.200.

  • Доменные имена, используемые для всех сторонних доменов, которые требуется включить в запись SPF TXT. Некоторые поставщики массовых рассылок настраивают поддомены для своих клиентов. Например, компания MailChimp создала поддомен servers.mcsv.net.

  • Определите, какое правило принудительного применения следует использовать для записи SPF TXT. Рекомендуется использовать правило -all. Подробные сведения о других вариантах команд см. в разделе Синтаксис записи SPF TXT для Office 365.

Важно!

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

Создание или обновление записи SPF TXT

  1. Убедитесь, что вы знакомы с синтаксисом SPF из следующей таблицы.

    Элемент Используемая система Распространенная у клиентов? Добавляемый параметр
    1 Любая почтовая система (обязательно) Распространенная. Все записи SPF TXT начинаются с этого значения v=spf1
    2 Exchange Online Распространенная include:spf.protection.outlook.com
    3 Только для Exchange Online Нераспространенная ip4:23.103.224.0/19
    ip4:206.191.224.0/19
    ip4:40.103.0.0/16
    include:spf.protection.outlook.com
    4 Office 365 Germany, только Microsoft Cloud Germany Нераспространенная include:spf.protection.outlook.de
    5 Сторонняя почтовая система Нераспространенная include:<domain_name>

    <> domain_name является доменом сторонней системы электронной почты.
    6 Локальная система электронной почты. Например, Exchange Online Protection плюс другая система электронной почты Нераспространенная Используйте один из следующих параметров для каждой дополнительной почтовой системы:

    ip4:<IP_address>
    ip6:<IP_address>
    include:<domain_name>

    <> IP_address и <domain_name> — это IP-адрес и домен другой почтовой системы, которая отправляет почту от имени вашего домена.
    7 Любая почтовая система (обязательно) Распространенная. Все записи SPF TXT заканчиваются этим значением <enforcement rule>

    Это может быть одно из нескольких значений. Рекомендуется значение -all.

  2. Создайте запись SPF TXT (если вы еще не сделали этого), используя синтаксис из таблицы.

    Например, если ваша организация целиком размещена в Office 365 (то есть у вас нет локальных почтовых серверов), то в запись SPF TXT будут включены строки 1, 2 и 7, и она будет выглядеть следующим образом:

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

    В примере выше используется наиболее распространенная запись SPF TXT. Эта запись подходит практически для всех, независимо от того, где находится ваш центр обработки данных Майкрософт — в США, Европе (в том числе в Германии) или другом месте.

    Однако если вы приобрели Office 365 Германии, в составе Microsoft Cloud Germany, следует использовать инструкцию include из строки 4 вместо строки 2. Например, если вы размещаетесь полностью в Office 365 Германии, то есть у вас нет локальных почтовых серверов, запись SPF TXT будет включать строки 1, 4 и 7 и будет выглядеть следующим образом:

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

    При переходе с Office 365 на Office 365 Germany необходимо обновить запись SPF TXT для личного домена. Чтобы сделать это, измените include:spf.protection.outlook.com на include:spf.protection.outlook.de.

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

  4. Проверьте свою запись SPF TXT.

Как работать с поддоменами?

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

Для каждого домена и поддомена требуется запись SPF с подстановочным знаком (*.), чтобы помешать злоумышленникам отправлять письма от несуществующих поддоменов. Например:

*.subdomain.contoso.com. IN TXT "v=spf1 -all"

Устранение неполадок инфраструктуры политики отправителей

Возникли проблемы с записью типа TXT инфраструктуры политики отправителей? Прочитайте статью Устранение неполадок: советы и рекомендации по инфраструктуре политики отправителей в Office 365.

Какие действия выполняет проверка подлинности электронной почты инфраструктуры политики отправителей?

Инфраструктура политики отправителей определяет, каким почтовым серверам разрешается отправлять сообщения от вашего имени. Инфраструктура политики отправителей, а также DKIM, DMARC и другие технологии, поддерживаемые Office 365, помогают предотвратить спуфинг и фишинг. Инфраструктура политики отправителей добавляется в виде записи TXT, которую служба DNS использует, чтобы определить, какие почтовые серверы могут отправлять сообщения от имени вашего личного домена. Почтовые системы получателей могут просматривать записи SPF TXT, чтобы определить, было ли сообщение из вашего личного домена отправлено с уполномоченного сервера обмена сообщениями.

Допустим, ваш личный домен contoso.com использует Office 365. Мы добавим запись SPF TXT, в которой перечислены серверы обмена сообщениями Office 365, разрешенные для домена. Когда принимающий сервер обмена сообщениями получает сообщение от joe@contoso.com, сервер ищет запись SPF TXT для contoso.com и выясняет, является ли сообщение допустимым. Если сервер получателя определит, что сообщение отправлено с сервера, не указанного в списке серверов обмена сообщениями Office 365 в записи SPF, то сервер получателя может отклонить сообщение как спам.

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

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

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

  • Используется гибридная среда с Office 365 и локальной службой Exchange.

  • Вы планируете настроить DKIM и DMARC (рекомендуется).

Дополнительные сведения об инфраструктуре политики отправителей

Расширенные примеры, подробное обсуждение поддерживаемого синтаксиса для инфраструктуры политики отправителей и сведения о спуфинге, устранении неполадок и о том, как Office 365 поддерживает инфраструктуру политики отправителей, см. в разделе Как инфраструктура политики отправителей помогает предотвратить спуфинг и фишинг в Office 365.

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

Инфраструктура политики отправителей (SPF) призвана предотвратить спуфинг, но существуют некоторые методики, позволяющие обойти ее. Чтобы защититься от таких атак, по завершении настройки SPF необходимо настроить DKIM и DMARC для Office 365.

Цель проверки подлинности электронной почты DKIM — проверить, что содержимое письма не подделано.

Цель проверки подлинности электронной почты DMARC — убедиться, что сведения SPF и DKIM соответствуют адресу, указанному в поле "От".

Расширенные примеры и подробное обсуждение поддерживаемых команд для инфраструктуры политики отправителей см. в разделе Как инфраструктура политики отправителей помогает предотвратить спуфинг и фишинг в Office 365.

Использование доверенных отправителей ARC для допустимых почтовых потоков

Выберите "Эта страница" в разделе "Отзывы", если хотите оставить отзыв об этой документации.