Email-спуфинг — один из самых распространённых векторов атак в интернете. Кто-то отправляет письмо, выглядящее с вашего домена, но на самом деле оно идёт с другого сервера. Получатель видит имя вашей компании в поле «From» и доверяет. SPF (Sender Policy Framework) — первая линия защиты от этого, и его правильная настройка — одно из самых важных, что вы можете сделать для безопасности email вашего домена.

Это руководство пройдёт по всему, что нужно знать про SPF-записи: что это, как работают и как настроить запись для вашего домена.

Что такое SPF и почему это важно#

SPF, или Sender Policy Framework, — протокол аутентификации email, описанный в RFC 7208. Он позволяет владельцам доменов указать, какие почтовые серверы авторизованы отправлять email от имени их домена. Когда принимающий сервер получает письмо, якобы пришедшее с вашего домена, он сверяется с вашей SPF-записью, чтобы убедиться, что отправляющий сервер действительно авторизован.

Почему SPF важен#

Без SPF-записи кто угодно может отправить письмо, выглядящее с вашего домена. Это создаёт серьёзные проблемы:

Email-спуфинг и фишинг: атакующие могут выдавать себя за ваш бренд, чтобы обманом выудить чувствительную информацию или заставить кликать по вредоносным ссылкам.
Проблемы доставляемости: крупные email-провайдеры (Gmail, Outlook, Yahoo) используют SPF как сигнал при решении, доставлять ли письмо в Inbox или в спам. Домены без SPF чаще получают фильтрацию даже легитимной почты.
Ущерб репутации бренда: если спамеры используют ваш домен для bulk-рассылки, его репутация падает по сетям email-провайдеров. Это влияет на доставляемость всей вашей почты, включая легитимные деловые сообщения.
Требования комплаенса: многие индустриальные стандарты и регуляции ожидают внедрения email-аутентификации. SPF — базовый уровень.

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

Понимание механики SPF помогает правильно его настроить и устранять проблемы.

Процесс SPF-проверки#

Вы отправляете письмо с you@yourdomain.com через авторизованный почтовый сервер.
Принимающий сервер извлекает домен из envelope sender (заголовок Return-Path, не From).
Принимающий сервер делает DNS TXT-запрос на yourdomain.com, чтобы получить SPF-запись.
Сервер сравнивает IP отправляющего сервера со списком авторизованных IP и хостнеймов в SPF-записи.
На основе сравнения сервер возвращает один из результатов:
- Pass: отправляющий сервер авторизован. Письмо проходит нормально.
- Fail: сервер не авторизован, и владелец домена явно сказал отклонять.
- SoftFail: сервер не авторизован, но владелец недостаточно уверен, чтобы требовать жёсткого отклонения. Письмо обычно принимается, но помечается.
- Neutral: владелец домена не делает утверждений о сервере.

Формат SPF-записи#

SPF-запись — это DNS TXT-запись, опубликованная на вашем домене. Она следует определённому синтаксису:

v=spf1 [механизмы] [квалификатор]

v=spf1 обязательно и идентифицирует запись как SPF v1.
Механизмы определяют, какие серверы авторизованы.
Квалификатор в конце задаёт политику по умолчанию для серверов, не подходящих ни под один механизм.

Реальный пример:

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

Эта запись говорит: разрешить почтовые серверы Google, серверы SendGrid и конкретный IP 203.0.113.50 отправлять для этого домена. Всех остальных — отклонять.

Пошаговая настройка SPF#

Следуйте этим шагам, чтобы создать и опубликовать SPF-запись для домена.

Шаг 1: определите все email-сервисы отправки#

Перед написанием SPF-записи нужен полный список всех сервисов и серверов, отправляющих email от имени вашего домена. Это самый часто упускаемый шаг — пропуск источника отправки приведёт к провалу SPF для этих писем.

Типичные источники email-отправки:

