Как добавить IP-адрес в запись SPF (пошаговое руководство)

Чтобы добавить IP-адрес в запись SPF, отредактируйте существующую запись SPF TXT для вашего домена в DNS и вставьте механизм ip4: (или ip6:) перед механизмом all. Например:

v=spf1 ip4:192.0.2.1 include:_spf.google.com -all

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

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

Что такое запись SPF и почему она важна в 2026 году?

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

Google приступил к внедрению требования по аутентификации массовых отправителей в феврале 2024 года, требуя использования SPF или DKIM в сочетании с DMARC для всех, кто отправляет более 5 000 сообщений в день. 

С ноября 2025 года письма, не соответствующие требованиям, будут подвергаться не временной отсрочке, а постоянному отклонению — т. е. будут возвращаться с кодом ошибки 550. Yahoo ввела аналогичные требования в те же сроки. Microsoft последовала их примеру в мае 2025 года, полностью отклоняя неавторизованные массовые рассылки с ошибкой 550.

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

Объяснение синтаксиса записей SPF (с примерами)

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

v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all

Вот три реальных примера, отражающих разные уровни сложности:

Простой вариант (один почтовый сервер):

v=spf1 ip4:198.51.100.25 -all

Типичная компания малого и среднего бизнеса (Microsoft 365 + один маркетинговый инструмент):

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

Комплексное предприятие (предоставление нескольких видов услуг):

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all

Нужно создать запись с нуля? 

Использование бесплатного генератора записей SPF от PowerDmarc для мгновенного создания синтаксически корректной записи.

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

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

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

Шаг 1: Найдите свою текущую запись SPF

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

Вы можете проверить свои текущие данные двумя способами. 

Использование бесплатного инструмента проверки SPF от PowerDMARC для получения мгновенного визуального результата или запустите запрос из командной строки:

nslookup -type=TXT yourdomain.com

просмотреть запись TXT вашдомен.com

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

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

Шаг 2: Определите IP-адрес или введите значение, которое необходимо добавить

Здесь возможны два варианта, и правильный выбор зависит от того, что именно вы авторизуете:

Вариант A: Вы добавляете конкретный IP-адрес. Это применимо, если вы используете собственный почтовый сервер со статическим IP-адресом или у вас есть выделенный IP-адрес для отправки, который вы контролируете. Вам понадобится точный IPv4- или IPv6-адрес сервера.

Вариант B: Вы авторизуете сторонний сервис. Это относится к таким сервисам, как Mailchimp, SendGrid, HubSpot, Google Workspace или Microsoft 365. В этом случае вам нужно значение include: из документации данного сервиса, а не его IP-адреса.

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

Шаг 3: Измените запись SPF в DNS

Войдите в личный кабинет у своего провайдера DNS (регистратора домена или хостинг-провайдера), найдите записи TXT для своего домена и отредактируйте существующую запись SPF. Добавьте новый механизм ip4: или include: ПЕРЕД механизмом all.

Вот как это сделать у наиболее популярных провайдеров:

• Cloudflare: Перейдите в раздел «DNS» → «Записи». Найдите существующую запись TXT для вашего домена (@ или корневой), которая начинается с v=spf1. Нажмите «Изменить». Добавьте новый механизм перед тегом all. Нажмите «Сохранить».
• GoDaddy: Перейдите в раздел «Мои продукты» → «DNS» → «Записи DNS». Найдите запись TXT, содержащую v=spf1. Нажмите «Изменить». Измените поле «Значение», добавив новый механизм перед словом «all». Сохраните изменения.
• Namecheap: Перейдите в «Список доменов» → «Управление» → «Расширенный DNS». В разделе «Записи TXT» найдите запись SPF. Отредактируйте ее, чтобы добавить новый механизм. Сохраните.
• AWS Route 53: Откройте «Хостируемые зоны» → выберите свой домен → найдите запись TXT с v=spf1. Нажмите «Изменить». Обновите значение (сохраните кавычки). Сохраните.
• cPanel: Перейдите в раздел «Доставка электронной почты» → нажмите «Управление» рядом с вашим доменом → прокрутите страницу до раздела «Рекомендуемая запись SPF» → нажмите «Настроить». Добавьте новый IP-адрес в разделе «IP-адрес». Нажмите «Установить».

Шаг 4: Проверьте правильность обновленной записи SPF

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

Проверяйте этот контрольный список после каждого изменения SPF:

1. Проверьте свой домен с помощью инструмента проверки SPF и убедитесь, что запись обрабатывается без ошибок.
2. Убедитесь, что вы видите только ОДНУ запись SPF (а не две записи TXT, начинающиеся со строки v=spf1).
3. Проверьте общее количество запросов DNS. Оно должно быть не более 10.
4. Убедитесь, что весь механизм находится в самом конце записи.
5. Отправьте тестовое письмо на адрес Gmail или Yahoo, откройте сообщение, просмотрите исходные заголовки и найдите строку spf=pass.

