Что такое SPF Include и как его использовать в записи SPF?

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

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

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

Запись SPF, или Sender Policy Framework , представляет собой запись DNS типа TXT, в которой перечислены все серверы и IP-адреса, уполномоченные отправлять электронную почту от имени конкретного домена.

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

Чего не могут сделать записи SPF сами по себе

Механизмы SPF являются основополагающими, однако у них есть ограничения, о которых стоит знать:

• Он проверяет отправителя, указанного в поле «Envelope From», а не видимый адрес «From», который фактически видят получатели
• Оно выходит из строя во время пересылке электронной почты, то есть перенаправленные письма часто не проходят проверку SPF, даже если исходный отправитель является легитимным
• Это само по себе не может предотвратить подделку домена на уровне заголовка «От», который является целью большинства фишинговых атак

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

Что такое SPF Include?

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

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

Зачем нужен SPF Include

В настоящее время рассылка электронных писем редко осуществляется с одного сервера.

Большинство организаций используют сочетание собственного почтового сервера и сторонних платформ для рассылки транзакционных писем, проведения маркетинговых кампаний, работы служб поддержки и использования систем управления взаимоотношениями с клиентами (CRM). Каждый из этих сервисов отправляет электронные письма от вашего имени через свою инфраструктуру, используя IP-адреса, которые вы не можете указать напрямую.

Механизм SPF include решает эту проблему, позволяя напрямую ссылаться на запись SPF стороннего сервиса.

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

Как работает SPF Include на практике

Базовый оператор include в SPF выглядит следующим образом:

v=spf1 include:thirdpartydomain.com ~all

В данном примере принимающий сервер найдет запись SPF для домена thirdpartydomain.com и проверит её вместе с остальными вашими записями.

Если IP-адрес отправителя указан в этой записи, электронное письмо проходит проверку SPF для вашего домена.

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

Как работает механизм включения SPF?

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

Процесс проверки SPF

Когда электронное письмо поступает на почтовый сервер-получатель, сервер извлекает домен из адреса MAIL FROM и выполняет поиск в DNS , чтобы получить запись SPF TXT для этого домена. Затем он считывает запись слева направо, оценивая каждый механизм, пока не найдет совпадение или не дойдет до конца записи.

При обнаружении оператора include происходит следующее:

1. Принимающий сервер выполняет дополнительный запрос DNS, чтобы получить запись SPF TXT для указанного домена
2. Он сравнивает запись SPF указанного домена с IP-адресом отправителя
3. Если IP-адрес совпадает с авторизованной записью в списке включений, механизм включения возвращает результат «пропуск»
4. Если совпадение не найдено, сервер продолжает проверять остальные механизмы в исходной записи

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

Каждое указание «include» в записи SPF вызывает как минимум один дополнительный DNS-запрос. Это важно, поскольку при проверке SPF допускается не более десяти DNS-запросов за одну проверку.

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

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

Синтаксис записей SPF: как правильно написать SPF-включение

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

Основная структура записи SPF

Все записи SPF имеют одинаковую базовую структуру:

v=spf1 [механизмы] [квалификатор:все]

• v=spf1 указывает версию SPF и должна находиться в начале каждой записи SPF TXT
• механизмы определяют авторизованные источники отправки, которые могут включать IP-адреса, домены через include, записи MX и т. д.
• «all» — это универсальный механизм, который определяет, что происходит с письмами, не соответствующими ни одному из перечисленных источников

Написание оператора SPF include

Правильный синтаксис оператора include:

включить:domain.com

Обратите внимание, что между словом «include» и двоеточием не должно быть пробела. Пробел приведёт к синтаксической ошибке. Ниже приведён полный пример записи SPF с несколькими включениями:

v=spf1 include:sendgrid.net include:mailchimp.com ip4:192.168.1.1 ~all

В этой записи:

• sendgrid.net и mailchimp.com авторизованы в качестве сторонних отправителей с помощью include
• 192.168.1.1 — это IP-адрес с индивидуальным разрешением
• ~all — это «мягкий отказ», то есть письма из неавторизованных источников будут помечаться, но не отклоняться сразу

Распространенные синтаксические ошибки, которых следует избегать

• Публикация более одной записи SPF TXT для одного и того же домена. Наличие нескольких записей SPF приводит к возникновению цикла DNS-поиска, в результате чего проверка SPF полностью срывается. Необходимо объединить все данные в одну запись на каждый домен или субдомен
• Добавление пробела после двоеточия в операторе include
• Использование некорректных квалификаторов или механизмов, вступающих в противоречие друг с другом
• Забыв завершить запись с помощью механизма all

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

Запись SPF с несколькими включениями: что нужно знать

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

Зачем нужны несколько включений

Большинство организаций отправляют электронную почту через несколько платформ. Типичная конфигурация может включать:

• Основной почтовый сервер для внутренней и исходящей электронной почты
• Сервис рассылки транзакционных писем для подтверждений заказов и уведомлений
• Маркетинговая платформа для рассылок и рекламных кампаний
• CRM-система или инструмент службы поддержки для общения с клиентами