Email-провайдер: Google Workspace, Microsoft 365, Zoho Mail, ProtonMail и т. д.
Транзакционные email-сервисы: SendGrid, Mailgun, Amazon SES, Postmark, Resend и т. д.
Маркетинговые email-платформы: Mailchimp, HubSpot, ActiveCampaign, ConvertKit и т. д.
Веб-сервер: если ваш сайт отправляет письма напрямую (формы контактов, сбросы паролей, подтверждения заказов).
CRM и support-инструменты: Zendesk, Freshdesk, Intercom, Salesforce и т. д.
Другие SaaS-инструменты: любое приложение, отправляющее email с использованием вашего домена.

Запишите каждый сервис. Сверьтесь с разными отделами в организации. Маркетинг может пользоваться платформой, о которой инжиниринг не знает, и наоборот.

Шаг 2: соберите SPF-include значения#

Каждый email-провайдер публикует свой include-домен SPF. Вот значения для типичных:

Провайдер	SPF Include
Google Workspace	`include:_spf.google.com`
Microsoft 365	`include:spf.protection.outlook.com`
SendGrid	`include:sendgrid.net`
Mailgun	`include:mailgun.org`
Amazon SES	`include:amazonses.com`
Mailchimp	`include:servers.mcsv.net`
Postmark	`include:spf.mtasv.net`
Zoho Mail	`include:zoho.com`
HubSpot	`include:hubspot-email.com`
Freshdesk	`include:email.freshdesk.com`

Проверьте документацию провайдера на точное include-значение. Провайдеры иногда их обновляют, всегда сверяйтесь с текущей документацией.

Шаг 3: соберите SPF-запись#

Объедините версионный тег, все include-механизмы и квалификатор в одну запись.

Шаблон:

v=spf1 [include:provider1] [include:provider2] [ip4:your.server.ip] [квалификатор]

Пример для бизнеса с Google Workspace и SendGrid:

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

Пример для бизнеса с Microsoft 365, Mailchimp и кастомным почтовым сервером:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 -all

Шаг 4: выберите квалификатор#

Квалификатор в конце SPF-записи определяет, что происходит, когда письмо приходит с сервера, не указанного в записи:

-all (Fail): неавторизованные серверы отклонять. Рекомендуется для максимальной защиты. Говорит принимающим серверам, что вы уверены в списке, и любая почта с невнесённого сервера — мошенническая.
~all (SoftFail): относиться с подозрением, но не отклонять сразу. Используйте при первоначальной настройке или тестировании, когда не уверены, что внесли все легитимные источники.
?all (Neutral): утверждений нет. Защита почти нулевая, не рекомендуется.
+all (Pass): все авторизованы. Полностью убивает смысл SPF. Никогда не используйте.

Рекомендация: начните с ~all во время первоначального развёртывания и тестирования. После подтверждения, что вся легитимная почта проходит SPF, переключитесь на -all для полной защиты.

Шаг 5: опубликуйте запись в DNS#

Войдите к DNS-провайдеру (Cloudflare, Route53, GoDaddy, Namecheap и т. д.) и добавьте/обновите TXT-запись:

Перейдите в управление DNS вашего домена.
Добавьте новую TXT-запись (или отредактируйте существующую SPF, если есть).
Host/Name — @ (это означает корневой домен).
Value/Content — полная строка вашей SPF-записи.
TTL — 3600 (1 час) или дефолт провайдера.
Сохраните запись.

Изменения DNS могут распространяться до 48 часов, хотя обычно видны в течение 15 минут — часа.

Шаг 6: проверьте SPF-запись#

После публикации убедитесь, что запись настроена корректно. Можно использовать Email Health Checker от Nova Uptime для комплексной проверки конфигурации email домена, включая валидацию SPF. Инструмент проверяет синтаксис SPF, оценивает квалификатор, считает DNS-lookup'ы и выявляет потенциальные проблемы.

Можно проверить и из командной строки:

dig TXT yourdomain.com +short

или

nslookup -type=TXT yourdomain.com

Найдите TXT-запись, начинающуюся с v=spf1. Подтвердите, что все ожидаемые include-механизмы на месте, а квалификатор корректен.

