Defaults.Exposed › Звіти

Чому мій SPF не працює? Проблема 10 запитів SaaS для відправників у Великобританії та ЄС (2026)

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

Дані станом на 2026-06-29 · методологія v7. Зведені дані перепису по 261 мільйонах оцінених доменів. Дивіться як ми виставляємо оцінки.

Коли SPF перестає працювати у компанії, яка використовує SaaS-інструменти у Великобританії або ЄС, найімовірнішою причиною є одне правило RFC, про яке вам ніколи не доводилося думати: після 10 DNS-запитів SPF не повертає «fail» — він повертає PermError, що означає: запис трактується так, ніби його не існує. Щонайменше 797,263 доменів вже перетнули цю межу. Ще 2,119,539 знаходяться рівно на 9–10 запитах — і лише один новий інструмент відділяє їх від такого самого обриву.

Чому SPF ламається при підключенні нового SaaS-інструменту?

SPF працює, перелічуючи поштові сервери, яким дозволено відправляти листи від імені вашого домену. Сучасні компанії не використовують власні поштові сервери — вони використовують Google Workspace для внутрішнього листування, Mailchimp для розсилок, HubSpot для торговельних послідовностей, Pipedrive для CRM-комунікацій. Кожна платформа надає вам рядок include:, який потрібно вставити в DNS.

Проблема: кожен include: сам по собі є DNS-запитом. А кожен запис всередині цього include може рекурсивно ініціювати нові запити. RFC 7208 §4.6.4 встановлює жорстке обмеження в десять запитів. Після десяти приймаючий поштовий сервер припиняє оцінку і повертає PermError — а PermError — це не м’який збій, через який листи потрапляють до спаму. Це означає, що ваш SPF-запис вважається відсутнім. Аутентифікація електронної пошти за SPF-гілкою зазнає невдачі.

Ви не побачите цього в панелі управління DNS. Лічильник спрацьовує лише під час живої перевірки. У вашому видимому записі можуть бути три рядки include:, і при цьому ланцюжок іде на дванадцять запитів углиб — адже кожен постачальник має власний SPF-запис із вкладеними include.

Скільки доменів вже перевищило ліміт?

Щонайменше 797,263. Це кількість, отримана після того, як ми розв’язали кожну ціль SPF include:, що зустрічається 100 і більше разів, — 10,842 унікальних цілей, що охоплюють 95.2% всіх посилань include, — і оцінили повний ланцюжок для кожного домену. Поверхневий підрахунок (лише видимих рядків у записі) дає приблизно 7,958. Цифра з урахуванням повного ланцюжка у 100 разів більша, тому що майже весь збиток прихований всередині цілей include.

Ситуація, що найімовірніше зачіпає європейський бізнес:

Європейські хостинг-провайдери та слабкі налаштування SPF за замовчуванням

Хостинг-провайдер, з якого ви починали, має значення — адже деякі встановлюють налаштування SPF за замовчуванням, що вже витрачають кілька з ваших десяти запитів ще до підключення першого SaaS-інструменту.

Серед найбільших хостинг-провайдерів, якими користуються європейські домени у нашому переписі:

IONOS вирізняється: лише 1.0% доменів на IONOS мають обов’язковий DMARC, а це означає, що переважна більшість не має жодної значущої аутентифікації відправника. Домени OVH демонструють кращий результат за суворим SPF (43.7%), але знижуються до 2.2% за застосуванням DMARC — SPF наодинці, без DMARC для прив’язки до заголовка From:, захищає лише конверт, а не те, що бачить отримувач.

Microsoft 365 є винятком у позитивному сенсі: 85.0% доменів Microsoft використовують суворий SPF — переважно тому, що майстер налаштування пошти Microsoft встановлює -all за замовчуванням. Google Workspace за замовчуванням встановлює ~all (softfail), залишаючи 92% своїх доменів без суворого захисту.

Як діагностувати збій SPF менш ніж за 60 секунд

Найшвидший спосіб — безкоштовний інструмент, що оцінює повний ланцюжок запитів, а не лише видимий запис. Запустіть у командному рядку nslookup -type=TXT yourdomain.com і підрахуйте всі include:, які бачите. Потім знайдіть кожен із цих записів і підрахуйте їхні. Якщо пальці закінчуються раніше, ніж include, — ви в небезпечній зоні.

Надійніший підхід: перевірте свій домен тут — сканер оцінює повний розв’язаний ланцюжок, позначає PermError і показує, які механізми витрачають ваш бюджет запитів.

Три можливі результати діагностики:

• PermError — ви вже перевищили десять запитів. Кожен відправлений вами лист не проходить перевірку SPF у отримувача.
• 9–10 запитів — ви на краю обриву. Наступна SaaS-інтеграція штовхне вас за нього.
• Softfail (~all) замість hardfail (-all) — ви в межах ліміту, але запис налаштований надто м’яко для реального захисту. Дивіться звіт про помилки налаштування SPF для повної картини порівняння -all і ~all.

