Мой дэйли дайджест

одно техническое понятие в день

SPF (Sender Policy Framework)

24 июля 2026 · ~15 мин чтения

протокол email dns безопасность антиспам

SPF (Sender Policy Framework)

SPF — это стандарт для email, который позволяет владельцу домена публично объявить в DNS список серверов, которым разрешено отправлять письма от имени этого домена. Приёмный сервер сверяет реального отправителя со списком и решает, доверять письму или считать его подделкой.

История

Начало 2000-х, США. Meng Weng Wong (Мэн Вэн Вон), сооснователь провайдера pobox.com — один из первых массово формулирует идею: пусть домен сам скажет, кто имеет право слать от его имени. До этого злоумышленник мог тривиально поставить в поле «From» любой адрес: почтовый протокол SMTP (Simple Mail Transfer Protocol — простой протокол пересылки почты) образца 1982 года никакой проверки отправителя не предусматривал вообще. Это делало возможным массовые спам-рассылки и фишинг «от имени банка».

2003 — первый черновик SPF и объединение с параллельным проектом RMX (Reverse MX) Хадмута Данеша. Идея простая: добавить в DNS-зону домена специальную TXT-запись, где перечислены IP-адреса и другие домены, которым разрешено отправлять почту. Приёмник смотрит IP отправителя, тянет TXT-запись домена из письма и сверяет.

2006 — RFC 4408. Первый официальный экспериментальный стандарт. Он же ввёл отдельный тип DNS-записи SPF (номер 99) — казалось, что это правильнее, чем перегружать общий TXT. На практике почти все реализации остались на TXT — многие DNS-провайдеры долго не умели заводить кастомные типы, а поддерживать две записи параллельно оказалось хуже, чем одну.

2014 — RFC 7208. Обновлённая версия, уже proposed standard (полноценный стандарт-кандидат). Именно она действует сегодня. Здесь окончательно закрепили: тип DNS-записи — только TXT, отдельный тип SPF (99) объявлен устаревшим. Также RFC 7208 уточнил лимиты по количеству DNS-запросов при разборе одной SPF-записи (не больше 10 lookup-ов, о них ниже).

Текущий статус (2026). SPF — базовый обязательный кирпич для любой массовой рассылки. С 2024 года Gmail и Yahoo официально требуют SPF вместе с DKIM и DMARC для отправителей от 5000 писем в сутки — без этого набора письма отбрасывают или ставят «спам» автоматически. Российские провайдеры (Mail.ru Group, Яндекс.Почта) держат похожие требования.

Что это такое

SPF — это механизм авторизации отправляющего сервера. Не проверка содержимого письма и не подпись, а именно вопрос: «имеет ли право этот конкретный SMTP-сервер отправлять почту от имени этого домена?».

Всё держится на трёх сущностях:

  1. Домен отправителя — берётся не из «красивого» поля From, которое видит человек, а из так называемого MAIL FROM (envelope sender, «конверт-адрес»). Это адрес, который SMTP-сервер передаёт в команде MAIL FROM:<...> при доставке. Может отличаться от From (например, bounces@newsletter.example.com в MAIL FROM и hello@example.com в From — обычная практика для рассылок).
  2. DNS TXT-запись — публикуется владельцем домена, начинается с v=spf1, дальше идут механизмы разрешения и запретительная политика в конце.
  3. Проверяющий сервер — обычно принимающий MTA (Mail Transfer Agent — почтовый узел) вроде Gmail, Postfix, Exim. Он тянет TXT-запись домена из MAIL FROM и проверяет, входит ли IP подключившегося отправителя в разрешённый список.

SPF vs DKIM. SPF отвечает на вопрос «правильный ли сервер отправил?», DKIM (DomainKeys Identified Mail) — «не подделали ли содержимое по пути и подписал ли его правильный домен?». Это разные слои. SPF ломается при пересылке (forwarding): если Вася переслал письмо со своего почтового ящика на другой адрес, конверт-отправитель может остаться прежним, а слать будет уже сервер Васи — SPF не сойдётся. DKIM в этой ситуации обычно выживает, потому что подпись едет вместе с телом. Именно поэтому современный подход — использовать оба вместе.

