SPF-запись

SPF-запись — это TXT-запись в DNS домена, которая перечисляет серверы и IP-адреса, имеющие право отправлять письма от имени домена. Она помогает принимающей стороне отличить вашу легитимную почту от подделок и снижает риск попадания писем в спам. Разберём синтаксис, настройку и проверку — с примерами и типичными ошибками.

SPF (Sender Policy Framework) — это TXT-запись в DNS, где вы перечисляете IP-адреса и серверы, которым разрешено отправлять письма от имени вашего домена. Принимающий почтовый сервер запрашивает эту запись и сверяет с ней IP отправителя. Если адрес совпал — письмо получает статус pass, если нет — fail или softfail, и дальше применяется политика получателя: доставка с пометкой, фильтр или отклонение.

SPF не работает в одиночку. Он проверяет адрес отправителя в конверте письма (MAIL FROM), DKIM подтверждает подпись письма, а DMARC объединяет результаты обеих проверок и указывает, что делать при несовпадении. Без DMARC одна SPF-запись не защищает заголовок From — то есть то, что видит получатель в почтовом клиенте.

При проверке принимающий сервер фиксирует один из результатов:

• pass — IP есть в списке разрешённых, письмо легитимно;
• fail — IP не разрешён, вероятна подделка;
• softfail — IP не разрешён, но отправитель просит относиться к письму мягко;
• neutral — записи не дают чёткого ответа;
• none — SPF-записи у домена нет.

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

Пример для одного сервера: v=spf1 ip4:192.0.2.10 -all. Для нескольких источников: v=spf1 ip4:192.0.2.10 ip4:198.51.100.25 ~all. С подключением сервиса: v=spf1 ip4:192.0.2.10 include:_spf.mailer.example -all.

Принимающий сервер берёт домен из MAIL FROM и запрашивает его TXT-запись. Затем сверяет IP отправителя с механизмами записи слева направо — до первого совпадения. При pass письмо пропускается, при fail — блокируется или помечается в заголовках Received-SPF и Authentication-Results.

У механизма есть ограничения. При пересылке письма на другой адрес IP отправителя меняется на IP сервера пересылки, и SPF может вернуть fail, хотя письмо легитимно. Именно поэтому нужны DKIM (подпись сохраняется при пересылке) и DMARC. Ещё один нюанс: каждый include, a, mx и exists — это DNS-запрос. Всего допускается не более 10 таких запросов на проверку одной записи.

1. Соберите список всех источников отправки: хостинг сайта, корпоративная почта, CRM, сервисы рассылок. Пропущенный источник — главная причина, по которой письма попадают в спам.
2. Запросите у сервисов рассылок значение include — оно есть в их справке или настройках домена.
3. Откройте панель DNS у провайдера или регистратора и добавьте TXT-запись: имя хоста (обычно @), тип TXT, значение с v=spf1 … и TTL.
4. Для собственных серверов используйте ip4, для сервисов рассылок — include, если почта на хостинге — механизм mx или a.
5. Завершите запись квалификатором ~all на время проверки и перейдите на -all, когда убедитесь, что все источники внесены.

При смене провайдера или добавлении нового источника отправки запись нужно обновить: добавьте механизм и заново проверьте, что лимит DNS-lookup не превышен. DNS обновляется от нескольких минут до 24–48 часов в зависимости от TTL.

Механизмы all, ip4 и ip6 не требуют дополнительных DNS-запросов. a, mx, include, exists и модификатор redirect обращаются к DNS и расходуют лимит в 10 запросов, причём include тянет за собой и запросы из подключённой записи. Квалификаторы + - ~ ? сообщают принимающей стороне, как интерпретировать совпадение. Модификаторы redirect и exp применяют реже: redirect перенаправляет проверку на другую запись, exp задаёт пояснение для случаев fail.

Быстрее всего — через DNS: выполните dig TXT example.ru или nslookup -type=TXT example.ru и найдите в ответе строку с v=spf1. Дальше удобно проверить запись через онлайн-анализаторы: они показывают синтаксис и количество DNS-lookup. Затем отправьте тестовое письмо и посмотрите заголовки Received-SPF и Authentication-Results — там будет результат проверки.

Типичные ошибки: несколько SPF-записей у домена (должна быть одна), отсутствие all, превышение лимита lookup, опечатки в механизмах и include. Увидеть все DNS-записи домена сразу, включая SPF и DMARC, можно в проверке DNS-записей nextin.ru.

1. Откройте страницу проверки DNS-записей.
2. Введите домен, для которого проверяете почту, и запустите проверку.
3. Посмотрите строки TXT и DMARC: среди TXT будет ваша SPF-запись, в DMARC — политика домена из записи _dmarc.
4. Проверьте записи A/AAAA (сайт), MX (почтовые серверы), NS и SOA, CAA.
5. Прочитайте подсказки: инструмент отметит, если у домена есть MX, но нет SPF, если нет DMARC-записи и если не настроен www.

Проверка бесплатная и без регистрации. Синтаксис и число DNS-запросов внутри SPF инструмент не разбирает — для этого скопируйте запись в специализированный SPF-анализатор. Если нужно узнать регистратора и срок оплаты домена, используйте WHOIS, а настройку HTTPS — проверку SSL.

Если домен не отправляет письма, достаточно записи v=spf1 -all — так вы запрещаете любую отправку от его имени. Жёсткий -all опасен, если легитимные источники не внесены в запись: письма начнут отклоняться. Пересылка писем и сторонние сервисы тоже требуют внимания — добавляйте их include заранее. И помните: без DMARC одна SPF-запись не даёт полной защиты заголовка From.

Возьмите у сервиса рассылок значения include и добавьте их в запись рядом с остальными источниками. Настройте DKIM и DMARC — только вместе они дают предсказуемую доставку. После изменения записи следите за отчётами DMARC, прогревайте домен постепенно и перед массовой отправкой проверьте количество lookup и сделайте тестовую доставку.

Сколько SPF-записей может быть у домена?

Одна. Если TXT-записей с v=spf1 несколько, проверка может завершиться ошибкой — объедините всё в одну строку.

Что означает v=spf1 -all в конце записи?

Это запрет на отправку писем от имени домена любыми серверами. Такую запись ставят для доменов, которые не используются для почты.

Почему письма попадают в спам, хотя SPF настроен?

Чаще всего не хватает DKIM и DMARC, либо в записи пропущен источник отправки. Проверьте заголовки Authentication-Results тестового письма.

Чем SPF отличается от DKIM и DMARC?

SPF проверяет IP отправителя из конверта, DKIM — подпись письма, DMARC объединяет результаты и задаёт политику для заголовка From.

Как проверить, что SPF-запись работает правильно?

Посмотрите запись в DNS-записях домена или DNS-запросом TXT, проверьте синтаксис и лимит lookup онлайн-анализатором, отправьте тестовое письмо и посмотрите результат в заголовках.