Як виправити SPF при використанні кількох SaaS-інструментів

Існують три підходи, у порядку зростання довготривалості:

1. Аудит і видалення зайвого. Почніть з перерахування всіх include: у поточному записі. Видаліть будь-які платформи, якими ви більше не користуєтеся, — старі ESP, CRM-інструменти з попередніх контрактів, платформи, які ви тестували, але покинули. Це безкоштовно і часто дозволяє відновити кілька запитів. Кожен видалений include: може усунути 1–3 вкладені запити.

2. Вирівнювання SPF-запису. Вирівнювання SPF розв’язує всі цілі include: до базових діапазонів IP-адрес і записує їх безпосередньо у запис як механізми ip4: та ip6:. IP-механізми не ініціюють запитів, тому вирівняний запис може перераховувати десятки джерел відправлення і при цьому залишатися на нулі запитів. Недолік: потрібно повторно вирівнювати запис щоразу, коли постачальник оновлює свої IP-адреси для відправлення, що відбувається без попередження. Більшість компаній використовують платний сервіс вирівнювання SPF (PowerDMARC, EasyDMARC, Dmarcian та інші) або будують процес моніторингу.

3. Використання SPF-макросів. Макроси RFC 7208 дозволяють будувати записи, що виконують один DNS-запит на кожну перевірку і відповідають динамічно, замість ланцюжка include. Макроси вимагають підтримки з боку DNS-хостингу та певних зусиль з реалізації, але є архітектурно чистим рішенням для організацій із багатьма SaaS-відправниками.

Після виправлення SPF доповніть його застосуванням DMARC — SPF без DMARC аутентифікує лише відправника конверта, а не адресу в заголовку From:, яку бачать отримувачі.

Часті запитання

Чому мій SPF-запис проходить перевірку в DNS-інструменті, але все одно відмовляє в заголовках електронної пошти? Більшість інструментів DNS-пошуку підраховують лише механізми, видимі у вашому власному записі, а не вкладені запити, які ці механізми ініціюють. У вас можуть бути два рядки include:, і при цьому ліміт буде перевищений, якщо запис кожного постачальника містить ще кілька. Тільки інструмент, що оцінює повний ланцюжок (або приймаючий поштовий сервер), підраховує повну глибину. Перевірте свій домен, щоб побачити реальну кількість у ланцюжку.

Чи означає збій SPF, що мої листи потраплять до спаму? PermError (забагато запитів) означає, що SPF-гілка аутентифікації повертає недійсний результат — фактично відсутність запису. DMARC оцінює як SPF, так і DKIM; якщо DKIM пройшов перевірку, DMARC може пройти, незважаючи на PermError у SPF. Якщо жоден не пройшов, DMARC зазнає невдачі, і результат залежить від вашої політики DMARC. При p=none листи все одно доставляються, але збій фіксується. При p=quarantine або p=reject листи фільтруються або повертаються. Виправте SPF, щоб не покладатися лише на DKIM.

Скільки запитів використовує типовий SaaS-стек? Запис p99 SPF у нашому переписі вже знаходиться на 9 запитах — прямо біля ліміту — ще до додавання будь-чого. Запис Google Workspace додає 3–4 запити; Mailchimp — 1–2; HubSpot — 1–3 залежно від поточної конфігурації. Трьох популярних інструментів плюс налаштувань хостинг-провайдера за замовчуванням часто досить, щоб перевищити десять.

Чи безпечне вирівнювання SPF? Так, за умови актуального підтримання. Вирівнювання перетворює ланцюжки include: на статичні діапазони IP-адрес — якщо постачальник змінює свої IP-адреси для відправлення, а ви не виконали повторне вирівнювання, ви почнете відхиляти його листи. Більшість організацій використовують керований сервіс вирівнювання, що відстежує зміни IP-адрес, а не підтримують його вручну.

Мій SPF залишався таким роками — чому він раптово зламався? Тому що ваші постачальники оновили свої SPF-записи, а не ви. Щоразу, коли SaaS-платформа додає новий діапазон IP-адрес для відправлення або вкладає ще один include, вартість вашого ланцюжка зростає без будь-яких змін з вашого боку. Ліміт у 10 запитів оцінюється в реальному часі при отриманні повідомлення, тому зміна у постачальника вранці у вівторок може зламати ваш SPF вже до полудня того самого дня.

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

Безкоштовна перевірка SPF

Якщо ви не впевнені, чи перевищує ваш SPF-запис ліміт запитів або чи він налаштований надто м’яко для захисту домену, — виконайте безкоштовну перевірку. Вона оцінює повний розв’язаний ланцюжок і показує, куди саме витрачається бюджет.

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