Перевірка SPF-запису — синтаксис і DNS-запити

Написано та перевірено редакційною командою BroBroGo.Останнє оновлення: 2026-08-04

Призначення та функції SPF-записів в автентифікації пошти

Записи SPF (Sender Policy Framework) є важливим інструментом для захисту доменних імен від підробки та несанкціонованого використання в електронній пошті. Інструмент «Перевірка SPF-запису» допомагає детально проаналізувати SPF TXT-запис, розбираючи його умови, оцінюючи кількість DNS-запитів, які він ініціює, та виявляючи потенційні помилки синтаксису або ризики політики.

Цей інструмент розроблено для адміністраторів доменів, персоналу з налаштування пошти, а також для всіх, хто бажає розібрати умови SPF-запису, оцінити кількість DNS-запитів або вчасно помітити ризики у синтаксисі й політиці. Інструмент обробляє наданий вами текст, надаючи структурований «Аналіз SPF», «Підсумок SPF» та детальний список виявлених проблем.

Вхідні дані та особливості обробки тексту

Для початку аналізу користувач має надати вхідні дані:

Значення SPF TXT: текстовий рядок, що представляє SPF-запис. Запис обов'язково має починатися з v=spf1.
Максимальна довжина: інструмент приймає текст обсягом до 20 000 символів.

Якщо ваш DNS-запис містить частини DNS TXT у лапках, інструмент автоматично об'єднує їх перед початком аналізу. У разі виявлення таких частин у звіті з'являється примітка: «Частини DNS TXT у лапках було об’єднано перед аналізом.».

Якщо спробувати запустити перевірку без введення даних, інструмент покаже помилку «Спочатку вставте SPF-запис.». Якщо введений текст не відповідає формату SPF, відображається помилка «Введіть підтримуваний SPF-запис.». У разі перевищення ліміту символів ви побачите повідомлення «Цей запис незвично великий. Обмежте його 20 000 символами.».

Результати аналізу та розібрані умови

Після обробки запису інструмент виводить детальний аналіз, який містить кілька ключових показників:

Прямі умови DNS: число, що відображає оціночну кількість DNS-запитів для першого запису.
Механізми: загальна кількість знайдених механізмів.
Ризики: кількість виявлених інформаційних та безпекових ризиків (крім суто інформаційних повідомлень).

Таблиця Розібрані умови містить такі стовпці для кожної виявленої частини запису:

Умова: конкретна розібрана умова SPF.
Тип: категорія елемента, наприклад, Версія (Version), Механізм (Mechanism), Модифікатор (Modifier) або Невідомо (Unknown).
Значення або кваліфікатор: конкретне значення умови або її кваліфікатор (наприклад, +, -, ~, ?).
Використовує DNS: логічне значення (Так або Ні), яке вказує, чи викликає ця умова DNS-запит.

Обмеження на кількість DNS-запитів та його наслідки

Одним із найважливіших правил SPF є обмеження на кількість DNS-запитів. Під час повної перевірки SPF-запису поштовими серверами одержувачів дозволяється виконувати не більше 10 DNS-запитів.

Оцінка кількості DNS-запитів у цьому інструменті враховує такі умови у вставленому записі:

include
a
mx
ptr
exists
redirect

Якщо вставлений запис безпосередньо містить понад 10 умов, що викликають DNS-запити, інструмент зафіксує порушення: «Цей запис уже містить ‹detail› умов, що спричиняють DNS-запити, понад обмеження SPF у 10.».

Слід пам'ятати, що цілі include або redirect можуть містити власні вкладені умови, які додають ще більше DNS-запитів під час реальної перевірки. Тому інструмент виводить попередження: «Цілі include або redirect можуть додати більше DNS-запитів, ніж враховує оцінка першого запису.». Якщо загальна кількість запитів у всьому ланцюжку під час повної оцінки перевищує 10, поштові сервери одержувачів (SPF-receiver) мають трактувати це як постійну помилку (permanent error), що може критично вплинути на доставку листів.

Помилки синтаксису та правила побудови запису

Інструмент виконує локальну перевірку синтаксису та виявляє низку критичних помилок:

