Что такое v=spf1? Для чего оно предназначено?

Перед вами запись DNS, которая начинается со v=spf1, и вы знаете, что это важно, но изменение этой записи без полного понимания ее значения может нарушить доставку электронной почты по всему вашему домену.

Достаточно одного пропущенного слова «include:», одного лишнего запроса или одной синтаксической ошибки, чтобы письма не прошли аутентификацию, попали в спам или были полностью отклонены

SPF (Sender Policy Framework) — это одна из основных составляющих аутентификации электронной почты. Она указывает принимающим серверам, какие источники имеют право отправлять письма от вашего имени. Тег активирует эту политику, но все, что следует за ним, определяет, будут ли ваши письма доверяться или блокироваться.

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

В этом руководстве подробно объясняется, что именно означает v=spf1 , как устроены записи SPF, как происходит их оценка, а также как создать и поддерживать запись, которая будет работать в реальных условиях.

Как работает оценка SPF

Оценка SPF — это пошаговый процесс проверки, который выполняется при каждом получении электронного письма. В ходе этой проверки определяется, имеет ли сервер-отправитель право отправлять письма от имени домена, указанного в поле Return-Path.

Вот как это работает на практике:

• Получено электронное письмо, якобы отправленное с вашего домена: Сообщение поступает на почтовый сервер получателя с видимыми заголовками (From) и скрытыми данными о маршрутизации (Return-Path).
• Принимающий сервер извлекает домен Return-Path: Именно этот домен проверяет SPF. Он представляет отправителя, использованного при передаче электронного письма.
• Сервер запрашивает у DNS запись SPF (v=spf1): Он ищет запись TXT, опубликованную в этом домене. Если запись SPF отсутствует, результатом будет None (аутентификация не пройдена).
• IP-адрес отправляющего сервера проверяется на соответствие записи SPF: Сервер обрабатывает запись SPF слева направо:
  • Проверяет каждый механизм (ip4, включить, a, и т. д.)
  • Выполняет все необходимые запросы DNS
  • Останавливается на первом подходящем правиле
• На основании совпадения формируется результат: Возможные результаты включают:
  • Пропустить → Отправитель авторизован
  • Ошибка / Мягкая ошибка → Отправитель не авторизован (строгая или мягкая обработка)
  • Нейтральный / Отсутствует → Отсутствует четкая политика или запись SPF
  • Постоянная ошибка / Временная ошибка → Не удалось выполнить проверку SPF из-за ошибок
• Результат объединяется с DKIM и DMARC: Один только SPF не определяет доставку. Принимающий сервер использует его вместе с:
  • DKIM (проверка целостности сообщения)
  • DMARC (соответствие + политика)
    для принятия решения о том, принимать, фильтровать или отклонять сообщение

Что такое запись SPF?

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

Что означает v=spf1?

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

Без этого тега запись вообще не рассматривается как SPF, проверка не выполняется, и домен фактически не имеет защиты SPF.

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

• Он просматривает записи TXT в поисках той, которая начинается со v=spf1
• При оценке SPF учитывается только эта запись
• Все, что следует далее, интерпретируется как правила авторизации (механизмы, квалификаторы, модификаторы)

Чтобы SPF работал правильно, v=spf1 должно соответствовать строгим требованиям:

• Должно находиться в самом начале записи
• Должно быть написано именно так v=spf1 (без опечаток и лишних пробелов)
• Для каждого домена должна существовать только одна запись SPF

Если тег версии содержит какие-либо неточности, вся запись считается неверной:

• Полное отсутствие → SPF возвращает Нет (запись не найдена)
• Ошибка в написании (v=spf 1, v=spf2, v=SPF1) → Неверный синтаксис → PermError
• Если стоит после другого значения → Запись игнорируется как некорректная

Серверы получения не могут интерпретировать вашу политику SPF, в результате чего аутентификация всех писем завершается сбоем.

Структура записи SPF: подробный разбор синтаксиса

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

Запись SPF всегда начинается с тега версии (v=spf1), за которым следует ряд механизмов, определяющих авторизованных отправителей. Эти механизмы могут сочетаться с квалификаторами, которые контролируют, как обрабатываются совпадения, а иногда и с модификаторами, которые корректируют способ оценки записи. Все это помещается в одной строке текста, но каждый элемент напрямую влияет на то, как принимающие серверы интерпретируют электронную почту вашего домена.

