Defaults.Exposed

Defaults.Exposed › Звіти

Звіт про SPF PermError: у 100× більше доменів перевищують ліміт у 10 запитів, ніж показують поверхневі підрахунки (2026)

Опубліковано 2026-07-03

Показники станом на 2026-06-29 · методологія v7, плюс прохід із розцінюванням ланцюжків, виконаний 2026-07-03. З перепису 261 мільйонів оцінених доменів ми розв’язали кожну ціль SPF include:, на яку посилаються 100 або більше разів — 10,842 цілей, що покривають 95.2% усіх посилань include, — і розцінили збережений ланцюжок кожного домену за цією картою. Нерозв’язані цілі «хвоста» рахувалися як нуль, а вміст ланцюжків відображає день розв’язання, тож заголовний показник є консервативним, зміщеним до нижньої межі наближенням: ми кажемо «щонайменше». Лише агрегат; ніколи не запис окремого бізнесу. Див. як ми оцінюємо.

Скільки доменів перевищують ліміт 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-панелі — але отримувач мусить завантажити й той запис теж, і порахувати кожен механізм запиту, який він містить, рекурсивно. Запис із трьома include може коштувати одинадцять. У вашій власній зоні того дня, коли ви перевищили ліміт, нічого не змінилося; провайдер вклав ще один include, і ваш SPF помер без попередження.

Гірше того, DMARC трактує PermError як провал на ланці SPF — тож домен, який зламав свій SPF у такий спосіб, тепер провалює половину власної автентифікації.

Що виявило розцінювання ланцюжків

ЗнахідкаДомени
Понад ліміт у 10 запитів, ланцюжки розцінені797,263
Понад ліміт, рахуючи лише видимі механізми7,958
Понад ліміт при завершенні суворим -all112,215
Рівно на 9–10 запитах — край прірви2,119,539

Дві історії в цій таблиці — третя, край прірви, має власний розділ нижче:

2.1 мільйонів доменів за один інструмент від прірви

Число, яке має турбувати читачів, у яких наразі все гаразд: 2,119,539 доменів розв’язуються рівно до 9 або 10 запитів — сьогодні під лімітом, мертві того дня, коли хтось під’єднає ще одну платформу. Це приблизно 1 із 66 усіх публікаторів SPF, і це відповідає формі розподілу: 99-й перцентиль запису SPF уже стоїть на 9 запитах. Підпишіться на ще один маркетинговий інструмент, вставте його рядок «просто додайте цей include», і запис, який був під лімітом за сніданком, стане недійсним до обіду.

Чия це провина? Дедалі частіше — стека

Найбільші провайдери тихо сплюснули свій SPF — Google _spf.google.com і Microsoft spf.protection.outlook.com тепер розгортаються у прості списки IP, що коштують нуль внутрішніх запитів (ми перевірили обидва за живим DNS під час цього аналізу). Вибухи приходять звідінде: ланцюжки хостинг-панелей, вкладені на три рівні вглиб, регіональні провайдери, чий include сам по собі коштує 7–10 запитів, і чесне накопичення SaaS — поштова скринька плюс розсилка плюс CRM плюс служба підтримки, кожен «лише один include». Майже ніхто не додає одинадцятий запит навмисно. Він з’являється як сума розумних рішень.

Як перевірити та виправити свій — безкоштовно

  1. Порахуйте свій справжній підсумокнаша безкоштовна перевірка розв’язує ваш ланцюжок, або скористайтеся будь-яким лічильником запитів SPF.
  2. Приберіть баласт: інструменти, якими ви перестали користуватися, дублікати include та застарілий механізм ptr.
  3. Сплющуйте лише те, що контролюєте. Заміна глибокого include його IP-блоками працює для вашої власної інфраструктури; сторонні IP змінюються без попередження.
  4. Виділіть масовим відправникам піддомен. Розсилки з 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 запитах, за один include від ліміту.

Чи зупиняє PermError доставку моєї пошти? Зазвичай ні — отримувачі продовжують без SPF, а ваша пошта тримається на DKIM і репутації. Що перестає працювати — це захист: фальсифікатори більше не відхиляються, а кожна перевірка DMARC вашої пошти втрачає свою ланку SPF. Це непомітно, доки не стане дорого.

Як зменшити кількість моїх запитів SPF? Приберіть невикористовувані include та ptr, сплющіть власну інфраструктуру до ip4:/ip6:, перенесіть масових відправників на піддомени й перераховуйте після кожного нового інструмента. Посібник із виправлення проведе вас крок за кроком.

Дізнайтеся своє справжнє число

Механізми, які ви бачите, — це не ваша кількість запитів; розв’язане число — те, яке обчислюють отримувачі, і це перевірка на 30 секунд.

Перевірте свій домен → · Виправити SPF → · Модель зрілості SPF → · Два записи SPF = жодного → · Пастка ptr → · Лише агрегатні дані. Дані зберігаються та обробляються в ЄС.