Чтобы провести полный аудит безопасности, выходящий за рамки SPF, проверьте свой домен с помощью анализатора доменов PowerDMARC. Он проверяет SPF, DKIM, DMARC, MTA-STS и BIMI за один проход.

Шаг 5: Отслеживание результатов аутентификации SPF в динамике

Добавление IP-адреса — это первый шаг. Убедиться, что он действительно работает, и вовремя обнаружить сбои в его работе — это второй шаг.

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

ip4 или include: что выбрать? (Руководство по выбору)

Когда использовать IPv4 (необработанные IP-адреса):

• Вы используете собственный почтовый сервер, подключенный к статическому IP-адресу, который находится под вашим контролем.
• У вас есть выделенный IP-адрес для отправки от вашего собственного поставщика услуг электронной почты (не общий).
• Вы настраиваете локальный SMTP-ретранслятор с фиксированным адресом.

Правило: используйте ip4: только в том случае, если ВЫ контролируете IP-адрес и он не изменится.

Когда использовать include: (делегированный SPF):

• Вы предоставляете доступ любому стороннему сервису SaaS, например Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, Salesforce, Zendesk или любому облачному почтовому сервису.
• Сервис использует общие или сменяемые IP-адреса.
• Сервис публикует собственную запись SPF, которую он поддерживает.

Почему стоит использовать: почти всегда лучше для сторонних сервисов:

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

Механизм «include:» перенаправляет запрос на собственную запись SPF службы, которая обновляется динамически. Когда они обновляют свои IP-адреса, ваша запись SPF автоматически отражает эти изменения, и вам не нужно ничего делать.

[Изображение: Блок-схема в виде дерева решений — «Является ли это сервером/IP-адресом, которым вы владеете и который вы контролируете?» → ДА → Использовать ip4 / НЕТ → «Предоставляет ли сервис значение include:?» → ДА → Использовать include (предпочтительно) / НЕТ → Использовать ip4 + установить напоминание о ежеквартальной проверке]

[Альтернативный текст: Блок-схема, показывающая, когда следует использовать IPv4, а когда — механизм include в записях SPF]

Чтобы подробнее ознакомиться с синтаксисом include и рекомендациями по его использованию, ознакомьтесь с полным руководством по SPF include.

Распространенные значения SPF в списках доверенных сторон (краткая справочная таблица)

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

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

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

Ограничение в 10 запросов DNS и что делать, если оно исчерпано

Согласно RFC 7208, при оценке SPF учитываются не более 10 механизмов запроса DNS. Учитываются следующие механизмы: include, a, mx, redirect и exists. Не учитываются следующие механизмы: ip4, ip6 и all. Они оцениваются локально без отправки запроса DNS.

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

Существует также менее известное ограничение: ограничение на количество запросов с нулевым результатом (2-void-lookup). Если в ходе проверки SPF более двух DNS-запросов возвращают код NXDOMAIN (домен не найден), проверка SPF также завершается сбоем.

Вот три способа решить эту проблему, упорядоченные по степени практичности:

Вариант 1: Удаление неиспользуемых механизмов

Начните с проверки. Удалите операторы `include:` для служб, которыми вы больше не пользуетесь. Удалите записи `A` и `MX`, если вы не отправляете электронную почту с IP-адресов, указанных в записях `A` или `MX` вашего домена. Это самое быстрое решение, которое зачастую сразу же освобождает 2–3 запроса.

Вариант 2: Ручное сглаживание SPF

Разобьёте ваши включения: определите механизмы вплоть до лежащих в их основе IP-адресов и жестко задайте их в виде записей ip4:. Это позволит исключить запросы к DNS, которые потребовались бы для этих включений.

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

Вариант 3: Макросы SPF или автоматическое сглаживание

В современном подходе используются макросы SPF (определенные в RFC 7208, §7), которые динамически расширяются при оценке, что позволяет удержать размер записи в пределах допустимого лимита без необходимости ручного обновления IP-адресов. 

Автоматизированные инструменты для выравнивания адресов постоянно занимаются этим, повторно определяя IP-адреса провайдеров по расписанию и обновляя вашу опубликованную запись.

Одного SPF недостаточно: почему DKIM и DMARC дополняют картину

SPF сверяет IP-адрес отправителя (MAIL FROM) с вашим списком авторизованных адресов. Это работает, когда письмо отправляется напрямую от отправителя к получателю, но при пересылке — через списки рассылки, правила автоматической пересылки, общие почтовые ящики или любой ретранслятор — IP-адрес отправителя меняется. В этом случае SPF перестает работать, поскольку IP-адрес сервера пересылки отсутствует в вашей записи SPF и не должен там находиться.

DKIM (DomainKeys Identified Mail) работает по-другому. Он прикрепляет криптографическую подпись к тексту письма. Эта подпись сохраняется при передаче сообщения независимо от того, через какой сервер оно проходит. DKIM сохраняется при пересылке, а SPF — нет.

DMARC (Domain-based Message Authentication, Reporting, and Conformity) объединяет эти механизмы. Для того чтобы сообщение прошло проверку DMARC, достаточно, чтобы прошел только ОДИН из механизмов — SPF или DKIM — и его результаты совпадали с вашим доменом отправителя. 

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