SPF vs DMARC. DMARC — это надстройка, которая описывает, что делать, когда SPF или DKIM не прошли. Сам по себе SPF только выдаёт вердикт «pass/fail/softfail», но не диктует принимающему серверу, что с этим делать. DMARC говорит: «если ни SPF, ни DKIM не прошли — отправляй в спам» или «отбрасывай совсем» и «шли мне отчёт вот сюда». Без DMARC даже жирный SPF-fail часто не приводит к отклонению — приёмник просто «ставит галочку».

Как выглядит SPF-запись. Примерно так:

v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 include:_spf.google.com include:sendgrid.net -all

Читается: «версия 1; разрешаем IP 192.0.2.10 и .11; разрешаем всё, что перечислено в SPF-записи домена google (это MX-серверы Gmail); разрешаем всё, что перечислено у SendGrid; всё остальное — жёсткий fail». -all в конце — это «политика»: -all — жёстко отклонять, ~all — softfail (пометить, не отклонять), +all — разрешить всех (никогда так не делай, это буквально «слать от нашего домена может кто угодно»).

Аналогии из жизни

Пропуск на охраняемой парковке.
У торгового центра есть охраняемая парковка. У ресепшена — список номеров машин, которым разрешено ставиться от имени арендатора «Кафе Ромашка». Приезжает грузовик, говорит: «Я от Ромашки». Охранник смотрит номер по списку — есть, впускает. Нет — заворачивает. SPF — этот самый список у ресепшена, только в DNS.
Где ломается: если владелец Ромашки нанял новую службу доставки и забыл добавить их машины в список — легитимные грузовики завернут. Так же и с SPF: подключил новый сервис рассылок (условный UniSender, SendGrid, Mailchimp), но не дописал их в TXT-запись — почта от этого сервиса пойдёт в спам, хотя ты сам её заказал. Это самая частая причина «наши письма не доходят» после переезда на новый провайдер рассылок.

Штамп «Отправлено с моего аккаунта на почте».
Раньше в некоторых странах на конвертах ставили штамп почтового отделения — «принято отделением №42, город N». Получатель по штампу мог убедиться: если письмо якобы от банка, а штамп какой-то мелкой сельской почты в другом регионе — что-то не так. SPF — это проверка штампа: реально ли письмо ушло из «отделения», которое разрешено домену.
Где ломается: если письмо пришло тебе на почту, а ты пересылаешь его другу — на новом конверте будет уже штамп твоего отделения, не банковского. Формально «неправильный отправитель», хотя содержание оригинальное. Именно так SPF ломается при forwarding-е: пересылающий сервер меняет envelope sender-а, и SPF-проверка на стороне финального получателя выдаёт fail. Против этого придумали SRS (Sender Rewriting Scheme) и подход, при котором пересылщик добавляет свой DKIM.

Шенгенская виза и авиакомпания.
Когда ты летишь в Европу, авиакомпания перед посадкой в самолёт проверяет визу — это её обязанность (Directive 2004/82/EC), иначе штраф. Виза — «право въезда», а не «право лететь». Похоже и с SPF: он подтверждает не то, что письмо законное по содержанию, а только то, что отправитель имеет право «лететь под флагом» этого домена.
Где ломается: виза не означает, что тебя точно впустят на границе — пограничник может завернуть по другим основаниям (мало денег, подозрительная цель поездки). Так же SPF-pass не гарантирует, что письмо попадёт во «Входящие»: приёмник смотрит ещё и на репутацию IP, содержимое, DKIM, DMARC, поведение пользователей. SPF — необходимое, но далеко не достаточное условие доставляемости.

Как это работает

Пошагово, что происходит при отправке одного письма.

Шаг 1. Сервер-отправитель (условно mail.example.com) устанавливает SMTP-соединение с сервером-получателем (например, gmail-smtp-in.l.google.com). Уже на этом этапе получатель видит IP-адрес отправителя — из TCP-соединения.

