Докладът за SPF PermError: 100× Повече Домейни Нарушават Лимита от 10 Търсания, Отколкото Показват Повърхностните Броячи (2026)

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

Данни към 2026-06-29 · методология v7, плюс проход за ценообразуване на веригите, проведен на 2026-07-03. От преброяването на 261 милиона оценени домейна, разрешихме всяка SPF include: цел, референцирана 100 или повече пъти — 10,842 цели, покриващи 95.2% от всички включвания — и оценихме задържаната верига на всеки домейн спрямо тази карта. Неразрешените крайни цели са преброени като нула, а съдържанието на веригите отразява деня на разрешаване, затова заглавната цифра е консервативна, пристрастна към долната граница апроксимация: казваме „поне”. Само агрегирано; никога запис на отделен бизнес. Вижте как оценяваме.

Колко домейна нарушават SPF лимита от 10 търсания?

Поне 797,263 — защото SPF има вграден самоунищожител в стандарта, а задействателят се крие там, където собствениците не могат да го видят. RFC 7208 §4.6.4 ограничава SPF проверката до 10 DNS търсания; след десет получателят спира и връща PermError, а PermError записът не осигурява никаква защита. Броете само търсанията, видими в самия запис — както правят повечето инструменти и нашето собствено преброяване до този доклад — и ще намерите около 8 000 нарушители (7,958, точно казано). Оценете include: веригите, които тези записи действително изтеглят, и броят достига 797,263: приблизително 100 пъти по-голям.

Защо собствениците не могат да го видят предварително?

Защото бюджетът се изразходва от чуждите записи. include:onetool.example.com изглежда като един ред в DNS панела ви — но получателят трябва да извлече и този запис, и да брои всеки механизъм за търсене, който той съдържа, рекурсивно. Запис с три включвания може да струва единадесет. Нищо в собствената ви зона не се е промени в деня, в който сте надхвърлили; доставчик е вложил още едно включване, и SPF ви е умрял без предупреждение.

По-лошото е, че DMARC третира PermError като неуспех при SPF крака — така домейн, счупил SPF по този начин, сега не успява половината от собственото си удостоверяване.

Какво откри ценообразуването на веригите

Находка	Домейни
Над лимита от 10 търсания, вериги оценени	797,263
Над лимита, броейки само видими механизми	7,958
Над лимита докато завършва в строго `-all`	112,215
Точно при 9–10 търсания — ръба на пропастта	2,119,539

Две истории в тази таблица — третата, ръбът на пропастта, получава собствена секция по-долу:

Повърхностните броячи пропускат ~99% от счупването. Видимият брой механизми открива 7,958; оценяването на веригите открива 797,263. Почти всичките щети са наследени от това, което включванията включват.
112,215 от счупените записи завършват с -all. Техните собственици са направили всичко правилно — покатерили стената, избрали строгия завършек — и едно твърде много включване е анулирало всичко. Изглеждащ строг и счупен е най-суровият режим на неуспех в сигурността на имейла.

2.1 милиона домейна са на един инструмент от пропастта

Числото, което трябва да притесни читателите, в момента наред: 2,119,539 домейна разрешават до точно 9 или 10 търсания — под лимита днес, мъртви в деня, в който някой свърже още една платформа. Това е приблизително 1 на 66 от всички SPF публикуващи, и съответства на формата на разпределението: 99-ят процентил SPF запис вече е при 9 търсания. Регистрирайте се за още един маркетинг инструмент, поставете ред „само добавете това включване”, и запис, бил под лимита сутринта, е невалиден по обед.

Чия е грешката? Все повече на стека

Най-големите доставчици тихо са изравнили SPF — _spf.google.com на Google и spf.protection.outlook.com на Microsoft сега се разширяват до прости IP списъци, коставащи нула вътрешни търсания (потвърдихме и двата срещу живо DNS по време на този анализ). Преливанията идват от другаде: хостинг-панел вериги, вложени три нива дълбоко, регионални доставчици, чието включване струва 7–10 търсания само по себе си, и честното натрупване на SaaS — пощенска кутия плюс бюлетин плюс CRM плюс helpdesk, всяко „само едно включване”. Почти никой не добавя единадесетото търсане нарочно. То пристига като сбор от разумни решения.

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

Преброете реалния си общ брой — нашата безплатна проверка разрешава веригата ви, или използвайте произволен брояч на SPF търсания.
Изчистете мъртвото тегло: инструменти, спрели да използвате, дублиращи се включвания и остарелия ptr механизъм.
Изравнявайте само онова, което контролирате. Замяната на дълбоко включване с IP блокове работи за собствената ви инфраструктура; IP адресите на трети страни се променят без предупреждение.
Дайте на масовите изпращачи поддомейн. Бюлетините от news.yourdomain.com получават собствен запис и собствен бюджет от 10 търсания.

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

Какво е SPF лимитът от 10 DNS търсания? RFC 7208 §4.6.4 позволява най-много 10 DNS търсания за оценяване на един SPF запис — броейки търсанията вътре в всяко include: рекурсивно. Надхвърлянето му връща PermError: записът се третира като невалиден и не осигурява никаква защита.

Какво означава SPF PermError? Постоянна грешка при оценяване — получателят не е могъл да обработи записа ви (твърде много търсания, множество записи или счупен синтаксис) и третира домейна ви като нямащ използваем SPF. DMARC го брои като неуспех при SPF крака.

Колко домейна надвишават SPF лимита на търсания? Поне 797,263 от 139 милиона SPF публикуващи, според нашия проход за ценообразуване на вериги — около 100× повече от 7,958 видими без разрешаване на вериги. Още 2,119,539 са при 9–10 търсания, на едно включване от лимита.

PermError спира ли доставянето на имейл? Обикновено не — получателите продължават без SPF, и пощата ви се носи на DKIM и репутация. Което спира да работи е защитата: фалшификаторите вече не се отхвърлят, и всяка DMARC проверка на пощата ви губи SPF крака. Невидимо е, докато не стане скъпо.

Как да намаля броя на SPF търсанията? Премахнете неизползваните включвания и ptr, изравнете собствената инфраструктура до ip4:/ip6:, преместете масовите изпращачи на поддомейни и прешроявайте след всеки нов инструмент. Ръководството за поправка ви води през него.

Разберете реалния си брой

Механизмите, които можете да видите, не са вашият брой на търсанията — разрешеният брой е този, който получателите изчисляват, и е 30-секундна проверка.

Проверете своя домейн → · Поправете SPF → · Моделът за зрялост на SPF → · Два SPF записа = никакъв → · Клопката ptr → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.