Как настроить SPF-запись: практический гайд на 2026

Настройка SPF-записи — один из трёх обязательных шагов аутентификации для любого sending-домена в 2026 (вместе с DKIM и DMARC). Выглядит обманчиво просто — одна TXT-запись в DNS — но failure mode’ы конкретны, и большинство команд, настроивших SPF неверно, не обнаруживают проблему, пока placement rate уже не коллапсит. Эта статья проходит по настройке SPF шаг за шагом, с синтаксисом, который имеет значение, типичными ошибками и шагами верификации, ловящими проблемы до того, как они стоят кампаний. Пара к гайду по доставляемости email и обзору SPF/DKIM/DMARC настройки.

SPF (Sender Policy Framework) — DNS-based механизм аутентификации, сообщающий receiving mail-серверам, какие IP-адреса авторизованы шлать email от имени вашего домена. Правильно сконфигурированная SPF-запись уменьшает шанс быть помеченным как спам или отклонённым. Неправильно — слишком много DNS lookup’ов, неверный синтаксис, отсутствующие отправители — активно повреждает доставляемость.

Что реально делает SPF-запись

Когда email приходит на receiving mail-сервер, сервер проверяет “from” домен email’а и ищет SPF-запись этого домена в DNS. SPF-запись содержит список авторизованных отправителей (IP-адресов, hostname’ов или сторонних сервисов). Если sending IP email’а матчит одного из авторизованных отправителей, SPF проходит. Если не матчит, SPF проваливается — и большинство receiving-систем относится к SPF-провалам как к сильному spam-сигналу.

Сама SPF-запись — plain text DNS-запись (TXT-запись) в корне вашего sending-домена. Пример:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Переводится как: “Mail с этого домена авторизован приходить от sending-инфраструктуры Google Workspace или от sending-инфраструктуры Smartlead. Всё остальное должно быть soft-failed”.

Куски, имеющие значение:

• v=spf1 — идентификатор версии; всегда в начале
• include:domain.com — делегировать авторизацию SPF-записи другого домена (самый распространённый механизм)
• a / mx — авторизовать A-запись или MX-запись самого домена
• ip4:1.2.3.4 — авторизовать конкретный IPv4-адрес
• ~all / -all — дефолтный fall-through: ~all — soft-fail (рекомендуется для большинства случаев), -all — hard-fail (строгий)

Пошаговая настройка

Базовый workflow для настройки SPF-записи:

Шаг 1: Идентифицируйте все ваши sending-сервисы. До написания записи перечислите каждый сервис, шлющий email “от” вашего домена. Распространённые: Google Workspace или Microsoft 365 (ваш day-to-day email), cold email тул (Smartlead, Lemlist, Instantly, Apollo), любой транзакционный email-провайдер (SendGrid, Mailgun, Postmark), любой CRM, шлющий email’ы, любой marketing email тул. Пропуск одного означает, что email’ы с того сервиса будут SPF-провалить.

Шаг 2: Получите include: значение для каждого сервиса. Каждый sending-сервис публикует свой SPF include-значение в документации. Примеры (верифицируйте против текущей доки):

• Google Workspace: include:_spf.google.com
• Microsoft 365: include:spf.protection.outlook.com
• Smartlead: include:spf.smartlead.ai (или похожее — check current docs)
• SendGrid: include:sendgrid.net
• Mailgun: include:mailgun.org

Шаг 3: Постройте SPF-запись. Комбинируйте include с версией и fall-through:

v=spf1 include:_spf.google.com include:spf.smartlead.ai ~all

Порядок не строго имеет значение, но держите читаемым.

Шаг 4: Добавьте TXT-запись в DNS. Войдите в DNS-провайдера (Cloudflare, AWS Route53, GoDaddy, Namecheap — что используете), navigate к DNS-записям sending-домена, добавьте новую TXT-запись:

• Host/Name: @ (или оставьте пустым, в зависимости от провайдера — представляет root-домен)
• Type: TXT
• Value: SPF-строка из шага 3
• TTL: дефолт (обычно 3600 секунд / 1 час)

Шаг 5: Дождитесь DNS-пропагации. Обычно 5–60 минут в зависимости от DNS-провайдера и TTL-настроек. Некоторые провайдеры пропагируют в секундах; другие занимают больше.

Шаг 6: Верифицируйте запись. Существуют несколько верификационных тулов. Простейший: dig +short TXT yourdomain.com из терминала. Вы должны увидеть свою SPF-строку. Online-тулы (MXToolbox, SPF checker от DMARC Analyzer) делают то же плюс syntax-валидацию.

