Defaults.Exposed › Поправки › Guides

„SPF запис не е намерен” — но имате такъв? Петте истински причини (2026)

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

Данни към 2026-06-29 · методология v7. Обобщени данни от census за 261 милиона оценени домейна. Вижте как оценяваме.

Ако проверяващ казва „SPF запис не е намерен”, но сте сигурни, че сте го публикували, записът обикновено е невидим, а не липсващ: 1,013,416 домейна — около един на 138 от опитващите SPF — публикуват два или повече SPF записа, PermError (RFC 7208 §3.2), за който много проверяващи съобщават като не-намерен, според census на Defaults.Exposed за 261 милиона домейна.

Има пет истински причини, всички поправими в едно сядане: грешен хост, дублиран запис, грешен DNS тип или наострено цитиране, непоследователни сървъри за имена или конфликт с дължина/CNAME. По-долу: 60-секундният тест за всяка, в реда за проверка, след това стъпките за поправяне.

Сигурни ли сте, че записът действително съществува?

Започнете с неласкавата възможност, защото тя е най-честата с огромна разлика: от 261,086,232 домейна, оценени в census на Defaults.Exposed, 121,145,609 — 46.4% — нямат изобщо SPF запис. Много случаи „но аз го настроих” се оказват запис, добавен в стейджинг зона или стар DNS доставчик, вече неавторитативен. Проверете DNS доставчика, към когото сочат сървърите ви за имена (често не е регистраторът ви) за TXT запис, започващ с v=spf1. Ако наистина го няма, пропуснете детективската работа и отидете директно на поправяне на SPF записа ви.

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

Уеб проверяващите запитват DNS чрез собствения си кеширащ резолвер. За да видите истината, попитайте авторитативния сървър за имена на домейна ви директно:

# намерете авторитативните сървъри за имена
dig NS yourdomain.com +short

# попитайте един от тях директно за TXT записи
dig TXT yourdomain.com @ns1.yourdnshost.com +short

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

Две правила за интерпретация. Първо, преброите редовете, започващи с v=spf1 — броят е толкова важен, колкото и съдържанието. Второ, проверете дали сте запитали правилното ime: получателите оценяват SPF спрямо домейна в Return-Path (RFC5321.MailFrom, „envelope from”) — а не адреса From, видян от получателите. Ако инструментът ви за бюлетини отвръща поща чрез bounce.yourdomain.com, перфектен запис на върха не е записът, търсен от получателите.

Кои са петте истински причини?

Данни към 2026-06-29.

1. Записът на грешния хост ли е?

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

2. Имате ли два SPF записа?

Главната причина и най-подвеждащото съобщение за грешка при имейл автентикацията. RFC 7208 §3.2 е директен: домейнът трябва да има точно един SPF запис. Два или повече е PermError — получателите третират SPF като анулиран. Някои проверяващи съобщават точно за това положение („намерени са множество записи”); други съобщават за нетния ефект: не е намерен валиден SPF запис. Виждате запис в панела и заключвате, че проверяващият е счупен. Не е — имате един запис повече.

Census откри 1,013,416 домейна, носещи два или повече SPF записа — около един на 138 от домейните, опитващи SPF — всеки с ефективно изключен SPF. Обикновено се случва при смяна на доставчик: инструментът за настройка на новия доставчик добавя нов запис вместо да редактира стария. Поправката е сливане, никога втори запис: комбинирайте всичко в един ред v=spf1 … ~all и изтрийте останалите. Докладът ни с данни два SPF записа равняват нула разгражда как един милион домейна са стигнали дотам; ако е започнало след миграция, вижте SPF спря да работи след смяна на доставчик. При сливане, не конкатенирайте сляпо всеки include: — всеки изразходва DNS търсения срещу твърдата граница от 10, разменяйки не-намерен за PermError: твърде много DNS търсения.

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), всеки резолвер може да види новия отговор. Все още не е намерен след 24 часа? Разпространението не е причината.

Двамата истински виновници: негативно кеширане — резолвер, запитал ви преди да сте добавили записа, кешира отговора „такъв запис не съществува” до изтичането на негативния TTL — и непоследователни сървъри за имена след миграция, при която домейнът все още изброява сървърите за имена на стария доставчик заедно с новите и половин свят чете зона, вече нередактирана от вас. Запитайте всеки изброен сървър за имена директно; ако отговорите се различават, намерили сте го. Поправете NS делегирането при регистратора, така че само доставчикът, когото действително редактирате, е авторитативен.

5. Записът твърде дълъг ли е или блокиран от CNAME?

Единичен низ в TXT запис максимум достига 255 символа. По-дългите SPF записи са законни, но трябва да бъдат разделени на множество цитирани низове в рамките на един запис — и интерфейсите на DNS доставчиците редовно объркват разделянето, трунктирайки стойността или счупвайки я по средата на механизъм, така че вече не се парсва. Ако записът ви е дълъг, проверете изхода dig за стойност, прекъснала се рязко.

Отделно, DNS забранява TXT запис на ime, вече имащо CNAME. Ако mail.yourdomain.com е CNAME за вашия доставчик, не можете да поставите и SPF там — някои панели го приемат и после сервират само CNAME. Поставете записа там, където сочи CNAME (ако го контролирате), или преструктурирайте така, че изпращащото ime да не е с CNAME. Доставчиците с чисто TXT обработване правят и двете по-лесно — вижте ръководството за настройка на SPF за Cloudflare.

Как да го поправите стъпка по стъпка?

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

Често задавани въпроси

Защо проверяващият казва „не е намерен”, когато виждам записа в DNS панела? Обикновено причина 2 или 4: втори v=spf1 запис прави и двата анулирани — PermError, за който някои инструменти съобщават като не-намерен, положението, в което са 1,013,416 домейна към 2026-06-29 — или панелът ви не е 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 оценени в census на Defaults.Exposed (към 2026-06-29), не публикуват изобщо SPF. Не-намерен е стандартното положение в интернет.

Изпратете на собственика доклада

След като записът се разрешава чисто, пуснете отново сканирането и препратете оценения доклад на собственика на бизнеса или клиента, чийто домейн е това. Показва, разбираемо, какво е счупено, какво сте поправили и накъде стои домейнът — точно доказателството, от което ще бъдат попитани при подновявания на киберзастраховка и въпросници за сигурност от доставчик. Докладът е разписката за свършената работа.

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

Вижте в кое от петте положения „не е намерен” се намирате — поверително и само за собственика.

Проверете вашия домейн → · Поправяне на SPF → · SPF спря след смяна на доставчик → · Как оценяваме → · Само обобщени данни. Данните се съхраняват и обработват в ЕС.