Defaults.Exposed › Исправления › Guides

"SPF Record Not Found" — но запись у вас есть? 5 настоящих причин (2026)

Опубликовано 2026-07-08

Цифры по состоянию на 2026-06-29 · методология v7. Агрегированные данные переписи по 261 млн оценённых доменов. См. как мы ставим оценки.

Если чекер говорит “SPF record not found”, а вы уверены, что публиковали запись, то запись обычно невидима, а не отсутствует: 1 013 416 доменов — примерно один из 138 среди пытающихся настроить SPF — публикуют две и более SPF-записи, а это PermError (RFC 7208 §3.2), который многие чекеры показывают как not-found, по данным переписи Defaults.Exposed, охватившей 261 млн доменов.

Настоящих причин пять, и все исправимы за один присест: не тот хост, дублирующая запись, неправильный тип DNS-записи или искалеченные кавычки, несогласованные серверы имён, конфликт длины или CNAME. Ниже: 60-секундный тест для каждой, в порядке проверки, а затем шаги исправления.

Вы уверены, что запись вообще существует?

Начните с нелестной версии, потому что она с большим отрывом самая частая: из 261 086 232 доменов, оценённых в переписи Defaults.Exposed, 121 145 609 — 46,4% — не имеют SPF-записи вообще. Немало случаев «но я же это настраивал» оказываются записью, добавленной в тестовую зону или к старому DNS-провайдеру, который больше не авторитативен. Проверьте у того DNS-провайдера, на которого реально указывают ваши серверы имён (часто это не ваш регистратор), TXT-запись, начинающуюся с v=spf1. Если её там действительно нет, пропустите детективную работу и идите сразу к странице исправить SPF-запись.

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

Веб-чекеры запрашивают DNS через собственный кэширующий резолвер. Чтобы увидеть правду, спросите авторитативный сервер имён вашего домена напрямую:

# find the authoritative nameservers
dig NS yourdomain.com +short

# ask one of them directly for TXT records
dig TXT yourdomain.com @ns1.yourdnshost.com +short

В Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Два правила интерпретации. Первое: посчитайте строки, начинающиеся с v=spf1, — количество важно не меньше содержимого. Второе: проверьте, что вы запросили правильное имя: получатели проверяют SPF по домену из Return-Path (RFC5321.MailFrom, «envelope from») — а не по адресу From, который видят получатели. Если ваш инструмент рассылок возвращает отлупы через bounce.yourdomain.com, идеальная запись на корневом домене — не та запись, которую ищут получатели.

Каковы пять настоящих причин?

Данные по состоянию на 2026-06-29.

1. Запись не на том хосте?

Классика: SPF добавлен на mail.yourdomain.com, а почта заявляет, что идёт с yourdomain.com, или наоборот. SPF не наследуется вниз — запись на корневом домене ничего не говорит о поддоменах, и наоборот. Публикуйте ровно на том имени, которое стоит в вашем Return-Path. Поставщику, отправляющему со своего bounce-поддомена, нужна запись на этом поддомене — обычно CNAME или TXT, которые выдаёт сам поставщик (руководство по настройке SPF на GoDaddy показывает, где находятся эти поля).

2. У вас две SPF-записи?

Главная причина — и самое обманчивое сообщение об ошибке во всей аутентификации почты. RFC 7208 §3.2 прямолинеен: у домена должна быть ровно одна SPF-запись. Две и более — это PermError: получатели считают ваш SPF недействительным. Одни чекеры сообщают об этом состоянии точно (“multiple records found”); другие сообщают итоговый эффект: no valid SPF record found. Вы видите запись в панели и решаете, что чекер сломан. Он не сломан — у вас на одну запись больше, чем нужно.

Перепись нашла 1 013 416 доменов с двумя и более SPF-записями — примерно один из 138 среди доменов, пытающихся настроить SPF, — и у каждого SPF фактически выключен. Обычно это происходит при смене провайдера: мастер настройки нового провайдера добавляет свежую запись вместо правки старой. Исправление — слияние, никогда не вторая запись: объедините всё в одну строку v=spf1 … ~all и удалите остальные. Наш аналитический отчёт две SPF-записи равны нулю разбирает, как миллион доменов сюда попал; если это началось после миграции, см. SPF перестал работать после смены провайдера. При слиянии не склеивайте вслепую каждый include: — каждый стоит DNS-запросов против жёсткого лимита SPF в 10, и вы обменяете not-found на PermError: too many DNS lookups.

3. Вы опубликовали не тот тип записи — или интерфейс её искалечил?

У раннего SPF был собственный тип DNS-записи (тип 99, буквально названный “SPF”). Он объявлен устаревшим: RFC 7208 требует TXT, и получатели не запрашивают тип 99. Некоторые DNS-панели всё ещё предлагают “SPF” в выпадающем списке типов записей; выберите его — и ваша запись будет настоящей, корректной и невидимой. Проверьте колонку типа и переопубликуйте как TXT.

