Проверка SPF в Exchange: как проверить, опубликовать и исправить записи SPF в Exchange

В мае 2025 года Microsoft начала отклонять электронные письма от отправителей с большим объемом рассылки, у которых отсутствовали действительные настроек SPF, DKIM и DMARC. Если ваш домен отправляет более 5 000 сообщений в день на Outlook.com или Hotmail.com без надлежащей аутентификации, эти сообщения никогда не попадают в папку «Входящие».

Google и Yahoo ввели аналогичные требования в феврале 2024 года. По данным команды Google по безопасности электронной почты, тот ранний этап внедрения этих мер позволил сократить количество неаутентифицированных сообщений, получаемых пользователями Gmail, примерно на 75%.

Согласно отчету ФБР IC3 о киберпреступлениях за 2023 год. 

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

В этом руководстве рассказывается о том, как проверить запись SPF для Exchange с помощью четырёх методов, как опубликовать правильную запись для Exchange Online, локальных и гибридных конфигураций, а также как исправить наиболее распространённые ошибок SPF (включая ограничение в 10 запросов, которое нарушает работу SPF в большинстве средних компаний), как Exchange Online на самом деле оценивает SPF «под капотом», и как постоянно отслеживать SPF, а не проверять его один раз и забывать об этом.

Как проверить SPF-запись вашего хостинга (пошаговая инструкция)

Существует четыре надежных способа проверить ваш запись SPF, от самого быстрого до самого полного. Используйте метод 1 для быстрой проверки, метод 4 — для постоянного мониторинга работоспособности.

Способ 1: Использование инструмента поиска SPF (самый быстрый способ)

