# SPF SPF (правила проверки отправителя) — это TXT-запись в DNS домена, которая перечисляет серверы, имеющие право отправлять почту от его имени. Когда письмо приходит, сервер получателя сверяет IP отправителя с этим списком: если сервера в записи нет, письмо помечают подозрительным или отклоняют. Без корректной SPF холодная рассылка попадает в спам ещё до того, как её прочитают. **Цифры:** 97,7% — адресов приняли письмо в наших кампаниях; 2,3% — отскок при настроенных DNS и чистой базе; 420 — ящика-отправителя в нашей инфраструктуре ## Как SPF влияет на результат кампании Почтовые провайдеры — Яндекс, Mail.ru, Google — проверяют SPF одной из первых. Нет записи или IP отправителя в ней не значится — письмо получает минус к репутации до чтения текста. На холодном объёме это критично: фильтр и так относится к незнакомому отправителю настороженно, а сломанная авторизация превращает настороженность в отказ. По нашим кампаниям: при настроенных SPF, DKIM и DMARC и валидной базе **97,7% адресов приняли письмо**, отскок — 2,3%. Это потолок того, что даёт техническая настройка: она не делает рассылку хорошей, она убирает причины, по которым хорошую рассылку не доставят. Дальше результат решают база, оффер и [доставляемость](/slovar/deliverability/) как сумма факторов. Проверка SPF происходит на уровне сервера, получатель её не видит. Но видит последствия: письмо во «Входящих» или письмо в «Спаме». Поэтому настройку DNS ведём первым шагом, ещё до регистрации ящиков — регламент описан в услуге [доставляемости](/uslugi/dostavlyaemost/). ## Как выглядит запись и что проверить SPF публикуется одной TXT-записью в DNS домена. Типовой вид: **v=spf1 include:_spf.yandex.net ~all**. Начало v=spf1 — версия протокола. Середина — механизмы: ip4 для конкретных адресов, include для подключения списка провайдера почты. Финал — правило для всех, кто не совпал: ~all (мягкий отказ, письмо пометят) или -all (жёсткий отказ, письмо отклонят). Два жёстких ограничения стандарта. Первое: **запись на домен должна быть одна** — две TXT с v=spf1 дают ошибку PermError, и проверка считается не пройденной. Второе: суммарно не более **10 DNS-запросов** на проверку — каждый include тянет за собой вложенные запросы, и при переполнении проверка обрывается с той же ошибкой. 1. Определите все сервисы, которые шлют почту от имени домена: корпоративная почта, система учёта клиентов, рассыльщик, счёт на оплату из биллинга. 2. Соберите их механизмы в одну запись: ip4 для своих серверов, include для сервисов. 3. Выберите финал: ~all на время отладки, -all когда уверены, что всех отправителей перечислили. 4. Проверьте запись после публикации — опечатка в синтаксисе ломает её целиком. Пошаговый регламент — в гайде [настройка SPF, DKIM и DMARC](/gaydy/spf-dkim-dmarc-nastroyka/), быстрая сверка — в инструменте [проверки DNS домена](/instrumenty/proverka-dns/). ## Типовые ошибки при настройке - **Две записи вместо одной.** Добавили рассыльщик, не тронув старую TXT. Оба сервиса формально прописаны, фактически проверка не проходит вообще. - **Жёсткий -all с неполным списком.** Про биллинг или форму на сайте вспомнили, когда клиенты перестали получать счета. - **Лавина include.** Каждый сервис просит свой include, у каждого внутри свои вложенные. Лимит в 10 запросов исчерпан, запись не работает. - **Рассылка с основного домена.** Холодный объём с корпоративного домена подставляет под фильтры всю рабочую почту компании. Под кампании делегируют отдельные домены — это база [прогрева доменов и ящиков](/uslugi/progrev-domenov/). - **Запись настроена и забыта.** Сменили почтового провайдера, старый include остался, новый не добавили. > SPF проверяет домен из технического адреса возврата (envelope from), а не из поля «От кого», которое видит читатель. Подделать видимое поле можно и с корректной записью — поэтому существует DMARC: он требует, чтобы технический и видимый домены совпадали. ## Когда одной SPF мало SPF — один из трёх механизмов авторизации, а не вся система. [DKIM](/slovar/dkim/) подписывает письмо криптографическим ключом и подтверждает, что текст не меняли в пути. [DMARC](/slovar/dmarc/) связывает обе проверки и говорит серверу получателя, что делать с письмом, которое их не прошло. Провайдеры смотрят на связку: одна SPF без подписи и политики выглядит наполовину собранной схемой. Есть и честные пределы. При пересылке письма дальше (форвардинг внутри компании получателя) SPF ломается технически: пересылающий сервер в записи не значится — выручает DKIM, подпись пересылку переживает. И никакая запись не компенсирует репутацию: молодой домен без истории, объём с первого дня, жалобы на спам — и корректный SPF не удержит письма во «Входящих». Репутацию нарабатывают прогревом и дисциплиной объёмов, следствие смотрите по метрике [отказа доставки](/slovar/bounce-rate/). ## Частые вопросы **Чем SPF отличается от DKIM и DMARC?** SPF — список разрешённых серверов в DNS. DKIM — цифровая подпись письма ключом домена. DMARC — политика, которая требует совпадения видимого отправителя с проверенным и задаёт реакцию на несовпадение. Работают вместе: SPF без DKIM и DMARC — неполная авторизация. **Что выбрать в конце записи: ~all или -all?** ~all помечает чужие отправки как подозрительные, но доставляет — вариант на время настройки, пока не уверены, что все легальные сервисы перечислены. -all отклоняет их — строже и лучше для защиты домена от подделки, но сначала проверьте, что под жёсткое правило не попадёт биллинг или система учёта клиентов. **Можно ли иметь две SPF-записи на домен?** Нет. Две TXT-записи с v=spf1 дают ошибку PermError — проверка считается не пройденной, как будто записи нет вообще. Все механизмы собирают в одну строку через пробелы. **SPF настроен, а письма всё равно в спаме. Почему?** Запись — пропуск на проверку, а не гарантия доставки. Дальше фильтр смотрит DKIM и DMARC, репутацию домена и IP, историю жалоб, содержимое письма. На холодном объёме решающим часто оказывается возраст домена и график прогрева. **Нужна ли SPF для поддомена под рассылки?** Да, для каждого домена и поддомена-отправителя запись публикуется отдельно — она не наследуется. Под кампании делегируем отдельные домены и настраиваем SPF, DKIM и DMARC на каждый до первой отправки. **Как проверить, что запись работает?** Сверьте TXT-запись домена любым DNS-чекером: должна быть одна строка v=spf1 без ошибок синтаксиса и без превышения лимита запросов. Затем отправьте тестовое письмо и посмотрите заголовки: строка Received-SPF должна содержать pass. --- Источник: https://ot9.ru/slovar/spf/ · Отряд 9 (КАП Групп) · обновлено 2026-08-10