Пример записи

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all 

ip4:192.0.2.0/24 (где /24 обозначает диапазон из 256 IP-адресов с использованием нотации CIDR (Classless Inter-Domain Routing))

Для чего нужна каждая деталь

• v=spf1 определяет запись как политику SPF и включает оценку
• ip4:192.0.2.0/24 явно разрешает известный диапазон IP-адресов, как правило, вашей собственной инфраструктуры
• include:_spf.google.com авторизует Google Workspace, ссылаясь на его запись SPF
• добавьте:spf.protection.outlook.com то же самое для Microsoft 365
• -all определяет политику по умолчанию: любой отправитель, не найденный ранее, не допускается

Такое сочетание формирует полную модель авторизации: разрешены только определенные источники, а все остальное запрещено.

Как на самом деле проходит оценка

SPF обрабатывается строго и предсказуемо:

• Принимающий сервер считывает запись слева направо
• Каждый механизм поочередно проверяется по IP-адресу отправляющего сервера
• Как только найден совпадение, оценка немедленно прекращается
• Условие, привязанное к этому механизму, определяет результат

Если ни один механизм не соответствует:

• Этот все механизм выступает в качестве резервного решения

Это означает, что SPF — это не система, в которой «проверяется всё и принимается решение». Это система, в которой побеждает первое совпадение.

Объяснение механизмов SPF

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

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

Механизмы оцениваются по порядку, и результат определяет первый из них, который соответствует IP-адресу отправителя. Это означает, что каждый добавленный механизм влияет как на охват авторизации, так и на сложность оценки.

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

Как работают различные механизмы

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

SPF допускает не более 10 запросов DNS на одну оценку. Механизмы, учитываемые при подсчете этого лимита:

• включают:
• a
• mx
• существует:
• перенаправление=
• ptr

Механизмы, которые не:

• ip4:
• ip6:

Это приводит к следующему компромиссу:

• Удобство (включает:) → более высокая стоимость поиска
• Управление (IPv4/IPv6) → меньшие затраты на поиск, но больше работы по обслуживанию

Объяснение квалификационных турниров SPF

Квалификаторы определяют, какие действия следует предпринять при совпадении механизма. Если механизмы отвечают на вопрос «кому разрешено», то квалификаторы отвечают на вопрос «что должно произойти дальше». Вместе они определяют, насколько строго применяется ваша политика SPF.

Перед каждым механизмом можно указать квалификатор. Если квалификатор не указан, по умолчанию используется значение «pass» (+). Квалификатор напрямую влияет на то, как принимающий сервер интерпретирует совпадение и насколько сильно он доверяет или отвергает сообщение.

Как ведут себя квалификаторы во время оценки

Когда механизм соответствует:

• Прилагаемый к нему квалификатор сразу же определяет результат
• На этом оценка SPF заканчивается
• Затем этот результат используется (наряду с DKIM и DMARC) для принятия решения об обработке сообщения

Это означает, что отборочные матчи являются окончательные сигналы принятия решения в процессе SPF.

Что на самом деле делает каждый квалификатор (в контексте)

В большинстве записей SPF квалификаторы применяются к все в конце для определения политики по умолчанию.

Как обычно используются квалификаторы в записях SPF

Большинство записей SPF используют квалификаторы в одном месте: в all в конце.

• ~все → По умолчанию — мягкое обеспечение соблюдения (этап мониторинга)
• -все → По умолчанию — строгое соблюдение (политика, готовая к использованию в производственной среде)

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

Практические рекомендации

• Начните с ~все во время настройки: Это позволит вам отслеживать результаты SPF, не блокируя при этом легитимных отправителей, которых вы, возможно, пропустили.
• Перейти к -все , как только ваша запись будет готова: После подтверждения, что все допустимые источники включены, переключитесь на hardfail для полного принудительного применения.
• Избегайте ?all :Это не обеспечивает значимой защиты или руководства для принимающих серверов.
• Никогда не используйте +all:  Это позволяет любому отправителю пройти проверку SPF, что фактически отключает аутентификацию для вашего домена.

Объяснение (разъяснение) модификаторов SPF

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

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

