Введите любой домен, чтобы получить и проверить его SPF-запись. Полное значение записи, пояснение каждого механизма и оценка корректности настройки.
SPF-запись (Sender Policy Framework) — это DNS TXT-запись, которая разрешает конкретным почтовым серверам отправлять письма от имени домена. Это один из трёх основных протоколов аутентификации почты наряду с DKIM и DMARC. Когда сообщение приходит, принимающий почтовый сервер запрашивает SPF-запись домена отправителя, чтобы проверить, авторизован ли IP-адрес доставки.
SPF лежит в основе доставляемости почты. Без корректной SPF-записи письма с вашего домена чаще помечают как спам или отклоняют полностью. Крупные почтовые провайдеры — Gmail, Outlook, Yahoo — считают результат SPF основным сигналом доверия. Google и Yahoo теперь требуют SPF в рамках правил для массовых отправителей.
SPF-запись описывает авторизованных отправителей с помощью набора механизмов. Часто используются ip4 и ip6 (конкретные IP-адреса или диапазоны), mx (почтовые серверы домена) и include (делегирование SPF-записи другого домена). Запись заканчивается механизмом all, который определяет, что делать с отправителями, не указанными явно: ~all (softfail), -all (hardfail) или ?all (neutral).
Авторизует конкретный IPv4-адрес или CIDR-диапазон. Пример: ip4:203.0.113.1 или ip4:203.0.113.0/24.
Авторизует конкретный IPv6-адрес или диапазон. Пример: ip6:2001:db8::1.
Авторизует почтовые серверы из MX-записей домена. Полезно, когда исходящие и входящие серверы совпадают.
Импортирует и проверяет SPF-запись другого домена. Используется для авторизации сторонних отправителей, например Google Workspace или SendGrid.
Авторизует IP-адреса из A- или AAAA-записей домена. Полезно для веб-серверов, которые также отправляют почту.
Catch-All для отправителей, не попавших под другие механизмы. Префикс: ~(softfail), -(hardfail) или ?(neutral).
Актуальные данные DNS
Проверка SPF получает публичную TXT-политику и показывает правила авторизации, которые оценивают получатели. Это диагностика конфигурации, а не гарантия, что каждое реальное письмо пройдёт проверку.
Домен без политики SPF не даёт доказательств авторизации SPF. Домен с несколькими TXT-записями v=spf1 вызывает постоянную ошибку SPF, а не объединяет их автоматически.
Читайте возвращённую запись точно так, как её публикует DNS. Устаревшие include провайдеров, случайные пробелы и политика на неверном поддомене могут изменить результат.
ip4 и ip6 указывают сети напрямую. include, a, mx, exists и redirect могут вызывать дополнительные DNS-запросы и зависеть от записей другого провайдера.
Политика может быть синтаксически верной, но авторизовать не те системы. Сверяйте каждый механизм с актуальным списком отправителей — зелёный разбор не означает, что бизнес-конфигурация верна.
Как читать политику
Важен не только факт наличия записи. Нужно понять, можно ли её проверить и совпадает ли граница авторизации с реальным почтовым потоком.
SPF проверяет домен из MAIL FROM или HELO, а не обязательно видимый заголовок From. Поэтому источник может технически пройти проверку, но не совпасть с адресом, который видит получатель, по выравниванию DMARC.
~all и -all задают разную строгость политики для несовпавших источников. ?all не делает положительного утверждения. Неверный синтаксис, дублирующие политики или избыточные DNS-запросы дают permerror — это нужно исправлять, а не трактовать как обычный fail.
Считайте механизмы, вызывающие DNS-запросы, по всей цепочке include. В записи верхнего уровня может быть всего два include, но провайдеры разворачиваются в столько операций a, mx, include, exists или redirect, что превышают лимит RFC.
+all авторизует любого отправителя. Большие диапазоны IP или лишние include тоже облегчают подделку. Проверка SPF должна помочь сузить авторизацию, а не просто подтвердить, что TXT-строка начинается с v=spf1.
Диагностический процесс
Системная проверка связывает опубликованную политику с реальными идентификаторами отправки.
Посмотрите реальное отправленное письмо или настройки провайдера, чтобы найти домен return-path, и запрашивайте именно его, а не предполагайте, что оценивается корневой домен организации.
Определите владельца каждой авторизации include, диапазона IP, a и mx. Удаляйте устаревшие источники только после подтверждения, что они больше не отправляют легитимную почту.
Отправьте письмо через каждую рабочую платформу и проверьте spf=, smtp.mailfrom и выравнивание DMARC в полученных заголовках. Так выявите несовпадения идентификаторов, которые одиночный DNS-запрос не покажет.
Если записи нет или она структурно неверна, используйте генератор SPF-записей, чтобы составить одну объединённую политику, опубликовать её и снова запустить эту проверку после истечения кэша DNS.
Границы результата
SPF — один сигнал на уровне домена. Сам по себе он не отвечает на вопросы о получателе, содержимом или полной аутентификации.
DMARC требует выровненного идентификатора SPF или DKIM. Отдельный домен return-path может пройти SPF, тогда как видимый домен From останется без защиты.
Используйте проверку DKIM и проверку DMARC для этих отдельных DNS-записей и политик.
Получатели сочетают аутентификацию с репутацией отправителя, долей жалоб, содержимым, вовлечённостью и собственными фильтрами. SPF pass — необходимое доказательство для многих отправителей, но не гарантия входящих.
Запись описывает, кто может отправлять от имени домена. Используйте проверку email-адресов, чтобы узнать, может ли адрес назначения принимать почту.
Справка по протоколу
Панели провайдеров упрощают SPF, но получатели оценивают опубликованную политику по протоколу.
Документ IETF RFC 7208 определяет идентификаторы SPF, TXT-записи, механизмы, квалификаторы, лимиты DNS и коды результатов. Это авторитетный источник по дублирующим записям и поведению permerror.
После исправления SPF добавьте подпись сообщений с помощью генератора DKIM и опубликуйте выровненную политику через генератор DMARC.
Выберите следующий инструмент по типу данных: получатель, поиск адресов, DNS и инфраструктура или процесс отправителя.
Бесплатные инструменты
Создайте корректную SPF DNS-запись для домена за секунды. Добавьте почтовые серверы, директивы include и выберите политику. Бесплатно, без регистрации.
Данные о домене или инфраструктуре — не подтверждение существования ящика.
Бесплатные инструменты
Проверьте запись DKIM для любого домена и селектора. Посмотрите полный открытый ключ и правильность настройки подписи. Бесплатно, без регистрации.
Данные о домене или инфраструктуре — не подтверждение существования ящика.
Бесплатные инструменты
Проверьте запись DMARC любого домена. Политика, выравнивание, адреса отчётов и корректность настройки. Бесплатно, без регистрации.
Данные о домене или инфраструктуре — не подтверждение существования ящика.
Бесплатные инструменты
Проверьте записи A, AAAA, MX, TXT, NS или CNAME для любого домена. Живой DNS-запрос с мгновенным результатом. Бесплатно, без регистрации.
Данные о домене или инфраструктуре — не подтверждение существования ящика.
Инструменты email
Запустите тест доставляемости email на реальном образце письма. Проверьте SPF, DKIM, DMARC, DNS, blacklist, спам-фильтр, заголовки и содержимое.
Диагностика отправителя или письма — не поиск адресов.
Инструменты проверки email
Проверьте, действителен ли email, бесплатным верификатором: синтаксис, MX, SMTP-ящик, disposable, role и catch-all.
Данные о получателе — не о отправителе и не о DNS-конфигурации.
Домен без SPF-записи не проходит проверки SPF. Принимающие серверы считают это нейтральным результатом, но вместе с другими сигналами это повышает вероятность попадания в спам. Google и Yahoo теперь требуют SPF-записи у всех массовых отправителей. Любой домен, с которого отправляют почту, должен опубликовать SPF-запись.
Две или более TXT-записи, начинающиеся с v=spf1, на одном домене вызывают постоянную ошибку SPF (permerror). Проверка SPF полностью срывается, и вся почта с этого домена не проходит SPF. Все правила нужно объединить в одну SPF-запись.
SPF fail означает, что IP-адрес доставки не авторизован в SPF-записи домена. Результат зависит от механизма all: ~all даёт softfail (подозрительно, но обычно письмо всё же доставляется), а -all — hardfail (как правило, отклоняется или уходит в спам). Нейтральный результат ?all не влияет ни в ту, ни в другую сторону.
Permerror (постоянная ошибка) возникает, когда SPF нельзя проверить из-за ошибки конфигурации — чаще всего потому, что у домена больше одной SPF-записи или в записи слишком много механизмов с DNS-запросами (более 10). Исправляйте permerror сразу: из-за них вся почта с вашего домена не проходит SPF.
SPF допускает не более 10 DNS-запросов при проверке. Каждый механизм include, a, mx, ptr и exists считается за один запрос, вложенные include тоже учитываются. Превышение 10 запросов в сумме даёт permerror.
Если SPF-запись приближается к лимиту в 10 DNS-запросов, рассмотрите SPF flattening — разрешите все include до реальных IP-адресов и замените механизмы include прямыми записями ip4/ip6. Это снижает число запросов по этим элементам до нуля, но запись придётся обновлять каждый раз, когда провайдер меняет диапазоны IP.
SPF — первый шаг. Добавьте DKIM и DMARC, чтобы полностью защитить домен. Затем поддерживайте чистоту списка с проверкой адресов BillionVerify.
600 кредитов/мес + бонус 20/день · Точность SMTP 99,9% · Мгновенный доступ к API · Банковская карта не нужна