Вот почему важно иметь и то, и другое:

• Google требует наличия SPF или DKIM для всех отправителей, а также DMARC для массовых рассылок (более 5 000 сообщений в день). С ноября 2025 года сообщения, не соответствующие этим требованиям, будут окончательно отклоняться.
• В мае 2025 года компания Microsoft начала отклонять неавторизованные массовые рассылки.
• Yahoo предъявляет те же требования в те же сроки, что и Google.

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

Что делать дальше:

1. Настройте DKIM для всех сервисов, которые отправляют электронные письма с вашего домена.
2. Опубликуйте запись DMARC (начните с параметра p=none для мониторинга, а затем перейдите к p=reject).
3. Отслеживайте сводные отчеты DMARC, чтобы узнать, какие источники проходят проверку SPF и DKIM, а какие — нет.

Записи SPF для доменов, которые не отправляют электронную почту

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

Решение очень простое. Опубликуйте следующую запись SPF:

v=spf1 -all

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

Для обеспечения максимальной защиты также опубликуйте запись DMARC с политикой отклонения:

v=DMARC1; p=reject; rua=mailto:[email protected]

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

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

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

Таблица: Наиболее распространённые ошибки в записях SPF, их последствия и способы их устранения.

Чтобы подробнее узнать о том, как устранять ошибки проверки SPF, ознакомьтесь с нашим руководством по ошибкам проверки SPF и способам их устранения.

Заключение

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

SPF — это один из уровней комплексной системы аутентификации электронной почты. В 2026 году, с Google, Yahoo и Microsoft будут активно вводить обязательные требования к аутентификации отправителей, одного SPF будет недостаточно. DKIM и DMARC не менее важны для полной защиты и соблюдения нормативных требований.

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

Хватит управлять записями SPF вручную. PowerDMARC предлагает автоматическое упрощение SPF (PowerSPF), мониторинг DMARC, управление DKIM и наглядную отчетность по всем вашим доменам — и все это на одной платформе. Начните 15-дневную бесплатную пробную версию 

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

1) Можно ли создать две записи SPF для одного и того же домена?

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

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

-all — это жесткий отказ, который предписывает принимающим серверам отклонять письма с неавторизованных IP-адресов. ~all — это мягкий отказ, который помечает неавторизованные письма, но не обязывает их отклонять. На практике, когда DMARC применяется с параметрами p=quarantine или p=reject, разница минимальна, поскольку политика DMARC имеет приоритет над квалификатором SPF. Если у вас настроен DMARC в режиме принудительного применения, подойдет любой из вариантов. Если у вас пока нет DMARC, параметр -all обеспечивает более надежную защиту.

3) Сколько IP-адресов можно добавить в запись SPF?

Жесткого ограничения на количество механизмов ip4: или ip6: нет. Они не учитываются при подсчете лимита в 10 запросов DNS. Однако общий объем записи SPF должен укладываться в ограничения по размеру записи DNS TXT (255 символов на строку, при этом несколько строк могут быть объединены в одну длиной до примерно 4 096 символов). Для больших списков IP-адресов используйте нотацию CIDR (например, ip4:192.0.2.0/24), чтобы эффективно охватить диапазоны.

4) Сколько времени требуется, чтобы изменения SPF вступили в силу?

Это зависит от значения TTL (Time to Live) вашей записи DNS. Если значение TTL равно 3600 (1 час), большинство серверов преобразования имен обновят данные в течение 1 часа. Чтобы ускорить процесс: перед внесением изменений уменьшите значение TTL до 300 (5 минут), дождитесь истечения срока действия старого значения TTL, а затем внесите изменения. Это значительно сокращает время распространения изменений.

5) Как узнать, с каких IP-адресов в данный момент отправляются письма с моего домена?

Наиболее надежным методом является отчетность DMARC. Когда вы публикуете запись DMARC с тегом rua, принимающие серверы ежедневно отправляют сводные отчеты, в которых перечислены все IP-адреса, с которых предпринимались попытки отправки писем с вашего домена, а также результаты проверки SPF и DKIM (прошел/не прошел). Без DMARC вам приходится только гадать. PowerDMARC преобразует эти отчеты в понятные и удобные для восприятия панели мониторинга, благодаря чему вы можете точно видеть, кто отправляет письма с вашего домена.

6) Включаются ли механизмы IPv4 и IPv6 в ограничение на 10 запросов DNS?

Нет. В лимит учитываются только те механизмы, которые требуют DNS-запроса: include, a, mx, redirect и exists. Механизмы ip4, ip6 и all обрабатываются локально и не требуют DNS-запросов.

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

Ахона Рудра

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

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

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

• Как добавить IP-адрес в запись SPF (пошаговая инструкция) - 11 мая 2026 г.
• Запись SPF Avanan: как настроить, исправить и оптимизировать SPF для почтовой системы Check Point Harmony - 7 мая 2026 г.
• Запись SPF в DNS: как она работает и как её настроить - 6 мая 2026 г.