Определение
SPF-запись (Sender Policy Framework) — DNS TXT-запись, публикуемая в публичной DNS-зоне домена, которая перечисляет IP-адреса, IPv6-префиксы и имена почтовых серверов, уполномоченных отправлять email от имени этого домена. Когда принимающий сервер принимает входящее сообщение, он запрашивает DNS отправителя для извлечения SPF-записи и сверяет с политикой IP-адрес соединяющегося сервера. Если IP в списке отсутствует, принимающий сервер может пометить сообщение как softfail, сразу отвергнуть или отправить на дополнительную оценку — в зависимости от заданного владельцем квалификатора.
SPF впервые формализован как стандарт IETF в RFC 4408 (2006) и затем обновлён до текущей авторитетной спецификации RFC 7208, опубликованной IETF в апреле 2014 года. Это один из трёх взаимодополняющих стандартов аутентификации email — наряду с DKIM (DomainKeys Identified Mail) и DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Как это работает
Оценка SPF включает несколько последовательных шагов на стороне SMTP-движка принимающего сервера в фазе MAIL FROM SMTP-диалога.
Владелец домена публикует SPF TXT-запись в DNS. Типичная запись подчиняется синтаксису: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Компоненты: v=spf1 (идентификатор версии), один или несколько механизмов (include, ip4, ip6, a, mx, exists) и итоговый квалификатор (+all, -all, ~all, ?all). Квалификатор -all означает жёсткий отказ — любой не указанный сервер не санкционирован. Квалификатор ~all (softfail) пропускает сообщение, отметив несоответствие — обычно используется на этапах миграции.
При получении сообщения принимающий MTA извлекает домен envelope sender (адрес MAIL FROM, он же RFC5321.MailFrom) и выполняет DNS TXT-запрос по _spf.<домен> или прямо по корню. SPF-библиотека оценивает механизмы в порядке, пока один не совпадёт или пока не будет достигнут лимит из десяти DNS-запросов («SPF PermError», RFC 7208 §4.6.4). Результат — Pass, Fail, SoftFail, Neutral, TempError или PermError — вставляется в заголовок Received-SPF и передаётся спам-фильтру и движку DMARC-политики.
Важно отметить: SPF аутентифицирует envelope sender (MAIL FROM), а не видимый заголовок From в теле сообщения. Из-за этого SPF сам по себе не предотвращает подделку отображаемого имени в почтовых клиентах, поэтому для полной защиты нужна выровнятельная проверка DMARC — требование, чтобы результаты SPF и/или DKIM совпадали с доменом RFC5322.From.
Где вы это встречаете
SPF-записи появляются всюду, где важны доставляемость и репутация отправителя. Транзакционная инфраструктура — Amazon SES, SendGrid, Mailgun, Postmark, SparkPost — требует, чтобы вы как владелец домена добавили SPF-механизм include, указывающий на инфраструктуру отправки провайдера, прежде чем сообщения пройдут аутентификацию.
Конкурсные платформы, шлющие подтверждения голосов по email — Woobox, ShortStack и собственные системы на Mailchimp Transactional (Mandrill), — опираются на наличие у домена отправителя валидной SPF-записи. Почтовые провайдеры — Google (Gmail), Microsoft (Outlook / Exchange Online Protection), Yahoo Mail, Yandex Почта, Mail.ru — оценивают SPF как один из входов алгоритмов доставляемости. Отсутствующая или неверно настроенная SPF существенно повышает вероятность того, что подтверждения молча уйдут в спам или будут отвергнуты, и голоса останутся неподтверждёнными.
Панели управления DNS у Cloudflare, AWS Route 53, GoDaddy, REG.RU, Namecheap позволяют редактировать SPF TXT-запись через свой интерфейс. Диагностические инструменты — MXToolbox SPF Lookup, Google Admin Toolbox и SPF Surveyor от DMARCIAN — помогают проверить опубликованные записи.
Практические примеры
Конкурсная платформа отправляет письма-подтверждения с [email protected]. У домена votes.example.com SPF-запись v=spf1 include:sendgrid.net -all. Когда Gmail получает сообщение, входной SMTP-сервер Gmail запрашивает DNS на SPF, разворачивает механизм include:sendgrid.net и сверяет соединяющийся IP со списком авторизованных серверов SendGrid. Если IP совпадает — результат Pass и сообщение идёт в Inbox. Без SPF-записи фильтр Gmail сочтёт сообщение неаутентифицированным, и шанс попадания в Inbox снизится.
Региональная газета в России меняет провайдера транзакционной почты с Mailchimp на Amazon SES без обновления SPF. Подтверждения начинают проваливать SPF-проверку у Microsoft Outlook и попадают в спам, и голосующие пропускают окно подтверждения. Администратор диагностирует через MXToolbox, добавляет include:amazonses.com в SPF, и доставляемость восстанавливается в окне распространения DNS (обычно 0–48 часов в зависимости от TTL).
Связанные понятия
SPF — один столп трёхзвенного стека аутентификации email: см. DKIM для криптографической проверки подписи и DMARC для уровня политики, действующего на результаты SPF и DKIM. Практическое влияние на конкурсные операции описано в Голосовании по подтверждению email, где доставляемость подтверждающего сообщения — критическая операционная зависимость. BIMI (Brand Indicators for Message Identification) — более новый стандарт, надстроенный над DMARC, позволяющий верифицированным отправителям отображать логотип бренда в поддерживающих провайдерах — формирующийся сигнал доверия, не рассматриваемый здесь.