Понимаем механизмы SPF#

SPF-записи поддерживают несколько типов механизмов, дающих гибкость в определении авторизованных отправителей.

`include`

Ссылается на SPF-запись другого домена. Самый частый механизм, потому что именно так email-провайдеры публикуют свои авторизованные диапазоны IP.

include:_spf.google.com

Когда принимающий сервер встречает это, он делает дополнительный DNS-запрос, чтобы получить SPF-запись Google и проверить отправляющий IP по диапазонам Google.

`ip4` и `ip6`

Указывает индивидуальные IP-адреса или CIDR-диапазоны, авторизованные отправлять.

ip4:203.0.113.50
ip4:198.51.100.0/24
ip6:2001:db8::/32

Используйте для собственных почтовых серверов или сервиса, где знаете конкретные IP.

`a`

Авторизует IP-адрес, на который указывает A-запись домена. Если веб-сервер тоже отправляет email, это лаконичный способ его авторизовать.

`mx`

Авторизует IP MX-серверов вашего домена. Поскольку MX-серверы получают почту, им часто нужно и отправлять (ответы, отбивки, форварды).

mx

`redirect`

Указывает на SPF-запись другого домена полностью, замещая вашу. Отличается от include тем, что замещает, а не дополняет.

redirect=_spf.example.com

Типичные ошибки SPF и как их избежать#

Ошибка 1: превышение лимита 10 DNS-lookup'ов#

Спецификация SPF (RFC 7208) ограничивает суммарное число DNS-запросов до 10. Каждый механизм include, a, mx и redirect считается за один запрос. Вложенные include (include, который сам содержит include) тоже учитываются.

Если запись превышает 10 lookup'ов, SPF возвращает результат PermError, и многие принимающие серверы отнесутся к этому так же, как к отсутствию SPF.

Как починить:

Замените include на ip4/ip6, где возможно (IP-механизмы не считаются за DNS-запросы).
Используйте инструменты SPF-flattening, чтобы разрешить include до их IP.
Консолидируйте email-сервисы, где возможно.
Удалите include для сервисов, которыми больше не пользуетесь.

Ошибка 2: публикация нескольких SPF-записей#

У домена должна быть ровно одна SPF-запись. Если опубликовать две TXT-записи, начинающиеся с v=spf1, SPF вернёт PermError. Часто случается, когда добавляют новую SPF-запись, не убирая или не обновляя существующую.

Как починить: Объедините всех авторизованных отправителей в одну SPF-запись.

Неправильно:

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

Правильно:

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

Ошибка 3: использование `+all`

Установка +all как квалификатора означает, что любой сервер в мире авторизован отправлять как ваш домен. Это полностью отрицает смысл SPF и серьёзный риск безопасности.

Ошибка 4: забыть обновить после смены провайдеров#

Когда вы меняете email-провайдеров, мигрируете маркетинговые платформы или добавляете новые SaaS-инструменты, SPF нужно обновлять. Старые include для неиспользуемых сервисов тратят DNS-lookup'ы, а отсутствующие include для новых сервисов приводят к провалам легитимной почты.

Ошибка 5: не тестировать после изменений#

Каждый раз при изменении SPF-записи тестируйте её. Отправляйте тестовые письма со всех сервисов и убеждайтесь, что они проходят SPF. Используйте инструменты вроде Email Health Checker от Nova Uptime для валидации синтаксиса и конфигурации.

SPF и общая картина email-аутентификации#

SPF — один из трёх крупных протоколов email-аутентификации. Для комплексной защиты внедряйте все три:

SPF + DKIM + DMARC#

SPF проверяет, что отправляющий сервер авторизован для домена.
DKIM (DomainKeys Identified Mail) добавляет криптографическую подпись к исходящей почте, проверяя, что письмо не было изменено в пути и было отправлено авторизованной стороной.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) связывает SPF и DKIM политикой, говорящей принимающим серверам, что делать при провале аутентификации. Также даёт отчёты, чтобы вы видели, кто отправляет email от вашего имени.

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