Лимит DNS-lookup’ов

Самый распространённый SPF failure mode в 2026: превышение 10-DNS-lookup лимита. Каждый include: механизм считается как один DNS lookup, и include могут иметь nested include, которые тоже считаются. SPF-записи, превышающие 10 lookup’ов, проваливают “permerror” — что большинство receiving-систем относит как SPF-провал.

Распространённые сценарии, превышающие лимит:

• Несколько sending-сервисов с deep include цепочками (SPF Salesforce nest через несколько слоёв; HubSpot тоже)
• Добавление каждого транзакционного сервиса “just in case” без проверки lookup count
• Inheriting старая SPF-запись, включавшая сервисы, больше не используемые

Фикс: считайте свои lookup’ы. Тулы вроде Kitterman SPF Test или MXToolbox SPF Surveyor показывают lookup count. Если вы over 10, нужно flatten или консолидировать.

Flattening означает замену include: механизмов на underlying IP-адреса, которые они авторизовали бы. Тулы вроде SPFlat или PowerDMARC flattening сервис могут делать это автоматически. Trade-off: flattened записи не auto-update, когда upstream-сервис меняет IP, поэтому нуждаются в периодическом re-flattening.

Консолидация означает удаление сервисов, которые вы реально не используете. Audit’ьте свой sending-стек поквартально и удаляйте SPF includes для сервисов, которые перестали использовать.

Типичные SPF setup ошибки

Добавление +all или ?all вместо ~all или -all. +all означает “любой может слать с этого домена” — полностью defeats purpose of SPF. ?all означает “у нас нет мнения” — почти так же плохо. Всегда используйте ~all (soft-fail) или -all (hard-fail).

Hard-failing (-all) без тестирования. -all говорит receiving-серверам отклонять email, не матчащий SPF-запись. Если ваша SPF-запись неполная или неверная, -all приводит к отклонению легитимного email’а. Продакшен-команды используют ~all, пока SPF не верифицирован working через все sending-сервисы, потом опционально tighten до -all.

Несколько SPF-записей на одном домене. Некоторые команды добавляют вторую SPF-запись при добавлении нового сервиса, вместо редактирования существующей. SPF specifies только одну запись per domain — множественные записи приводят к “permerror”. Всегда редактируйте существующую запись; никогда не добавляйте вторую.

Including сервисы, включающие друг друга. SPF некоторых sending-сервисов уже включает другие распространённые сервисы. Добавление обоих производит redundant lookups, считающиеся в 10-lookup лимит без добавления coverage.

Настройка SPF на неверном уровне домена. Если вы шлёте с mail.company.com, SPF-запись должна быть на mail.company.com, не на company.com. Subdomain имеют свои SPF-требования, когда используются как sending-домены.

Забывание добавить SPF при старте cold email. Команды, начинающие cold email кампанию без настройки SPF на sending-домене, видят immediate placement collapse — большинство receiving-систем сильно штрафует unauthenticated mail в 2026.

Не тестируя после изменений. Каждое SPF-изменение должно быть верифицировано в течение часа propagation. Online testers вроде MXToolbox или PowerDMARC checker подтверждают, что запись синтаксически валидна и в пределах lookup лимитов.

Что делать после того, как SPF настроен

SPF в одиночку не достаточен. Три вещи должны следовать:

1. Настройте DKIM для того же домена — разобрано в деталях в как настроить DKIM. DKIM добавляет криптографическую подпись поверх IP-авторизации SPF.
2. Настройте DMARC, когда SPF и DKIM оба работают — разобрано в DMARC policy: quarantine vs reject. DMARC связывает SPF и DKIM с alignment-проверкой и policy-statement.
3. Мониторьте SPF-результаты через DMARC-отчёты. Как только DMARC настроен, receiving-системы пришлют aggregate-отчёты, показывающие, какие IP шлали mail, claiming быть с вашего домена, и passed ли SPF для каждого. Это feedback-петля для ловли SPF-проблем.

SPF setup в 2026 — 30-минутная задача, когда сделана правильно, и multi-week deliverability disaster, когда сделана неправильно. Самая полезная дисциплина — взять 30 минут, настроить тщательно, верифицировать с несколькими тулами и re-verify, когда меняется sending-стек. Обзор SPF/DKIM/DMARC setup покрывает, как все три куска работают вместе.