Более тонкий родственный случай — кавычки. Вставка значения, обёрнутого в кавычки, в поле, которое добавляет собственные кавычки, даёт ""v=spf1 …"" — а это больше не начинается с v=spf1, так что для верификатора записи не существует. Вывод dig показывает правду; DNS-панель часто косметически её скрывает.

4. Это правда «ещё распространяется»?

«Дайте 24–48 часов на распространение» — самый избыточно прописываемый совет в DNS. Распространение — это всего лишь истечение кэшей: как только TTL записи истёк (обычно 1 час, редко больше 24), каждый резолвер может увидеть новый ответ. Всё ещё not-found спустя 24 часа? Распространение — не причина.

Два настоящих виновника: отрицательное кэширование — резолвер, который искал вас до добавления записи, кэширует ответ «такой записи нет» до истечения отрицательного TTL — и несогласованные серверы имён после миграции, когда у домена наряду с новыми всё ещё перечислены серверы имён старого провайдера и половина мира читает зону, которую вы больше не редактируете. Запросите каждый перечисленный сервер имён напрямую; если ответы различаются — вы нашли причину. Исправьте NS-делегирование у регистратора, чтобы авторитативным был только тот провайдер, которого вы реально редактируете.

5. Запись слишком длинная или заблокирована CNAME?

Одна строка в TXT-записи ограничена 255 символами. Более длинные SPF-записи допустимы, но должны быть разбиты на несколько строк в кавычках внутри одной записи — и интерфейсы DNS-провайдеров регулярно портят это разбиение, обрезая значение или разрывая его посреди механизма так, что оно перестаёт разбираться. Если ваша запись длинная, проверьте в выводе dig, не обрывается ли значение внезапно.

Отдельно: DNS запрещает TXT-запись на имени, у которого уже есть CNAME. Если mail.yourdomain.com — CNAME на вашего провайдера, разместить там же SPF нельзя — некоторые панели это принимают, а затем отдают только CNAME. Разместите запись там, куда указывает CNAME (если вы это контролируете), или перестройте схему так, чтобы отправляющее имя не было под CNAME. С провайдерами, аккуратно работающими с TXT, и то и другое проще — см. руководство по настройке SPF на Cloudflare.

Как это исправить, шаг за шагом?

1. Запустите бесплатную проверку на defaults.exposed — сервис читает ваш живой DNS и говорит, в каком из пяти состояний вы находитесь, прежде чем вы что-либо тронете.
2. Подтвердите, какие серверы имён авторитативны (dig NS) и что все они дают одинаковый ответ.
3. Запросите TXT у авторитативного сервера имён по точному домену из Return-Path.
4. Посчитайте строки v=spf1: ноль → опубликуйте одну; две и более → объедините в одну.
5. Проверьте, что тип — TXT, значение начинается ровно с v=spf1, и в него не пробрались лишние кавычки или обрезка.
6. Переждите один TTL, затем пересканируйте и убедитесь, что запись везде разрешается чисто.

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

Почему чекер говорит “not found”, когда я вижу запись в своей DNS-панели? Обычно причина 2 или 4: вторая запись v=spf1 делает обе недействительными — PermError, который некоторые инструменты показывают как not-found; в этом состоянии по состоянию на 2026-06-29 находятся 1 013 416 доменов — либо ваша панель не тот DNS, который реально авторитативен.

Сколько ждать, пока чекеры увидят моё исправление? Один TTL — обычно час, максимум 24. Дольше — и «распространение» уже не объяснение; перепроверьте пять причин, начиная с согласованности серверов имён.

Стоит ли использовать тип записи “SPF”, который предлагает моя DNS-панель? Нет. Тип 99 устарел; RFC 7208 требует только TXT. Запись типа 99 невидима для современных получателей.

Запись теперь находится — почему моя почта всё равно не проходит SPF? Потому что SPF проверяется по домену Return-Path, а не по заголовку From, и запись должна реально перечислять серверы, которые отправляют за вас. Найденная запись — это шаг первый; о прохождении — руководство исправить SPF-запись.

Неужели отсутствие SPF-записи настолько распространено? Да — 121 145 609 доменов, 46,4% из 261 086 232 оценённых в переписи Defaults.Exposed (по состоянию на 2026-06-29), не публикуют SPF вообще. Not-found — состояние интернета по умолчанию.

Отправьте владельцу отчёт

Как только запись начнёт разрешаться чисто, перезапустите проверку и перешлите отчёт с оценкой владельцу бизнеса или клиенту, чей это домен. Он простым языком показывает, что было сломано, что вы исправили и где домен находится теперь, — ровно то свидетельство, которое у него попросят при продлении киберстраховки и в анкетах по безопасности для поставщиков. Отчёт — это квитанция за работу.

Проверьте свою SPF-запись бесплатно

Посмотрите, в каком из пяти состояний not-found находится ваш домен, — приватно и только для владельца.

Проверить свой домен → · Исправить SPF → · SPF сломался после смены провайдера → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.