Как модификаторы ведут себя при вычислении

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

• Они не совпадают с IP-адресами отправителей
• Они не дают разрешения и не отказывают отправителям напрямую
• Они регулируют расход или результат оценки SPF

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

redirect= – полная делегация оценки SPF

The модификатор redirect= переносит оценку SPF на другой домен.

• Это сообщает принимающему серверу: «Игнорируй остальную часть этой записи и проверь SPF с использованием политики, заданной для другого домена».
• В отличие от включают::
  • включить: добавляет еще одну политику в вашу оценку
  • redirect= полностью заменяет вашу оценку

Пример:

v=spf1 redirect=_spf.example.com

В данном случае:

• Ваш домен не определяет собственные правила SPF
• Вся проверка осуществляется с помощью _spf.example.com

Когда использовать:

• Управление несколькими доменами с помощью централизованной политикой SPF
• Обеспечение согласованности между доменами без дублирования записей

exp= – пользовательское объяснение причин сбоев

The модификатор exp= модификатор предоставляет понятное для человека объяснение в случае сбоя SPF.

• Она указывает на запись DNS, содержащую текстовое сообщение
• Это сообщение может быть отправлено обратно на сервер-отправитель в случае сбоя

Пример:

v=spf1 -all exp=explain._spf.example.com

Это позволяет вам задать собственное пояснение, например:

• Почему отправка сообщения не удалась
• Что следует сделать отправителю дальше

Как создать запись SPF

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

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

• Начните с v=spf1: Это активирует SPF для вашего домена. Без этого запись игнорируется и аутентификация не происходит.
• Добавьте собственную инфраструктуру отправки (ip4: / ip6:): Включите все серверы, которые вы контролируете напрямую, например серверы транзакционной почты или внутренние системы. Эти записи являются наиболее надежными, поскольку не зависят от внешних DNS-запросов.
• Добавьте своего основного почтового провайдера (включить:): Если вы используете такую платформу, как Google Workspace или Microsoft 365, вы должны включить их запись SPF. Это гарантирует, что вся их инфраструктура отправки писем авторизована от вашего имени.

Каждый включает: добавляет как минимум один запрос DNS и может привести к дополнительным вложенным запросам в зависимости от структуры SPF провайдера.

• Добавьте всех сторонних отправителей: Сюда входят маркетинговые инструменты, CRM-системы, платформы поддержки и любые сервисы, которые отправляют электронную почту с использованием вашего домена. Каждый из них должен быть явно авторизован, поскольку SPF не доверяет внешним сервисам автоматически.
• Завершите описание своей политики (~все или -все): Здесь определяется, как следует поступать с отправителями, не указанными выше:
  • ~все → принять, но рассматривать как подозрительное (используется во время настройки)
  • -все → отклонять неавторизованных отправителей (используется после полной проверки)
• Опубликовать в виде одной записи DNS типа TXT: SPF допускает только одну запись на домен. Все механизмы должны быть объединены в эту единственную запись.
• Проверка до и после публикации: Проверьте наличие синтаксических ошибок, ограничений поиска и отсутствующих источников. Также проверьте действующую запись DNS, а не только то, что было введено.

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

Такие инструменты, как PowerSPF (Hosted SPF) от PowerDMARC автоматизируют этот процесс путем:

• Не превышайте лимит в 10 запросов
• Автоматическое обновление изменений IP-адресов от провайдеров
• Сокращение количества ошибок, связанных с ручной работой, и объема технического обслуживания

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

Пример записи

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net -all

Что на самом деле делает эта запись

• Разрешает использование выделенного сервера (ip4:203.0.113.5)
• Разрешает Google Workspace (include:_spf.google.com)
• Предоставляет Mailchimp (include:servers.mcsv.net)
• Отклоняет всех отправителей, не указанных явно (-all)

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

Ограничение в 10 запросов

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

• включают:
• a
• mx
• существует:
• перенаправление=
• ptr (устарело, но при использовании по-прежнему учитывается)

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

Что НЕ учитывается

Они оцениваются напрямую и не вызывают DNS-запросов:

• ip4:
• ip6:
• все
• v=spf1

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

Как увеличивается количество запросов

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