Шаг 2. Отправитель произносит команду MAIL FROM:<newsletter@example.com> — это и есть envelope sender. Именно домен из MAIL FROM (example.com) будет использован для SPF-проверки. Если MAIL FROM пустой (иногда бывает при bounce-сообщениях) — SPF проверяют по домену из HELO / EHLO, то есть по имени, которым сервер представился в начале разговора.

Шаг 3. Приёмник делает DNS-запрос типа TXT для домена example.com. Получает ответ, ищет среди TXT-записей ту, что начинается с v=spf1. Если таких записей больше одной — по стандарту это ошибка permerror (нельзя иметь две SPF-записи на один домен).

Шаг 4. Приёмник разбирает механизмы SPF-записи слева направо и для каждого проверяет, подходит ли под него IP отправителя. Основные механизмы:

Шаг 5. Как только один из механизмов совпал, применяется его квалификатор (символ перед именем): + (по умолчанию) — pass, - — hardfail, ~ — softfail, ? — neutral. Разбор останавливается. Если ни один механизм не совпал — применяется «all» из конца записи.

Шаг 6. Приёмник получает результат и добавляет его в служебный заголовок письма — Received-SPF: pass|fail|softfail|neutral|none|temperror|permerror, а также включает в общий заголовок Authentication-Results. Что делать с результатом — решает DMARC-политика домена или локальная политика приёмника.

Ограничение 10 DNS-запросов. Ключевое место, где рушится куча реальных конфигураций. RFC 7208 говорит: при разборе одной SPF-записи приёмнику разрешено сделать не более 10 DNS-запросов. Каждый include, a, mx, exists — это один запрос. include рекурсивен: если внутри тоже есть include-ы, они тоже считаются. Если превысил — результат permerror, и с точки зрения многих приёмников это как fail. Практически это значит: подключил SendGrid + Mailchimp + Google Workspace + Zendesk + ещё пару сервисов — и уже уткнулся в лимит. Спасение — так называемый SPF flattening (замена всех include-ов на конкретные IP-адреса) или использование сервисов вроде autospf.com, которые генерируют «плоскую» запись автоматически.

Псевдокод логики приёмника (упрощённо):

ip = tcp_source_ip
domain = mail_from.split('@')[1]  # или HELO, если MAIL FROM пуст
spf_record = dns_txt(domain).filter(startswith("v=spf1"))
if len(spf_record) != 1: return "none" or "permerror"
for mechanism in parse(spf_record):
    if match(mechanism, ip):
        return quality(mechanism)  # pass / fail / softfail / neutral
    if dns_lookups_used > 10: return "permerror"
return apply(all_mechanism)  # обычно fail или softfail

Где встречается в обычной жизни

Где встречается в IT и бизнесе

Кто пользуется

По сути, все, у кого есть корпоративный домен и электронная почта. По разным оценкам, SPF-запись присутствует у 70–80% крупных доменов мира (данные из отчётов Google, Cloudflare, Valimail за последние годы — точные числа плавают). Среди топ-1000 сайтов по посещаемости SPF имеют почти 100%. У малого бизнеса — обычно только там, где кто-то из подрядчиков однажды дошёл до настройки.

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

Приёмная сторона: все крупные почтовые провайдеры проверяют SPF на входе. Gmail, Outlook.com, Yahoo, ProtonMail, Mail.ru, Яндекс, iCloud — все. Разница только в том, как строго они трактуют fail: одни сразу в спам, другие спрашивают DMARC-политику.

Альтернативы и конкуренты

Строго говоря, у SPF нет прямого конкурента — DKIM и DMARC не заменяют его, а работают вместе. Единственная реальная альтернатива — вообще ничего не настраивать, но это не альтернатива, а решение «принять, что письма будут в спаме».

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

Связанные понятия

Литература и источники

Где встретилось у меня

Вчера настраивал массовую email-рассылку через сервис-провайдера и разбирался, почему письма падают в спам Gmail. Проверил DNS-записи домена отправителя, SPF и DKIM оказались на месте, а вот DMARC отсутствовал — именно из-за этого приёмник не понимал, как трактовать письма от нового сервиса, и осторожно отправлял всё в спам.

Краткое резюме