1. Откройте любой инструмент проверки SPF (например, PowerDMARC SPF Checker бесплатен и не требует регистрации)
2. Введите свой домен (например, yourdomain.com, без префикса http://) и 
3. Просмотрите результаты

Запрос возвращает несколько результатов проверки SPF. Ниже приведено объяснение значения каждого поля результатов и рекомендации, на что следует обратить внимание при их просмотре: 

Запись может быть корректно проанализирована, а количество совпадений может составлять шесть, но при этом может отсутствовать действительный источник отправки. Проверка SPF проверяет данные в DNS, но не знает, какие IP-адреса должны быть авторизованы.

Способ 2: Проверка через Центр администрирования Microsoft 365

Войдите в центр администрирования Microsoft 365. Перейдите в раздел «Настройки» → «Домены» → выберите свой домен → «Записи DNS». В разделе «Microsoft Exchange» убедитесь, что статус записи TXT отображается как «OK».

Если в поле «Статус» отображается сообщение «Неверный запись», это означает, что ваша запись SPF либо отсутствует, либо не содержит обязательного указания include:spf.protection.outlook.com. Это самый быстрый способ проверить SPF, не выходя из портала администратора.

Способ 3: Проверка через командную строку (nslookup / dig)

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

Выполните одну из следующих команд: 

# Windows

nslookup -type=txt yourdomain.com

# Linux 

/ macOSdig txt yourdomain.com +short

В результате выводится исходная запись в формате TXT. Найдите строку, начинающуюся с v=spf1. Если вы увидите две таких строки, это означает, что у вас есть несколько записей SPF, что сразу же приводит к ошибке PermError. Исправьте это, прежде чем предпринимать какие-либо другие действия.

Способ 4: Проверка с помощью сводных отчетов DMARC (золотой стандарт)

Сводные отчеты от почтовых серверов, таких как Gmail, Yahoo, Microsoft, Mail.ru и региональных интернет-провайдеров, показывают показатели успешности и неудач проверки SPF для всех писем, отправленных с вашего домена, а не только для одного тестового сообщения. Это единственный способ получить актуальную и полную картину состояния SPF.

Если вы публикуете DMARC с тегом rua=, вы уже получаете эти отчеты. У большинства организаций они есть, но лишь немногие их просматривают, поскольку необработанный XML-код невозможно прочитать без специальной платформы для его анализа.

PowerDMARC ежедневно собирает эти отчеты и отображает аналитические данные по SPF на специальной панели инструментов, где представлены показатели успешности/неудачности по каждому источнику отправки, отслеживание DNS-запросов, а также оповещения о появлении новых неавторизованных отправителей.

Способ 5: Проверка с помощью заголовков сообщений Exchange (проверка в реальных условиях)

Чтобы проверить, как SPF оценивается реальным получателем:

• Отправьте тестовое сообщение со своего домена на внешний адрес (подойдет личный аккаунт Gmail).
• Откройте сообщение и выгрузите полные заголовки. В Outlook: «Файл» → «Свойства» → «Заголовки Интернета». В OWA или Gmail: «Просмотреть исходный код» / «Показать исходный текст».
• Найдите заголовок Authentication-Results и найдите поле spf=.

Вот как выглядит соответствующий заголовок с пояснениями:

Результаты аутентификации: 

spf=пройден (IP-адрес отправителя: 40.107.22.83)  

smtp.mailfrom=вашдомен.com;  

dkim=pass (подпись проверена)  

header.d=вашдомен.com;  

dmarc=pass action=none  

header.from=yourdomain.com;  

compauth=pass причина=100

Результат spf=pass подтверждает, что IP-адрес отправителя был авторизован вашей записью SPF. Если вы видите spf=fail, spf=softfail или spf=permerror, конкретный результат укажет вам, в чём заключается проблема:

• spf=fail: IP-адрес отправителя вообще отсутствует в вашей записи SPF.
• spf=softfail: IP-адрес не авторизован, но в вашей записи используется ~all вместо -all.
• spf=permerror: В вашей записи SPF обнаружена структурная ошибка (более 10 запросов, наличие нескольких записей, синтаксическая ошибка).

Как выглядит действительная запись SPF в сервере обмена

Как опубликовать запись SPF для Exchange Online (M365)

Опубликовать запись SPF для Exchange Online несложно. Однако именно на этапе правильного заполнения данных у большинства команд возникают проблемы.

Шаг 1: Определите все свои авторизованные источники отправки

Прежде чем приступать к настройке DNS, проверьте все системы, отправляющие электронную почту от имени вашего домена. Большинство организаций занижают этот список на 30–50 %.

• Microsoft 365 / Exchange Online → включить:spf.protection.outlook.com
• Автоматизация маркетинга (HubSpot, Mailchimp, Marketo, Pardot) → для каждого из них предусмотрен отдельный блок
• CRM (Salesforce, Microsoft Dynamics) → ознакомьтесь с документацией поставщика по SPF
• Транзакционная рассылка (SendGrid, Amazon SES, Postmark, Mailgun) → файлы включения, специфичные для поставщика
• Служба поддержки / система управления заявками (Zendesk, Freshdesk, ServiceNow) → настройки для конкретных поставщиков
• Кадры / расчет заработной платы (BambooHR, Gusto, Workday) → проверьте, отправляются ли уведомления с вашего домена
• Устаревшие локальные серверы → IPv4: с публичными IP-адресами

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

Шаг 2: Создание записи SPF

Начните с тега версии, добавьте авторизованные источники и завершите квалификатором.

Простой пример использования M365:

v=spf1 

включить:spf.protection.outlook.com -all

Типичная компания среднего размера, использующая HubSpot и SendGrid:

v=spf1 

включить:spf.protection.outlook.com 

включить:_spf.hubspot.com 

включить: sendgrid.net -all

Подсчитывайте количество запросов DNS в процессе сборки. Каждый механизм include:, a:, mx:, ptr: и exists: вызывает один запрос. Механизмы ip4: и ip6: не учитываются. Вложенные include: также учитываются, поскольку сам механизм include:spf.protection.outlook.com внутренне потребляет 2–4 дополнительных запроса при прохождении по инфраструктуре Microsoft.

Шаг 3: Опубликовать запись в DNS

Процесс публикации может немного отличаться в зависимости от провайдера DNS, но в целом следует одной и той же схеме:

Настройки, которые следует использовать всегда:

• Тип записи: TXT
• Хост / Имя: @ (или пустое поле, в зависимости от провайдера)
• TTL: 3600 (1 час) во время тестирования, затем 86400 (24 часа) после стабилизации

Важно: Только одна запись SPF на домен. Вторая запись TXT с параметром v=spf1 — это PermError, который только и ждет, когда его обнаружат. Если процесс настройки вашего провайдера DNS автоматически создает запись при добавлении услуги, немедленно проверьте наличие дубликатов.

Шаг 4: Проверьте опубликованную запись

• Подождите 5–60 минут, пока обновления DNS не вступят в силу (в зависимости от значения TTL и провайдера).
• Повторите поиск SPF, как описано в методе 1, чтобы убедиться, что запись разрешается правильно.
• Зайдите в Центр администрирования M365 (способ 2). Статус записи TXT теперь должен отображаться как «OK».
• Отправьте тестовое сообщение на внешний адрес и проверьте, присутствует ли в заголовках строка spf=pass.
• Убедитесь, что количество запросов DNS не превышает 10.

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

SPF для гибридных сред Exchange: локальная инфраструктура + облако

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

Гибридный вызов: два маршрута доставки почты, одна запись SPF

В гибридной среде исходящая почта может отправляться тремя различными способами:

• Прямой доступ к Exchange Online: для почтовых ящиков, размещенных в M365
• Локальные серверы Exchange или Edge Transport: для почтовых ящиков, которые по-прежнему находятся в локальной сети
• «Умные» хосты или сторонние ретрансляторы: когда почта проходит через внешнюю маршрутизацию, прежде чем попасть в общедоступный Интернет

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

Как создать SPF для гибридного обмена

Укажите оба пути авторизации:

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

Локальные IP-адреса — это публичные адреса, которые использует ваш почтовый сервер при отправке сообщений в Интернет, а не внутренние адреса из RFC 1918. Проверьте коннекторы отправки на сервере Edge Transport, а также все правила NAT или брандмауэра, определяющие публичный IP-адрес. Если у вас реализована географическая отказоустойчивость или имеется несколько путей исходящего трафика, в записи должны быть указаны все публичные IP-адреса, с которых может отправляться почта.

SPF во время миграции (переходное состояние)

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

• Перед началом миграции: Убедитесь, что ваша запись SPF охватывает как локальные записи ip4:, так и include:spf.protection.outlook.com.
• Во время миграции: Оставьте обе авторизации в силе. Отслеживайте показатели прохождения SPF с помощью сводных отчетов DMARC. Если изменения в маршрутизации приводят к перенаправлению почты по неожиданным путям, отчеты покажут это раньше, чем пользователи.
• После завершения миграции: Удалите записи on-prem ip4:. Оставление устаревших IP-адресов в SPF представляет угрозу безопасности. Если эти старые IP-адреса будут переназначены вашим интернет-провайдером или поставщиком облачных услуг, новый арендатор сможет отправлять аутентифицированную почту от имени вашего домена.

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

Субдомены в Exchange: настройки SPF не наследуются

Важный момент, который часто становится камнем преткновения для многих гибридных организаций: субдомены не наследуют запись SPF родительского домена. Если домен marketing.yourdomain.com отправляет электронную почту через отдельного поставщика услуг электронной почты (ESP), ему требуется собственная запись SPF типа TXT. Записи SPF с подстановочными знаками не поддерживаются протоколом. Каждый субдомен, отправляющий почту, должен иметь собственную запись v=spf1, опубликованную в корневой зоне DNS.

Это также означает, что использование субдоменов является эффективной стратегией распределения нагрузки на SPF. Направляйте маркетинговую почту через marketing.yourdomain.com, а транзакционную — через mail.yourdomain.com, чтобы каждый субдомен получал свой собственный бюджет из 10 запросов. Такой подход соответствует требованиям RFC, хорошо поддерживается поставщиками услуг электронной почты (ESP) и широко применяется в корпоративных средах.

Проверяет ли Exchange Online SPF для писем внутри одного арендатора?

Нет. Exchange Online рассматривает сообщения внутри одного арендатора как внутреннюю почту и не проводит проверку SPF. Сообщения между разными арендаторами, даже если речь идет о доверенных партнерских организациях, подлежат проверке SPF, поскольку такая почта проходит по общедоступному маршруту передачи.

Для организаций, имеющих несколько доменов в одном арендаторском пространстве M365, каждому домену требуется собственная запись SPF. Использование одной записи для нескольких доменов через CNAME не является стандартной практикой и не обеспечивает надежную работу.

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

Каждый из приведенных ниже сценариев устранения неполадок построен по одной и той же схеме диагностики: симптом → причина → устранение.

PermError: Слишком много запросов DNS

• • Симптом: SPF возвращает PermError. Получатели могут поместить ваше письмо в папку «Спам» или отклонить его. Не удается выполнить согласование DMARC.
  • Причина: Более 10 запросов DNS в записи SPF, включая вложенные включения. Это самая распространенная причина сбоев SPF в организациях, использующих несколько сервисов SaaS.

• Решение (пошаговая инструкция из 5 шагов):

• • Шаг 1: Проверьте текущее количество запросов с помощью SPF-проверки, которая рекурсивно подсчитывает вложенные включения.
  • Шаг 2: Удалите устаревшие включения для служб, которые вы больше не используете.
  • Шаг 3: Заменить include: на ip4: в тех случаях, когда IP-адреса поставщика являются стабильными и задокументированными.
  • Шаг 4: Переместите отправителей с большим объемом трафика, не относящихся к корпоративным (маркетинговые, транзакционные), в субдомены с собственными записями SPF.
  • Шаг 5: Если у вас все еще более 10 записей, внедрите сглаживание SPF или макросы с помощью такого инструмента, как PowerSPF, чтобы автоматически преобразовывать включения в записи ip4 и обновлять запись при смене IP-адресов поставщиками.

Пример «до и после»:

До (14 запросов: PermError):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com include:zendesk.com include:spf.freshdesk.com a mx -all

После (7 запросов: меньше предела):

v=spf1 include:spf.protection.outlook.com include:_spf.hubspot.com include:sendgrid.net ip4:198.2.128.0/24 ip4:192.254.113.0/24 -all# Salesforce и Zendesk перенесены в mail.yourdomain.com# Freshdesk заменен на упрощенные записи ip4# механизмы a и mx удалены (избыточны при явных включениях)

Обнаружено несколько записей SPF

• Симптом: Проверка SPF возвращает ошибку «несколько записей SPF». Все проверки SPF завершаются сбоем.
• Причина: Для одного и того же домена существует две или более записей TXT, начинающихся с v=spf1. Обычно это происходит, когда в процессе настройки поставщик SaaS создает вторую запись, а администратор этого не замечает.
• Исправление: Объедините в одну запись. В одной записи может быть несколько механизмов include: и ip4:, но только одна запись TXT v=spf1 на домен. Удалите лишнюю запись.

SPF перестает работать после добавления нового SaaS-инструмента

• Симптом: Письма, отправленные с помощью недавно добавленного инструмента, не проходят проверку SPF. У других отправителей также могут возникнуть проблемы, если из-за добавления нового инструмента общее количество запросов превысит 10.
• Причина: Новые записи: не были добавлены в SPF, либо их добавление превысило лимит запросов.
• Решение: Добавьте включение, затем повторно проверьте общее количество поисков. Если их количество теперь превышает 10, то проблема заключается в количестве поисков, а не в самом включении. Примените описанный выше 5-шаговый алгоритм действий.

Ошибка SPF в гибридном обмене (отсутствует локальный IP-адрес)

• Симптом: Письма, отправленные из локальной версии Exchange, не проходят проверку SPF, в то время как письма, отправленные из M365, проходят.
• Причина: IP-адрес локального сервера, доступный из внешней сети, отсутствует в записи SPF. Такая ситуация особенно часто возникает после частичной миграции, когда администратор обновил запись SPF для Exchange Online, но забыл, что почта по-прежнему проходит через локальный сервер.
• Решение: Добавьте ip4:x.x.x.x для каждого локального исходящего IP-адреса. Если почта проходит через сервер Edge Transport, смарт-хост или сторонний ретранслятор, необходимо также указать публичный IP-адрес этого ретранслятора.

Сбой SPF после миграции в Exchange Online

• Симптом: После миграции электронные письма повсеместно не проходят проверку SPF.
• Причина: DNS по-прежнему указывает на старые локальные IP-адреса, в том числе: spf.protection.outlook.com не был добавлен, либо почта проходит по неожиданным маршрутам во время перехода.
• Решение: Убедитесь, что запись SPF содержит как старые (локальные), так и новые (Exchange Online) пути авторизации в течение периода миграции. Удаляйте старые записи только после того, как будет подтверждено, что 100% почтовых ящиков перенесены. На протяжении всего процесса отслеживайте ситуацию с помощью сводных отчетов DMARC. Они точно показывают, по каким путям проходит ваша почта с точки зрения получателей.

SPF проходит проверку, но письмо попадает в спам

• Симптом: В заголовках указано spf=pass, но сообщение попадает в папку «Спам» получателя.
• Причина: SPF — это лишь один из многих сигналов. Возможно, не соответствуют требованиям репутация отправителя, содержание, DKIM или DMARC. Любой из этих факторов может перевесить положительный результат проверки SPF.
• Решение: Проверьте соответствие DKIM, политику DMARC, репутацию отправителя (статус в черном списке, возраст домена, недавние изменения объема) и репутацию контента/ссылок. Анализатор доменов PowerDMARC выдает оценку по всем этим параметрам за одно сканирование.

SPF не работает для пересланных писем

• Симптом: Сообщения с автоматической пересылкой, письма из списков рассылки или сообщения, маршрутизируемые по правилам транспорта, не проходят проверку SPF.
• Причина: IP-адрес сервера пересылки отсутствует в записи SPF исходного отправителя. Это архитектурное ограничение SPF, а не ошибка конфигурации.
• Решение: Рассматривайте сбой SPF при пересылке почты как ожидаемое поведение. Убедитесь, что DKIM правильно настроен для вашего домена. Подписи DKIM сохраняются при пересылке, что позволяет DMARC пройти проверку по DKIM даже при сбое SPF. ARC (Authenticated Received Chain) в Exchange Online дополнительно сохраняет результаты аутентификации по всей цепочке доверенных пересылок.

Как Exchange Online на самом деле обрабатывает результаты проверки SPF (разъяснение принципа работы «черного ящика»)

Большинство администраторов Exchange сталкиваются с одной и той же проблемой: как на самом деле Exchange Online Protection (EOP) обрабатывает ошибки SPF? В некоторых источниках утверждается, что «hard fail» означает автоматический отказ. Другие же считают, что SPF является лишь второстепенным сигналом о спаме. Вот как это работает на самом деле.

Многосигнальный конвейер (SPF — лишь один из входов)

Exchange Online Protection не принимает решения о доставке, основываясь исключительно на SPF. SPF является одним из факторов в комплексной оценке аутентификации, которая включает:

• Результат проверки SPF: прошел, не прошел, частично не прошел, нейтральный, PermError или TempError
• Результат проверки DKIM: прошел, не прошел или отсутствует
• Результат проверки DMARC: полученный на основе сопоставления SPF или DKIM с доменом в поле «От» заголовка
• Репутация отправителя: репутация IP-адреса, репутация домена, исторические модели отправки
• Оценка уровня вероятности спама (SCL): внутренняя шкала Microsoft от -1 (безопасный отправитель) до 9 (спам с высокой степенью вероятности)
• Фильтрация контента: ключевые слова, репутация URL-адресов, анализ вложений

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

Как EOP обрабатывает каждый результат SPF

PermError — это серьезный сбой, который EOP трактует практически так же, как полный сбой SPF, и который вызывает цепную реакцию в DMARC, полностью нарушая процесс аутентификации. Именно поэтому ограничение в 10 запросов является структурной точкой отказа.

Где посмотреть результаты SPF в Exchange

Три места, в порядке возрастания полноты:

• Заголовки сообщений (Authentication-Results): Каждое сообщение, обрабатываемое EOP, помечается меткой spf=pass/fail/softfail/permerror/temperror вместе с результатами проверки домена и IP-адреса отправителя.
• Отслеживание сообщений Exchange: Показывает статус доставки, IP-адрес источника, получателя и конечный статус, но не отображает оценку SPF в заметном месте. Если вы полагаетесь только на отслеживание сообщений для проверки SPF, вы действуете вслепую.
• Сводные отчеты DMARC (RUA): Единственный источник данных, который показывает, как получатели по всему миру оценивают ваш SPF. Отчеты RUA отображают показатели успешности и неудач SPF по каждому IP-адресу и источнику на всех серверах-получателях, которые обрабатывают вашу почту.

Настройка принудительного применения режима «Hard Fail» для SPF в EOP

По умолчанию Exchange Online учитывает результаты проверки SPF при расчете совокупной оценки, но не отклоняет письма исключительно на основании SPF. Чтобы явно настроить EOP на пометку сообщения с серьезным нарушением SPF как спам:

В центре администрирования Exchange Online: перейдите в раздел «Защита» → «Фильтр спама» → «Дополнительные параметры» и установите для переключателя «Запись SPF: жесткий отказ» значение «Вкл.». В качестве альтернативы выполните следующий командлет PowerShell:

Get-HostedContentFilterPolicy | Where-Object {$_.IsDefault -eq $true} | Set-HostedContentFilterPolicy -MarkAsSpamSpfRecordHardFail On

Рекомендации по использованию SPF в средах Exchange в 2026 году

• Используйте параметр -all (строгий отказ) в качестве значения по умолчанию. В сочетании с DMARC параметр -all является стандартом. Единственное исключение — период первоначального внедрения, пока DMARC еще не настроен.
• Никогда не используйте параметр +all. Он разрешает всем пользователям Интернета отправлять сообщения от имени вашего домена. Если вы обнаружите параметр +all в своей записи, рассматривайте это как активную угрозу безопасности.
• Для M365 всегда указывайте домен spf.protection.outlook.com, даже если исходящая почта проходит через шлюз стороннего поставщика. Exchange Online генерирует приглашения в календарь, автоответы, уведомления об недоставке (NDR) и подтверждения о прочтении, которые отправляются непосредственно из инфраструктуры Microsoft.
• Проводите проверку записи SPF не реже одного раза в квартал. Поставщики SaaS меняют диапазоны IP-адресов. Маркетинговые отделы внедряют новые инструменты, не сообщая об этом ИТ-отделу. Ежеквартальные проверки позволяют выявить отклонения, прежде чем они приведут к ошибке PermError. Непрерывный мониторинг с помощью отчетов DMARC позволяет выявлять отклонения в режиме реального времени.
• Внедряйте SPF вместе с DKIM и DMARC. Один только SPF не предотвращает подделку поля «From» в заголовке. Один только DKIM не проверяет подлинность отправителя конверта. Только применение DMARC, проверяющее соответствие SPF или DKIM домену в поле «From» заголовка, обеспечивает всестороннюю защиту.
• Соблюдайте требования к отправителям, предъявляемые всеми крупнейшими почтовыми сервисами. В 2026 году Google, Yahoo, Microsoft и Apple будут требовать от массовых рассыльщиков использования SPF + DKIM + DMARC. Стандарт PCI DSS v4.0, обязательный к применению с марта 2025 года, прямо предписывает использование всех трех механизмов в качестве средств защиты от фишинга.

Как осуществлять постоянный мониторинг SPF 

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

Почему разовые проверки SPF создают ложное чувство безопасности

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

Как выглядит непрерывный мониторинг SPF

Четыре компонента, каждый из которых предназначен для устранения конкретного вида неисправности:

• Ежедневно собираются сводные отчеты DMARC от получателей по всему миру. В них представлены результаты проверки SPF по каждому IP-адресу и источнику для всех серверов-получателей, обрабатывавших вашу почту. PowerDMARC автоматически импортирует эти данные и отображает их на специальной панели аналитики SPF, где представлены показатели успешности/неуспешности по источникам, отслеживание количества запросов DNS, а также графики исторических тенденций.
• Автоматические оповещения при превышении порогового значения ошибок SPF, появлении нового неавторизованного источника отправки или при внесении изменений в DNS, затрагивающих вашу запись. PowerAlerts от PowerDMARC перенаправляет их по электронной почте, в Slack или Discord, чтобы нужная команда могла увидеть проблему в рабочее время.
• Автоматическое сглаживание SPF , которая обновляется при смене IP-адресов сторонними провайдерами. PowerSPF преобразует цепочки include: в записи ip4: и постоянно поддерживает количество запросов к вашей записи на уровне менее 10, без необходимости ручного редактирования DNS.
• Мониторинг черных списков и репутации. Если ваши IP-адреса, с которых отправляются письма, попадают в черный список, SPF может пройти проверку, но доставляемость все равно ухудшится. Интегрированный мониторинг репутации выявляет сбои, которые не обнаруживает только SPF.

Специально для MSP: когда поставщик клиента меняет свой диапазон IP-адресов, вы узнаете об этом до того, как у клиента перестанет работать электронная почта. 

Панель управления MSP от PowerDMARC обеспечивает централизованный мониторинг SPF для всех доменов клиентов с одного экрана, с возможностью детализации данных по каждому клиенту. Благодаря этому управление SPF превращается из реактивного устранения неисправностей в полноценную линейку услуг.

Начните 15-дневную бесплатную пробную версию, чтобы самостоятельно оценить сервис. 

Часто задаваемые вопросы

Как проверить записи SPF в Exchange Online?

Воспользуйтесь инструментом проверки SPF, например PowerDMARC SPF Checker, введите свой домен и проверьте запись, синтаксис и количество запросов. Вы также можете проверить это в центре администрирования Microsoft 365 в разделе «Настройки» → «Домены» → «Записи DNS». Для проверки со стороны получателя просмотрите заголовок Authentication-Results в тестовом сообщении, отправленном извне.

Какая запись SPF нужна для Microsoft 365?

Как минимум: v=spf1 include:spf.protection.outlook.com -all. Если вы используете дополнительные службы отправки (HubSpot, SendGrid, Salesforce, Zendesk), добавьте их строки include перед строкой -all. Убедитесь, что общее количество запросов DNS не превышает 10, включая вложенные запросы внутри каждой строки include:.

Почему SPF не работает, хотя моя запись выглядит правильно?

Распространенные причины: превышение ограничения в 10 запросов DNS (PermError), наличие нескольких записей SPF для одного домена, перенаправленные письма (по замыслу SPF не работает при перенаправлении) или изменение поставщиком диапазонов авторизованных IP-адресов без уведомления. Проверьте заголовок Authentication-Results на наличие конкретного результата spf=.

В чём разница между -all и ~all?

-all (жесткий отказ) предписывает получателям отклонять или отклонять сообщения с неавторизованных IP-адресов. ~all (мягкий отказ) является более лояльным. В 2026 году, после внедрения DMARC, политика DMARC будет контролировать соблюдение правил независимо от используемого квалификатора. Если у вас еще нет DMARC, параметр -all обеспечивает значительно более надежную защиту.

Сколько запросов к DNS выполняет домен include:spf.protection.outlook.com?

Включение Microsoft учитывается как один запрос, но оно приводит к цепочке вложенных включений, которые требуют примерно 2–4 дополнительных запроса. Точное число зависит от обновлений инфраструктуры Microsoft. Всегда проверяйте это с помощью инструмента, который рекурсивно подсчитывает вложенные запросы.

Достаточно ли протокола SPF для предотвращения подделки адресов электронной почты?

Нет. Один только протокол SPF не предотвращает подделку видимого адреса «От:» (заголовка «From»). Он проверяет только отправителя конверта (Return-Path). Для всесторонней защиты требуется протокол DKIM для подписи на уровне сообщения, а также протокол DMARC для обеспечения соответствия. Совместное использование всех трех протоколов и их постоянный мониторинг станут стандартом в 2026 году.