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

SPF PermError: как да поправите „твърде много DNS търсения” без да счупите имейла (2026)

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

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

Поне 797,263 домейна надхвърлят ограничението на SPF от 10-DNS-търсения, според census на Defaults.Exposed за 261,086,232 домейна — от 139 милиона публикуващи SPF. След десет търсения получателят спира и връща PermError: вашият SPF е анулиран и DMARC брои PermError като неуспех.

Поправката има строг ред и повечето ръководства го изписват наопаки. Преброите реалните, разрешени търсения; изтрийте мъртвите и неизползваните includes — само това поправя повечето записи; преместете масовите изпращачи на поддомейни с техен собствен SPF бюджет; изравнявайте само като последна мярка и само с автоматизирано ре-изравняване, защото статичното изравняване изгнива и безшумно прекъсва доставянето.

Какво означава „SPF PermError: твърде много DNS търсения”?

RFC 7208 §4.6.4 ограничава всяка SPF проверка до 10 DNS търсения. След десет получателят спира и връща PermError — целият запис се третира като счупен, не само частта над бюджета. Същият раздел добавя по-малко известен втори таван: не повече от 2 „празни търсения” (заявки, връщащи без отговор или NXDOMAIN), така че два мъртви include: записа за анулирани услуги могат да анулират SPF сами по себе си.

Последствието е по-лошо от „без SPF”: DMARC третира PermError като SPF неуспех, така че домейн, счупващ собствения си SPF, е неавтентикиран по SPF компонента на всяка DMARC оценка. Ако DKIM не е настроен или се разпада при транзит, пощата вече изцяло не преминава DMARC.

Едно число от census показва колко жесток е този режим на неуспех: 112,215 домейна публикуват строг -all запис, анулиран от препълване на търсенията — от 54,655,923 домейна, публикуващи изобщо -all. Собствениците им са направили трудното — избрали са строгия край — и един include повече е изключил целия запис. Изглеждат строги; те са счупени. За пълната картина с данни, вижте доклада за SPF PermError.

Защо SPF ми се счупи, без да съм сменял нищо?

Защото бюджетът се изразходва предимно от чужди записи. Всеки include: се оценява рекурсивно и всеки механизъм за търсения вътре в него се брои срещу вашите десет. Един ред в DNS панела може да струва четири или пет търсения след разрешаване. Доставчик добавя още един include и SPF ви умира без единична промяна в зоната ви.

Основните платформи не са проблемът: Google и Microsoft са изравнили собствения си SPF — _spf.google.com и spf.protection.outlook.com се разгъват до прости IP списъци, струващи нула вътрешни търсения (проверено спрямо живия DNS, юли 2026). Реалните взривове идват от дълбоко вложени вериги с includes от хостинг панели и от честно натрупване на SaaS — пощенска кутия плюс бюлетин плюс CRM плюс helpdesk, всяко „само един include”. Никой не добавя единадесетото търсене нарочно; то пристига като сума от разумни решения. Затова ръбът е толкова претъпкан: 2,119,539 домейна стоят на точно 9–10 разрешени търсения — приблизително 1 на 66 от всички публикуващи SPF, наред днес, анулирани в деня на поставяне на още един include. 99-ото процентилно SPF записа вече разрешава до 9 търсения. Ако стекът ви е тежко SaaS-ориентиран, ръководството за SPF неуспех при SaaS инструменти покрива версията за всеки доставчик.

Кои части на SPF запис се броят като DNS търсения?

Преброите разрешения, а не видимите редове. Четири includes може да са четири или четиринадесет търсения.

Как да поправя „твърде много DNS търсения” без да счупя имейла?