Хотя их всего четыре включают: механизмы, общее количество обращений может превысить ограничение в 10 обращений после оценки вложенных записей.

Ограничение на поиск по пустому значению (часто упускается из виду)

SPF устанавливает не только ограничение на 10 запросов к DNS, но и ограничение на два неудачных запроса.

Поиск по пустому запросу происходит в том случае, когда DNS-запрос не возвращает результатов, например, при получении ответа «Несуществующий домен» (NXDOMAIN) или пустого ответа DNS.

Поиск по пустому запросу происходит в том случае, когда DNS-запрос не возвращает результатов, например, при получении ответа «Несуществующий домен» (NXDOMAIN) или пустого ответа DNS.

Общие причины:

• К ним относятся включают: домены
• Опечатки в механизмах SPF
• Ссылки на домены, которые больше не существуют

Если в ходе проверки SPF происходит более двух неудачных попыток поиска:

• SPF возвращает PermError
• Проверка SPF завершилась сбоем
• У законных электронных писем может отсутствовать аутентификация

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

Не знаете, сколько запросов к DNS использует ваша запись SPF? 

Такие решения, как SPF Analytics и Reporting от PowerDMARC предоставляют:

• Отслеживание всех источников отправки и IP-адресов (в том числе вложенных)
• Выявление проблем, связанных с ограничениями поиска, и ошибок в настройках
• Четкая диагностика с конкретными рекомендациями по устранению неполадок

Это поможет вам лучше понять, как на самом деле работает ваша запись SPF и в каких аспектах она требует оптимизации.

Заключение

SPF — это контрольный уровень, который определяет, кто может отправлять электронные письма с использованием вашего домена. Параметр Тег запускает этот процесс, но надежность вашей настройки зависит от того, насколько хорошо запись создана, поддерживается и находится в пределах допустимого.

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

Чтобы функция SPF работала должным образом:

• Ведите точные и лаконичные записи
• Регулярно проверяйте источники отправки
• Не превышайте лимиты поиска
• Проверка изменений до и после публикации

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

Не ждите, пока ошибки SPF нарушат доставку вашей почты.

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

Узнайте, как легко контролировать и управлять SPF с помощью PowerDMARC.

Вопросы и ответы

1. Что произойдет, если моя запись SPF отсутствует или не настроена?

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

2. Можно ли создать на моем домене более одной записи SPF?

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

3. Как проверить, верна ли моя запись SPF?

Вам необходимо проверить три вещи:

• Синтаксис правильный (без опечаток и ошибок форматирования)
• Включены все законные источники отправки
• Количество запросов DNS не превышает установленный лимит в 10 запросов

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

4. В чём разница между SPF Pass, Fail и PermError?

• Пропустить → Отправляющий сервер авторизован
• Ошибка / Мягкая ошибка → Отправитель не авторизован (строгая или мягкая обработка)
• PermError → SPF не работает из-за неправильной настройки (например, слишком много запросов, неверный синтаксис)

Ошибка PermError является самой серьезной, поскольку означает, что проверка SPF вообще невозможна.

5. Нужен ли мне SPF, если у меня уже есть DKIM и DMARC?

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

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

Само по себе это не поможет. SPF проверяет только домен в поле Return-Path, а не видимый адрес в поле «От». Злоумышленник по-прежнему может подделать заголовок «От» и обойти проверку SPF, используя свой собственный домен. Для обеспечения соответствия и предотвращения подобных ситуаций необходимо использовать DMARC.

• О сайте
• Последние сообщения

Ахона Рудра

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Аона - менеджер по маркетингу в PowerDMARC, имеет более чем 5-летний опыт написания статей на темы кибербезопасности, специализируясь на безопасности доменов и электронной почты. Ахона получила диплом о высшем образовании по специальности "Журналистика и коммуникации", а с 2019 года начала работать в сфере безопасности.

Последние сообщения Ахона Рудра (см. все)

• Что такое v=spf1? Для чего оно предназначено? - 5 мая 2026 г.
• Пример внедрения DMARC у MSP: как Digital Infinity IT Group оптимизировала управление DMARC и DKIM для клиентов с помощью PowerDMARC - 21 апреля 2026 г.
• Что такое DANE? Объяснение аутентификации именованных объектов на основе DNS (2026) - 20 апреля 2026 г.