SPF: что это и как правильно настроить запись для домена

SPF (Sender Policy Framework) — способ сказать всему миру, с каких серверов разрешено отправлять почту от имени вашего домена. Без SPF письма чаще попадают в спам, а мошенникам проще подделать ваш адрес. Разберём синтаксис записи, основные механизмы и ошибки, из-за которых SPF перестаёт работать.

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

SPF — это TXT-запись в DNS вашего домена. Когда сервер получателя принимает письмо, он смотрит на домен отправителя из SMTP-команды MAIL FROM (он же адрес возврата, Return-Path), находит SPF-запись этого домена и проверяет, входит ли IP-адрес подключившегося сервера в список разрешённых.

Результат проверки — одно из значений: pass, fail, softfail, neutral, none, а также temperror и permerror при ошибках DNS или самой записи.

Синтаксис записи

Простейшая SPF-запись выглядит так:

example.uz.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.10 include:_spf.crm.example ~all"

Запись читается слева направо, пока не найдётся первое совпадение:

• v=spf1 — обязательное начало, версия протокола.
• mx — разрешить серверам из MX-записей домена.
• ip4:192.0.2.10 — разрешить конкретному IP-адресу.
• include:_spf.crm.example — разрешить всё, что разрешает SPF-запись другого домена (например, сервиса рассылок или CRM).
• ~all — для всех остальных — мягкий отказ.

Механизмы

Механизм	Пример	Что означает	DNS-запрос
ip4	ip4:203.0.113.0/24	IPv4-адрес или подсеть	нет
ip6	ip6:2001:db8::/32	IPv6-адрес или подсеть	нет
a	a или a:mail.example.uz	IP-адреса из A/AAAA-записей	да
mx	mx	IP-адреса серверов из MX-записей	да
include	include:_spf.crm.example	Подключить SPF другого домена	да
exists	exists:%{i}.spf.example.uz	Сложные проверки через макросы	да
ptr	ptr	Устарел, использовать не рекомендуется	да
all	-all	Всё остальное; ставится в конце	нет

Есть ещё модификатор redirect=: он целиком передаёт проверку SPF-записи другого домена, если в текущей ничего не совпало. Его удобно использовать, когда у компании много доменов с одинаковыми правилами.

Квалификаторы

Перед любым механизмом можно поставить знак, который определяет результат при совпадении: + — pass (по умолчанию, обычно не пишется), - — fail, ~ — softfail, ? — neutral. На практике знак почти всегда ставят только перед all.

~all или -all

-all (hardfail) говорит: «всё, что не перечислено, — точно не мы». ~all (softfail) говорит: «скорее всего не мы, но не отклоняйте жёстко».

• При -all часть серверов отклоняет письмо прямо на этапе SMTP, ещё до проверки DKIM и DMARC. Если вы забыли внести в SPF какой-то сервис, его письма потеряются.
• При ~all письма из неучтённых источников обычно доставляются, но с пониженным доверием или в спам.

Разумный подход: начать с ~all, собрать все реальные источники отправки (в этом помогут отчёты DMARC), а затем, при желании, перейти на -all. Если настроен DMARC с политикой reject, защиту от подделки в основном обеспечивает именно он, и ~all вполне достаточно.

Никогда не используйте +all: эта запись разрешает отправлять почту от вашего имени любому серверу в интернете.

Лимит в 10 DNS-запросов

Стандарт SPF (RFC 7208) ограничивает число механизмов, которые требуют DNS-запросов, до 10 на одну проверку. Считаются include, a, mx, ptr, exists и модификатор redirect, причём включая вложенные: если ваш include внутри содержит ещё три include, это уже четыре запроса. Механизмы ip4, ip6 и all не считаются.

При превышении лимита результат — permerror, и многие получатели воспринимают его как провал SPF. Как уложиться в лимит:

1. Посчитайте запросы: развернуть запись и подсчитать вложенные include помогают онлайн-проверки SPF, например на mxtoolbox.com.
2. Удалите сервисы, которыми уже не пользуетесь.
3. Замените a и mx на явные ip4, если адреса стабильны.
4. Отправляйте рассылки с поддомена (например, news.example.uz) со своей SPF-записью — у него будет собственный лимит.

Есть и второй, менее известный лимит: не более двух «пустых» запросов (void lookups), которые вернули отсутствие записи. Он срабатывает, если в SPF остались ссылки на удалённые домены.

Одна запись на домен

У домена должна быть ровно одна TXT-запись, начинающаяся с v=spf1. Если их две, результат проверки — permerror. Это частая ошибка: подключили новый сервис, он попросил «добавить SPF», и рядом со старой записью появилась вторая. Правильно — объединить механизмы в одну запись:

Неправильно:
"v=spf1 mx ~all"
"v=spf1 include:_spf.crm.example ~all"

Правильно:
"v=spf1 mx include:_spf.crm.example ~all"

Если запись длиннее 255 символов, её разбивают на несколько строк в кавычках внутри одной TXT-записи — получатель склеит их без пробелов. Это по-прежнему одна запись. Отдельный DNS-тип SPF (тип 99) устарел, используйте только TXT.

Другие частые ошибки

• Опечатки: v=spf1 без единицы, ip4: с пробелом после двоеточия, include на несуществующий домен.
• Механизмы после all: всё, что идёт после all, игнорируется.
• Забытые источники: сайт, который отправляет уведомления, 1С, CRM, онлайн-касса, сканер в офисе.
• Нет SPF у неиспользуемых доменов: для доменов, с которых почта не отправляется, опубликуйте "v=spf1 -all", чтобы их было сложнее подделать.
• Пересылка: при простой пересылке письмо уходит с чужого сервера, и SPF на стороне конечного получателя не проходит. Здесь выручает DKIM, подпись которого пересылку обычно переживает.

Проверить SPF можно командой dig TXT example.uz +short или nslookup -type=txt example.uz, а результат проверки конкретного письма — в заголовке Authentication-Results (например, spf=pass smtp.mailfrom=example.uz).

В MCMail SPF, DKIM и DMARC для вашего домена настраиваем мы: присылаем точные записи при подключении и помогаем объединить их с уже используемыми сервисами. Если письма всё равно уходят в спам, посмотрите статью почему письма попадают в спам.