Каждый из этих сервисов должен быть авторизован в вашей записи SPF, и наиболее удобный способ сделать это — использовать операторы include со ссылкой на запись SPF каждого провайдера.

Проблема ограничения количества запросов DNS

Именно здесь использование нескольких включений создаёт риск.

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

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

• включает: sendgrid.net = 1 запрос, плюс любые запросы в пределах собственной записи SendGrid
• включает: mailchimp.com = 1 запрос, плюс все записи в базе данных Mailchimp
• включить: salesforce.com = 1 поиск, плюс любые записи в системе Salesforce
• поиск по mx = 1
• Общее количество может легко достичь или превысить 10

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

Как не превысить лимит запросов DNS

• Проведите аудит вашей текущей записи SPF и подсчитайте общее количество DNS-запросов, которые она вызывает, включая вложенные запросы в рамках включенных записей
• Удалите все операторы include для служб, которые вы больше не используете
• По возможности заменяйте механизмы include прямыми записями IPv4 или IPv6 для служб, диапазоны IP-адресов которых являются статическими и хорошо задокументированными
• Воспользуйтесь инструментом PowerDMARC инструмент сглаживания SPF , который автоматически разрешает цепочки include и заменяет их прямыми IP-адресами, сокращая общее количество запросов
• Регулярно проверяйте свои данные при добавлении или удалении платформы отправки

Одна запись SPF на домен — всегда

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

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

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

Распространенные ошибки при использовании SPF и как их избежать

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

Включение SPF и соответствие требованиям DMARC

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

Как SPF вписывается в DMARC

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

• SPF-проверка прошла успешно, и домен в поле «Envelope» совпадает с доменом в поле «From»
• Проверка DKIM пройдена, и домен, используемый для подписи DKIM, совпадает с доменом, указанным в поле «От кого»

Это означает, что даже правильно настроенной записи SPF со всеми необходимыми включениями само по себе недостаточно. Также должна быть обеспечена совместимость SPF, то есть домен в обратном пути должен совпадать с доменом «От», в соответствии с вашими настройками совместимости DMARC.

Как параметр SPF влияет на выравнивание

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

В данном сценарии проверка DMARC по SPF по-прежнему завершится с ошибкой. Крайне важно настроить сторонний сервис на использование настраиваемого обратного пути под вашим доменом или обеспечить согласованность DKIM в качестве резервного варианта.

Почему одного SPF недостаточно

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

DKIM подписывает само сообщение и сохраняет свою целостность при пересылке. DMARC объединяет обе технологии и обеспечивает вам возможность отслеживать и контролировать ситуацию в случае сбоя любой из них. Настройка всех трёх технологий — единственный способ создать надёжную и отказоустойчивую систему аутентификации электронной почты.

Настройка DMARC вместе с SPF

Если у вас правильно настроены включения SPF, но вы ещё не внедрили DMARC, настройка DMARC — это логичный следующий шаг.

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

Обеспечьте правильную настройку SPF с помощью PowerDMARC

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

Большее количество платформ означает больше включений, больше запросов к DNS и больше возможностей для того, чтобы что-то незаметно вышло из строя в фоновом режиме, и вы не заметили этого, пока не начнёт снижаться доставляемость.

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

Отзыв клиента:

«PowerDMARC помог нам объединить 15 различных почтовых сервисов в одну оптимизированную запись SPF. Доставляемость нашей почты улучшилась на 23 % уже в течение первого месяца». – ИТ-директор, компания из списка Fortune 500, работающая в сфере SaaS

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

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

1. Что произойдет, если количество запросов DNS в моей записи SPF превысит 10?

Если ваша запись SPF требует более 10 запросов к DNS, это приведет к ошибке PermError, в результате чего аутентификация SPF полностью завершится неудачей. Это может привести к тому, что легитимные письма будут отклонены или помечены как спам. Чтобы не превысить этот лимит, используйте сглаживание SPF или макросы.

2. Можно ли указать один и тот же домен несколько раз в записи SPF?

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

3. Как часто следует проверять мои SPF-записи?

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

4. В чём разница между ~all и -all в записях SPF?

~all (softfail) предполагает, что письма из неавторизованных источников должны помечаться как подозрительные, но при этом доставляться. -all (hardfail) предписывает принимающим серверам полностью отклонять письма из неавторизованных источников. Большинство организаций начинают с ~all и переходят на -all после проведения тестирования.

5. Может ли использование SPF повлиять на доставляемость электронной почты?

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

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

Юнес Тарада

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

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

• Сжатие SPF: сокращение количества запросов DNS для SPF и оптимизация записи SPF - 25 марта 2026 г.
• Сертификат проверенной марки и сертификат общей марки: выбор подходящего варианта - 10 марта 2026 г.
• Обход уровня доверия спама (SCL) -1: что это значит и как с этим бороться — 4 марта 2026 г.