Тестирование SPF-записи#

После настройки SPF тщательное тестирование обязательно. Чек-лист:

DNS-верификация: убедитесь, что запись существует и синтаксически корректна, через DNS-lookup инструменты.
Тестовые письма: отправьте письма с каждого авторизованного сервиса и проверьте на стороне получателя в заголовках наличие spf=pass.
Подсчёт lookup'ов: убедитесь, что сумма DNS-запросов ≤ 10.
Только одна SPF-запись: проверьте, что нет дубликатов.
Тест с неавторизованного сервера: если возможно, отправьте письмо с неавторизованного источника и убедитесь, что SPF падает или soft-fail.

Email Health Checker от Nova Uptime автоматизирует большинство проверок. Введите домен и получите мгновенный отчёт о SPF, включая силу политики, синтаксические проблемы и рекомендации. Также проверяет DKIM и DMARC, чтобы вы видели полную картину email-аутентификации в одном месте.

Поддержание SPF-записи#

SPF — не «настроил и забыл». Планируйте регулярные ревизии:

Ежеквартальные аудиты: сверяйте SPF со списком текущих email-сервисов. Удаляйте старые include, добавляйте новые.
После любого инфраструктурного изменения: при добавлении, удалении или смене email-сервиса немедленно обновляйте SPF.
После проблем с доставляемостью: если письма уходят в спам, проверьте SPF в первую очередь. Некорректная запись — одна из самых частых причин.
Автоматизированный мониторинг: используйте инструмент мониторинга здоровья email, который постоянно проверяет SPF и оповещает при поломке.

Итог

Правильная настройка SPF — одно из самых высокоэффектных и низкозатратных улучшений безопасности и доставляемости email вашего домена. Кратко:

Перечислите каждый сервис, отправляющий email от имени домена.
Соберите SPF-include значения для каждого.
Соберите единую SPF-запись со всеми авторизованными отправителями.
Начните с ~all и переходите к -all, как только убедитесь, что всё работает.
Опубликуйте TXT-запись в DNS.
Проверьте через Email Health Checker от Nova Uptime.
Ревизируйте и обновляйте ежеквартально.

Репутация email строится месяцами и может быть разрушена за дни. Правильно настроенная SPF-запись — фундамент, который её защищает.

Часто задаваемые вопросы

Как проверить SPF-запись?#

Используйте бесплатный SPF checker для поиска и валидации SPF-записи. Введите домен — инструмент запросит DNS, проверит синтаксис, посчитает DNS-lookup'ы (макс 10) и проверит политику энфорсмента. Также можно через dig TXT yourdomain.com или nslookup -type=TXT yourdomain.com.

Что делает SPF-проверка?#

SPF-проверка верифицирует, что сервер, отправляющий email от имени вашего домена, авторизован в SPF DNS-записи. Принимающие серверы делают это автоматически. Если отправляющий IP не в SPF, письмо может быть помечено как спам или отклонено в зависимости от политики DMARC.

Как протестировать SPF-запись?#

После публикации SPF тестируйте: (1) запустите бесплатный SPF check, (2) отправьте тестовое письмо в Gmail и проверьте «Show original» на наличие spf=pass, или (3) используйте nslookup -type=TXT yourdomain.com, чтобы убедиться, что запись опубликована корректно.

Что такое лимит 10 DNS-lookup'ов SPF?#

SPF-записи ограничены 10 DNS-запросами. Каждый механизм include:, a:, mx:, ptr: и redirect= считается за один. Превышение даёт постоянный провал SPF (permerror), что значит вся ваша почта проваливает SPF. Используйте SPF Checker для подсчёта текущих lookup'ов.

Использовать -all или ~all в SPF?#

Используйте -all (hard fail) для максимальной защиты — он говорит принимающим серверам отклонять почту с неавторизованных источников. Используйте ~all (soft fail) при первоначальной настройке или миграции. После подтверждения, что все легитимные отправители включены, переключайтесь на -all. Наш Email Health Checker проверяет SPF-политику и рекомендует подходящую настройку.