1. Стартирайте безплатното сканиране преди да докоснете DNS. То разрешава цялата ви верига с includes и показва реалния брой търсения, за да поправите действителния проблем — не записа, такъв какъвто изглежда в панела. (Ако казва, че изобщо нямате SPF, това е различен неуспех — вижте „SPF запис не е намерен”.)
2. Първо изтрийте мъртвите и неизползваните includes. Инструментът, изоставен през 2023 г., include на стария хост, оцелял след миграция, дубликати, всеки механизъм ptr. Мъртвите includes са двойно токсични: изгарят бюджет за търсения и са обичайният источник на празни търсения. Повечето надбюджетни записи се върнат под 10 в тази стъпка. Ако записът ви все още носи механизмите на предишен доставчик, следвайте ръководството за почистване след миграция.
3. Проверете дали всеки останал include прави нещо. Получателите оценяват SPF спрямо домейна на Return-Path (RFC5321.MailFrom), а не заглавието From — и много SaaS инструменти поставят собствения си домейн за отвърнати писма в Return-Path, така че include им в записа ви не прави нищо освен да изразходва бюджет. Запазвайте includes само за услуги, използващи вашия домейн като Return-Path; за останалите активирайте DKIM с персонализиран домейн на доставчика.
4. Преместете масовите изпращачи на поддомейни. Бюлетини от news.yourdomain.com, транзакционна поща от mail.yourdomain.com. Всеки поддомейн получава собствен SPF запис с нов бюджет от 10 търсения и проблем в един поток спира да се разпространява към останалите.
5. Само тогава обмисляйте изравняване — и само автоматизирано изравняване. Вижте по-долу.
6. Сканирайте отново за потвърждение, че сте удобно под 10 — целете резерв, а не точно 10, иначе просто сте се върнали към 2.1 милиона домейна на ръба. После преминете през всичко останало, маркирано от сканирането на страницата поправяне на SPF.

Трябва ли да изравнявам SPF записа си?

Изравняването замества includes с базисните им ip4:/ip6: блокове, струващи нула търсения. Работи — и направено на ръка, е отложена авария при доставяне.

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

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

SPF PermError означава ли, че доставянето на имейла ми спира? Не моментално — затова е опасен. DMARC брои PermError като SPF неуспех, така че доставянето разчита изцяло на DKIM; ако DKIM липсва или се разпада при транзит, не преминавате DMARC. От 139 милиона публикуващи SPF в census (към 2026-06-29), поне 797,263 са в това положение — повечето без да знаят.

Записът ми има само четири includes — как може да е над 10 търсения? Includes се броят рекурсивно: всичко вътре в всеки include (и вътре в неговите includes) се начислява към бюджета ви, така че четири видими реда може да се разрешат до четиринадесет търсения. Броете с разрешаващ инструмент, а не на окото — разрешаването на веригите е как докладът ни за PermError откри ~100× повече счупени домейни от показаното при повърхностно броене.

Записът ми завършва с -all — нали съм защитен? Само ако записът се оценява. Census (към 2026-06-29) откри 112,215 домейна, чиито строги -all записи са анулирани от препълване на търсенията. Строг квалификатор на PermError запис не предпазва от нищо.

Ограничението 10 търсения ли е за всеки include или за целия запис? За цялата оценка: RFC 7208 §4.6.4 ограничава пълната проверка до 10, плюс не повече от 2 празни търсения. Всеки поддомейн има собствен запис и бюджет — затова стъпка 4 работи.

Броят ли ip4 и ip6 записи към лимита? Не — IP механизмите не струват нищо, което е именно защо изравняването намалява броя.

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

Ако поправяте това за клиент или работодател, завършете с доказателство. Пуснете отново безплатното сканиране след промените ви и препратете оценения доклад на собственика на бизнеса: разбираем език, датиран, PermError изчезнал. Това е артефактът, от който ще се нуждаят за подновяване на киберзастраховката и следващия въпросник за сигурност на клиента — разликата между „сменил съм някои DNS записи” и документиран преди-и-след.

Проверете вашия домейн безплатно

Вижте реалния, разрешен брой търсения — и всичко останало за SPF, DKIM и DMARC — поверително и само за собственика.

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