Початок запису: SPF-запис обов'язково має починатися з версії v=spf1. Якщо ця умова відсутня, фіксується помилка «Запис має починатися з v=spf1.». Якщо вона розташована не на початку, виводиться повідомлення: «Умова ‹term›: v=spf1 має бути першою умовою.». Наявність кількох версій викликає помилку «Запис містить понад одну умову v=spf1.».
Невідомі механізми: якщо вказано неіснуючий механізм, інструмент позначить його: «Умова ‹term›: «‹detail›» не є розпізнаним механізмом SPF.».
Проблеми зі значеннями: відсутні або некоректні значення механізмів позначаються як «Умова ‹term›: значення ‹detail› відсутнє або має неправильний формат.».
Неправильні IP-адреси: для помилок у записах IP передбачені повідомлення «Умова ‹term›: введіть дійсну адресу IPv4 або діапазон CIDR.» та «Умова ‹term›: введіть дійсну адресу IPv6 або діапазон CIDR.».
Модифікатори: дублювання модифікаторів викликає помилку «Умова ‹term›: модифікатор ‹detail› трапляється понад один раз.». Крім того, модифікатори не можуть мати кваліфікаторів +, -, ~ або ? — у такому разі з'явиться попередження «Умова ‹term›: модифікатор не може мати кваліфікатор +, -, ~ або?.».

Аналіз ризиків політики та безпеки

Окрім синтаксичних помилок, інструмент оцінює загальну безпеку та логіку вашої SPF-політики:

Повторення механізму all: використання кількох механізмів all ускладнює аналіз політики, про що сповіщає попередження «Умова ‹term›: кілька механізмів all ускладнюють перевірку політики.».
Недосяжні умови: будь-які умови, розташовані після механізму all, є недосяжними під час оцінки SPF-сервером. Інструмент позначає це як «Умови після all недосяжні під час перевірки SPF.».
Конфлікт redirect та all: якщо в записі присутні обидва ці елементи, модифікатор redirect буде проігноровано. Інструмент виведе примітку: «redirect ігнорується, оскільки запис також містить all.».
Застарілий механізм ptr: публікація механізму ptr наполегливо не рекомендується, оскільки він є повільним та ненадійним. Ви побачите попередження: «Механізм ptr не слід публікувати, оскільки він повільний і ненадійний.».
Занадто м'які політики: використання +all фактично дозволяє надсилання листів з будь-якої IP-адреси у світі, що нівелює захисну функцію SPF. Інструмент попередить: «+all дозволяє будь-якого відправника й зазвичай нівелює призначення SPF.». Використання ?all повертає нейтральний результат і майже не дає одержувачам вказівок щодо того, як чинити з підозрілими листами.
Відсутність кінцевої політики: якщо запис не містить ні all, ні redirect, відправники, які не потрапили під жодну з умов, отримуватимуть нейтральний результат. Це фіксується приміткою «Запис не містить ні all, ні redirect, тому відправники без збігу отримують нейтральний результат.».

Якщо у вашому записі немає жодної з перелічених проблем, у розділі приміток відобразиться статус: «У вставленому записі не знайдено ризиків синтаксису чи політики.».

Конфіденційність та обмеження локальної перевірки

Цей інструмент працює за принципом повної локальної конфіденційності. Ваш SPF-запис повністю залишається у вашому браузері; сервіс BroBroGo не завантажує і не зберігає його на своїх серверах.

Оскільки це локальний аналізатор синтаксису та оцінки першого запису, він має певні обмеження:

Він не робить запитів до DNS.
Він не розгортає цілі include та redirect.
Він не тестує IP-адреси відправників.
Він не може підтвердити, яку саме відповідь поверне реальний поштовий сервер одержувача.

Результати перевірки слід використовувати для аналізу структури та виявлення помилок, а не як остаточний доказ успішної доставки пошти.

Поширені запитання (FAQ)

Як розраховується оцінка кількості DNS-запитів SPF?

Оцінка враховує умови include, a, mx, ptr, exists і redirect у вставленому записі. Включені та переспрямовані записи можуть додавати запити, тому локальна перевірка не визначає остаточну рекурсивну кількість.

Що станеться, якщо SPF потребує понад 10 DNS-запитів?

Одержувачі SPF мають вважати перевірку, що перевищила обмеження в 10 умов із DNS-запитами, постійною помилкою. Обмеження охоплює весь ланцюжок include і redirect, а не лише перший запис.

Чи доводить результат без помилок, що моє налаштування SPF працює?

Ні. Ця сторінка перевіряє лише вставлений текст. Вона не запитує DNS, не розгортає записи провайдера, не тестує IP відправника й не підтверджує відповідь поштового сервера одержувача.