SPF: занадто багато DNS-запитів — скоротіть безпечно та пройдіть перевірки

October 26, 2025 • February 3, 2026 • Читання: 5 хв • Views: 10

Було корисно?

Ваша вихідна пошта здається «налаштованою», ваш DNS «виглядає нормально», і все ж доставлення різко падає, бо SPF повертає permerror: занадто багато DNS-запитів. Маркетинг клянеться, що нічого не міняли. Служба підтримки клянеться, що все змінилося. Вам доведеться бути дорослим у кімнаті.

Ця помилка спочатку відчувається як дрібна проблема форматування, поки не пригадаєш, що це автентифікація. Отримувачі не ведуть переговори щодо автентифікації. Вони судять, мовчки, у масштабі.

Що насправді означає «занадто багато DNS-запитів»

SPF (Sender Policy Framework) оцінює приймаючий поштовий сервер. Коли він бачить повідомлення, що нібито від user@yourdomain, він дивиться SPF-запис вашого домену (TXT-запис, що починається з v=spf1) і визначає, чи дозволена IP-адреса відправника.

Під час оцінки деякі механізми SPF змушують отримувача робити DNS-запити. Специфікація обмежує, скільки DNS-запитів на основі механізмів може бути розширено. Якщо під час оцінки потрібно більше ніж 10 DNS-запитів, отримувач має припинити і повернути permerror (постійна помилка). «Постійна» тут означає: не намагайтеся знову; політика зламана.

Отже, «занадто багато DNS-запитів» — це не попередження. Це відмова отримувача робити вашу домашку.

Важлива оперативна деталь: підрахунок запитів — це не «скільки TXT-записів ви особисто бачите». Це скільки DNS-запитів може знадобитися отримувачу після переходу по include, redirect і розв’язування A/MX-цілей. Include можуть розростися рекурсивно. Один нешкідливий виглядом маркетинговий сервіс може потягнути за собою пів-універсу SaaS.

Жарт №1: SPF — єдине місце, де «ще один include» здається безпечним, поки це не стане вашою повною особистістю і Gmail перестає відповідати на дзвінки.

Факти та контекст, які можна використати на нарадах

SPF з’явився раніше за DMARC. SPF починався як спосіб зменшити підробку відправників задовго до того, як DMARC зробив «вирівнювання» словами на рівні ради директорів.
Ліміт у 10 запитів — це навмисне тертя. Отримувачі не можуть дозволити відправникам змусити безмежну DNS-рекурсію; це міра контролю ресурсів та захисту від зловживань.
Оцінка SPF відбувається на стороні отримувача. Ваш вихідний MTA може логувати «успішний SPF», але це не є авторитетним. Лише оцінка отримувача має значення.
Деякі механізми не коштують запитів. Семантика ip4, ip6, all та exists важлива; лише певні механізми запускають DNS-запити.
Include зазвичай є винуватцями. Постачальники постачають фрагменти SPF з include:, бо їм так зручно, а не тому, що це економно для вас.
Отримувачі розрізняються в кешуванні та поведінці резолверів. Специфікація чітка щодо ліміту, але шлях до його досягнення може відрізнятися в залежності від кешування DNS і налаштувань рекурсії.
Помилки SPF можуть бути тихими вбивцями доставляння. Деякі отримувачі трактують permerror як відмову, інші — як нейтральну подію з додатковою вагою у спам-скорінгу. У будь-якому разі ви програєте.
Один домен може мати кілька TXT-записів, але SPF не повинен. Багато SPF-записів на одному імені можуть викликати «permerror: multiple SPF records», окрему, але не менш дратівливу помилку.

Плейбук для швидкої діагностики

Це порядок дій, який найшвидше знаходить вузьке місце, не втягуючи вас у тижневі археологічні розкопки DNS.

Спочатку: підтвердьте режим відмови з боку отримувача

Подивіться реальний зразок заголовків від отримувача, який відкинув або поклав лист у спам.
Витягніть результат SPF: pass, fail, neutral, softfail, temperror, permerror.
Якщо це permerror з повідомленням «занадто багато DNS-запитів» (або «exceeded maximum DNS lookups»), у вас проблема розширення SPF, а не проблема пропагації DNS.

Друге: порахуйте кількість запитів для вашого SPF-запису

Отримайте поточний SPF TXT і перелічіть механізми.
Рекурсивно переходьте по include і redirect.
Порахуйте механізми, що запускають DNS: include, a, mx, ptr (не використовуйте), exists, redirect.

Третє: визначте, які include постачальників непотрібні або дублюються

Перелічіть кожну систему, що справді надсилає пошту від імені вашого домену: ваш MTA, Microsoft 365/Google Workspace, тикетинг, CRM, маркетинг-автоматизація, виставлення рахунків, HR-платформа тощо.
Суворо зіставте ці системи з механізмами SPF. Видаліть ті, що не надсилають від вашого домену або можуть бути переміщені на піддомен.

Четверте: виправляйте, починаючи з найменш ризикового скорочення

Замініть a/mx на явні ip4/ip6, якщо IP-адреси стабільні.
Згорніть надлишкові include (іноді постачальники включають інших постачальників, яких ви вже включили).
Використовуйте піддомени для джерел з високою мінливістю і відповідно налаштуйте DMARC.

Механізми SPF, що спалюють бюджет запитів

Не все в SPF коштує запитів. Бюджет споживається DNS-запитами під час оцінки.

Механізми, які зазвичай запускають DNS-запити

include: коштує щонайменше один запит для SPF включеного домену; може каскадувати.
redirect= подібний до include за витратами запитів; перенаправляє оцінку на інший запис.
a і mx: вимагають запитів для розв’язування A/AAAA або MX-цілей, а потім їх A/AAAA.
exists: вимагає DNS-запит для згенерованого імені.
ptr: потребує множинних запитів і загалом не рекомендується; багато оцінювачів ставляться до нього суворо. Не використовуйте.

Механізми, що не споживають ліміт DNS-запитів

ip4, ip6: прямі IP-діапазони в записі. DNS не потрібен.
all: термінатор механізмів (-all, ~all тощо). DNS не потрібен.

Чому «лише 10» боляче в сучасному SaaS-світі

Десять — це щедро, коли «ваша поштова система» означала один-два MTA і можливо резервний провайдер. У 2026 ваш поштовий слід — зоопарк: продукт надсилає onboarding, фінанси — квитанції, HR — оновлення політик, маркетинг — кампанії, і півдесятка інструментів надсилають повідомлення «хтось вас згадав». SPF стає спільним простором імен без моделі власності. Ось як ви потрапляєте на 11 запитів, і ніхто цього не помічає.

Аудит SPF як для SRE

Не розглядайте SPF як рядок. Розглядайте його як граф залежностей з доменами відмов.

Інвентаризуйте відправників, а не постачальників

Почніть з «хто фактично надсилає пошту з @yourdomain в RFC5321 MAIL FROM (envelope from)?» Саме це перевіряє SPF. Постачальник може відображати ваш домен у заголовку From, використовуючи власний envelope domain. У такому разі SPF для вашого кореневого домену не має значення, а ви даремно витрачаєте бюджет запитів.

Ізолюйте джерела з високою мінливістю

Маркетингові платформи часто змінюють IP та вміст include. Транзакційні MTA (власні або стабільні провайдери) відносно сталі. Поміщаючи все в один SPF-запис, ви поєднуєте різні темпи змін. Використовуйте піддомени, щоб ізолювати мінливість: m.yourdomain для маркетингу, notify.yourdomain для продукту, billing.yourdomain для фінансів тощо. Потім налаштуйте DMARC (або окремі DMARC-політики за піддоменами) в залежності від рівня ризику.

Надавайте перевагу явним IP, коли ви ними керуєте

Якщо ви оперуєте вихідними MTA зі стабільними egress IP, використовуйте ip4/ip6. Include призначені для делегування третій стороні. Делегування зручно, але воно дає іншій стороні право витрачати ваш бюджет запитів.

Будьте обережні з «флаттенінгом»

Флаттенінг означає розв’язувати include і конвертувати отримані IP-діапазони в явні ip4/ip6 у вашому записі. Це знижує кількість запитів, але створює зобов’язання з підтримки: якщо постачальник змінить IP-діапазони, ви повинні оновити SPF. Це безпечно тільки якщо ви можете автоматизувати процес або приймати періодичний ризик відхилення.

Жарт №2: Ручний флаттенінг SPF схожий на ручне редагування таблиці маршрутизації: він розвиває характер, здебільшого у формі жалю.

Практичні завдання з командами, виводами та рішеннями

Це польові завдання, які можна виконати з Linux-машини зі стандартними інструментами. Кожне завдання включає, на що звертати увагу, і яке рішення прийняти. Припустимо, ви тестуєте example.com; підставте свій домен.

Завдання 1: Отримати TXT-записи домену і знайти кандидати SPF

cr0x@server:~$ dig +noall +answer TXT example.com
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
example.com.     300 IN TXT "google-site-verification=abc123"

Що це означає: SPF — це TXT-рядок, що починається з v=spf1. Якщо ви бачите більше ніж один TXT з v=spf1 на тому самому імені — це інша permerror (multiple SPF records).

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

Завдання 2: Перевірити наявність кількох SPF-записів (поширено після «очищення DNS»)

cr0x@server:~$ dig +short TXT example.com | grep -c "v=spf1"
1

Що це означає: Кількість SPF-записів, що повертається. Будь-яке значення більше за 1 — проблема.

Рішення: Якщо >1 — об’єднайте в один запис і приберіть інші. Отримувачі можуть трактувати множинні як permerror навіть якщо комбінований набір був би валідний.

Завдання 3: Витягнути точний SPF-рядок для парсингу

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1'
v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all

Що це означає: Ви отримали сирий вміст запису без лапок.

Рішення: Збережіть цей рядок у нотатках інциденту. Ставтеся до змін SPF як до змін коду: бажано мати diff до/після.

Завдання 4: Швидко перерахувати include

cr0x@server:~$ dig +short TXT _spf.google.com | sed 's/"//g'
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

Що це означає: Один include може розгорнутися в кілька include. Ось як ви вичерпуєте бюджет.

Рішення: Побудуйте граф include. Якщо ваш кореневий запис вже включає два постачальники, і кожен розгортається в 3–6 include, ви, ймовірно, близькі до ліміту.

Завдання 5: Перевірити, чи використовуєте ви дорогі механізми (mx/a/ptr)

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | egrep '^(a|mx|ptr|exists)'
mx

Що це означає: Цей SPF використовує mx, що коштує DNS-запитів (MX + розв’язування A/AAAA) під час оцінки.

Рішення: Якщо вам не потрібні mx/a, видаліть їх. Якщо потрібні — розгляньте заміну на явні IP-адреси.

Завдання 6: Перевірити MX-цілі та їх A/AAAA (витрати бюджету)

cr0x@server:~$ dig +noall +answer MX example.com
example.com. 300 IN MX 10 mail1.example.com.
example.com. 300 IN MX 20 mail2.example.com.

cr0x@server:~$ dig +noall +answer A mail1.example.com
mail1.example.com. 300 IN A 203.0.113.10

Що це означає: Якщо SPF використовує mx, оцінювач може потребувати розв’язати ці імена. Це споживає запити.

Рішення: Якщо MX-хости потрібні лише для прийому пошти і не використовуються для вихідної, не використовуйте mx в SPF. SPF — для авторизації вихідної, не для маршрутизації вхідної.

Завдання 7: Підтвердити, якою IP реально користується ваша вихідна пошта

cr0x@server:~$ grep -R "client-ip" -n /var/log/mail.log | tail -n 3
/var/log/mail.log:98765: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98766: ... client-ip=198.51.100.24 ...
/var/log/mail.log:98767: ... client-ip=198.51.100.24 ...

Що це означає: Ваші логи можуть показати egress IP, що використовується для доставлення SMTP (залежить від MTA і формату логів).

Рішення: Якщо ви контролюєте IP і він стабільний, авторизуйте його явно через ip4:198.51.100.24 і зменшіть залежність від DNS-механізмів.

Завдання 8: Порахувати запити за допомогою утиліти для перевірки SPF (локальний інструмент)

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@example.com

Що це означає: spfquery оцінює SPF подібно до отримувачів. Не всі збірки виводять підрахунок запитів, але інструмент корисний для функціональних перевірок.

Рішення: Використовуйте це, щоб перевірити, що ваш кандидат-запис SPF все ще проходить для відомих хороших відправників після змін. Якщо результат зміниться на fail/neutral — ви порушили авторизацію.

Завдання 9: Простежити шляхи розв’язування DNS та TTL (кешування важливе)

cr0x@server:~$ dig +trace TXT example.com | tail -n 8
example.com.     300 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
;; Query time: 42 msec
;; SERVER: 192.0.2.53#53(192.0.2.53) (UDP)
;; WHEN: Sat Jan 03 12:00:00 UTC 2026
;; MSG SIZE  rcvd: 164

Що це означає: Ви можете бачити TTL і чи делегування адекватне. TTL впливає на те, як часто отримувачі повинні повторно завантажувати записи, але він не змінює жорсткого ліміту в 10 запитів.

Рішення: Якщо TTL надто низький (наприклад 30s) для SPF-пов’язаних записів, розгляньте підвищення, щоб зменшити змінність і випадкові DNS-збої. Це не виправить «занадто багато запитів», але зменшить temperror.

Завдання 10: Виявити ризик «занадто довгого SPF» при флаттенінгу

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | wc -c
142

Що це означає: Кількість символів у поточному SPF-рядку (приблизно). TXT-рядки мають обмеження по розміру; провайдери та отримувачі можуть мати власні реалізації з лімітами. Також DNS-відповіді можуть впиратися в UDP-розмір, якщо ви переборщите.

Рішення: Якщо флаттенінг перетворить ваш SPF у 1800-символьний зоопарк IP, перегляньте рішення. Коротший запис — не лише естетичніше; він надійніше доставляється через DNS.

Завдання 11: Перевірити випадкову рекурсію через цикли redirect/include

cr0x@server:~$ dig +short TXT spf-a.example.com | sed 's/"//g'
v=spf1 include:spf-b.example.com -all

cr0x@server:~$ dig +short TXT spf-b.example.com | sed 's/"//g'
v=spf1 include:spf-a.example.com -all

Що це означає: Це цикл. Оцінювачі вдарять у ліміти або помилку.

Рішення: Розірвіть цикл негайно. Графи SPF мають бути ациклічними. Якщо вам потрібен спільний вміст, використовуйте один спільний запис, який інші включають, а не кругові посилання.

Завдання 12: Перевірити, що кожне стороннє include живе і розв’язується

cr0x@server:~$ dig +noall +answer TXT spf.vendor-example.net
spf.vendor-example.net. 300 IN TXT "v=spf1 ip4:203.0.113.0/24 -all"

Що це означає: Постачальники іноді застарівають імена SPF. Якщо include-ціль повертає NXDOMAIN або таймаут, отримувачі можуть повернути temperror або permerror в залежності від поведінки.

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

Завдання 13: Виявити антипатерн «include всього»

cr0x@server:~$ dig +short TXT example.com | sed 's/"//g' | grep '^v=spf1' | tr ' ' '\n' | grep '^include:' | sort
include:_spf.google.com
include:mailgun.org
include:spf.protection.outlook.com
include:sendgrid.net
include:spf.salesforce.com
include:spf.zendesk.com

Що це означає: Цей домен намагається авторизувати пів-інтернету. Деякі з цих сервісів можливо і не надсилають із вашим envelope-from.

Рішення: Попросіть докази для кожного include: «Покажіть лист, де envelope-from — наш домен і він надійшов від цього провайдера». Видаліть непотрібні include.

Завдання 14: Швидка перевірка кандидатного зменшеного SPF перед публікацією (ім’я для стенду)

cr0x@server:~$ dig +short TXT spf-test.example.com | sed 's/"//g'
v=spf1 ip4:198.51.100.24 include:spf.protection.outlook.com -all

cr0x@server:~$ spfquery -ip 198.51.100.24 -sender test@spf-test.example.com -helo mail.example.com
pass (SPF result: pass) smtp.mailfrom=test@spf-test.example.com

Що це означає: Ви можете тестувати кандидат-список SPF на піддомені перед зміною продакшену. SPF застосовується за ім’ям домену, тож можна репетиціювати.

Рішення: Завжди робіть стенд-версії при можливості. Опублікуйте на spf-test, перевірте, потім перемістіть у реальний домен в контрольований віконний час.

Стратегії скорочення, що не підпалять вашу пошту

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

1) Видаліть те, чим не користуєтеся (найлегший виграш)

Більшість роздутих SPF-записів несуть мертві include: постачальники, від яких ви відійшли, пілоти, про які забули, регіональні підрозділи, що роблять по-своєму. SPF не підказує «не використовуваний include». Потрібна дисципліна.

Як робити безпечно:

Зберіть тиждень зразків вихідних листів з кожної системи. Подивіться на Return-Path і SPF-автентифіковану ідентичність у отримувачів.
Залишайте include лише для систем, що дійсно використовують ваш домен у envelope-from.
Якщо постачальник надсилає зі своїм bounce-доменом, припиніть авторизовувати його на вашому корені. Це нічого не дає.

2) Перенесіть джерела з високою мінливістю на піддомени

Це доросле рішення. Воно дає окремі SPF-записи та окремі домени відмов.

Приклад:

example.com: корпоративна пошта (M365), внутрішні MTA.
m.example.com: SPF маркетингової платформи (і DKIM/DMARC вирівняні на цей піддомен).
notify.example.com: провайдер сповіщень продукту.

На що дивитися: вирівнювання DMARC. Якщо ви використовуєте DMARC зі строгим вирівнюванням, переконайтеся, що видимий From збігається з envelope-from або з d= в DKIM. Інакше ви «поправите SPF», але все одно провалите DMARC.

3) Замініть `mx` та `a` на явні IP, коли вони стабільні

mx і a популярні через зручність і автоматичне оновлення, коли IP змінюються. Вони також коштують запитів і можуть випадково авторизувати хости, яких ви не мали на увазі.

Золоте правило: Якщо набір IP змінюється рідко і ви можете ним керувати — використовуйте ip4/ip6. Якщо IP часто змінюються і ви не можете автоматизувати — не флаттеньте; ізолюйте через піддомени.

4) Згорніть надлишкові include

Часто включають і «батьківський», і «дочірній» SPF-домен одного постачальника, бо різні гайди кажуть по-різному. Іноді один вже включає інший. Іноді два постачальники включають ту саму інфраструктуру. Ви платите бюджет двічі.

Метод: Розгорніть include і шукайте перекриття. Якщо include:spf1.vendor розгортається в include:spf2.vendor, можливо, потрібен лише один з них — залежить від того, який продукт ви використовуйте.

5) Використовуйте `redirect=`, коли справді хочете одну канонічну політику

redirect= не обманює ліміт; воно теж коштує. Воно дає централізацію політики: один запис стає авторитетним, а інші механізми ігноруються після застосування redirect.

Хороший кейс: у вас багато vanity-доменів, що мають ділити один SPF з основним доменом. Ви публікуєте мінімальні записи на vanity-доменах з v=spf1 redirect=example.com і керуєте політикою в одному місці.

6) Флаттенінг — лише з автоматизацією та запобіжниками

Флаттенінг може бути правильним, коли:

у вас один-два сторонні провайдери,
вони публікують стабільні IP-діапазони,
ви можете автоматично оновлювати та публікувати,
ви тестуєте перед релізом.

Флаттенінг ризикований, коли ви робите це один раз вручну під час інциденту, а потім забуваєте на дев’ять місяців. Це не інженерія. Це фольклор.

7) Не «вирішуйте» проблему, пом’якшивши `-all` до `~all`

Зміна кваліфікатора наприкінці не впливає на кількість запитів. Вона змінює примусову дію. Іноді це доречно під час міграції, але це не виправлення permerror. Якщо ви отримуєте permerror, отримувач може навіть не дійти до механізму all.

Один операційний вислів, щоб залишатися чесним

Парафразована ідея, атрибуція: В. Едвардс Демінг говорив, що не можна керувати тим, що не вимірюєш. Очищення SPF — це робота, яка починається з вимірів.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через хибне припущення

Середня компанія успішно використовувала Microsoft 365 для корпоративної пошти і маркетингову платформу для кампаній. Хтось додав нову систему тикетингу, яка «надсилає листи від вашого домену», і в onboarding-документах вендора було вказано додати ще один include в кореневий домен SPF.

Припущення: «SPF include дешеві, і отримувачі все одно кешують DNS». Так SPF не працює. Ліміт запитів — це жорсткий поріг під час оцінки; кешування може допомогти з латентністю, але воно не дає вам більше ніж десять запитів.

В понеділок вранці листи для скидання паролю почали потрапляти в спам у великого провайдера пошти для споживачів. Ніхто не бачив бонсів. Їх було небагато. Провайдер приймав пошту, але карав у скорингу за помилки автентифікації. Команда безпеки бачила погіршення DMARC-агрегатів, але це відставало і не викликало алертів.

До полудня черга підтримки виглядала як DoS-атака, вчинена спантеличеними людьми. Інженери перевірили застосунок, потім MTA, потім налаштування TLS. Зрештою хтось вставив повні заголовки в чат, і там було: spf=permerror (too many DNS lookups).

Виправлення було нудним: видалити include тикетинг-системи, бо вона фактично не використовувала домен компанії у envelope-from. Вони ввімкнули DKIM для bounce-домену вендора і оновили стратегію вирівнювання DMARC. Доставлення відновилося. Урок запам’ятався: ніколи не додавайте include у SPF без доказів використання envelope-from.

Міні-історія 2: Оптимізація, що влетіла в голову

Глобальна організація вирішила «почистити DNS» і зменшити залежність від третіх сторін. Хтось запропонував флаттенити всі include в явні IP-діапазони на кореневому домені. Це виглядало елегантно: нуль include, мінімум запитів, проблема вирішена назавжди.

Вони агресивно флаттенили. Запис розрісся десятками IP-діапазонів, майже до практичних обмежень розміру DNS-відповіді. Він ще публікувався, в основному. Деякі резолвери почали обрізати відповіді. Деякі отримувачі повторно підключалися по TCP і успішно отримували. Інші тайм-аутували. Режим відмов був переривчастий і дратівливий.

Гірше, один постачальник змінив свої вихідні IP-діапазони. Include у вендора оновився б автоматично. Флаттенінг — ні. Протягом вихідних частина маркетингового потоку почала провалюватися по SPF, і DMARC почав падати для цих повідомлень. «Покращення надійності» перетворилося на пастку технічного обслуговування.

План відновлення був таким: відмовитися від флаттенінгу для високомінливих провайдерів, перевести їх на піддомени і залишити явні IP лише для власних MTA організації. Результат мав трохи більше запитів, ніж ідеал флаттенінгу, але залишався під 10 і не вимагав героїчних дій кожного кварталу.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Компанія з дивовижно зрілою поштовою політикою трактувала SPF як конфігурацію-коду. Кожна зміна DNS проходила рев’ю, і вони мали просту перевірку перед злиттям: обчислити глибину розгортання SPF та оцінити використання запитів для будь-якого зміненого запису.

Коли бізнес придбав інший бренд, маркетинг попросив «просто додати їхній include до нашого кореневого SPF, щоб вони могли надсилати від головного домену». Інженер на рев’ю попросив зразок повідомлення і інформацію про те, який bounce-домен використовує платформа. Виявилося, що платформа за замовчуванням використовувала bounces.brand-vendor.tld для SMTP MAIL FROM.

Вони відмовили у додаванні до кореневого домену. Замість цього налаштували m.example.com з власним SPF, DKIM і політикою DMARC. Основний домен залишився маленьким: Microsoft 365 плюс корпоративні ретранслятори. Запити залишалися в межах бюджету. Злиття не стало інцидентом доставлення.

Без феєрверків. Без дзвінків у неробочий час. Саме на цьому й полягає суть.

Типові помилки: симптом → корінна причина → виправлення

1) Симптом: «spf=permerror (too many DNS lookups)» у заголовках

Корінна причина: Оцінка SPF перевищила ліміт у 10 DNS-запитів через ланцюги include і/або механізми mx/a.

Виправлення: Видаліть непотрібні include; замініть mx/a на явні IP, де доречно; перемістіть відправників на піддомени; уникайте флаттенінгу, якщо немає автоматизації.

2) Симптом: SPF іноді проходить, іноді temperrors

Корінна причина: Таймаути DNS або періодичні NXDOMAIN для включених доменів; низькі TTL; крихкий DNS постачальника; проблеми резолвера.

Виправлення: Підвищіть TTL для пов’язаних SPF-записів; приберіть або замініть ненадійні include; забезпечте здоров’я авторитетного DNS; розгляньте резервування авторитетних NS.

3) Симптом: «permerror: multiple SPF records»

Корінна причина: Більше одного TXT-запису на тому ж імені, що починається з v=spf1.

Виправлення: Злийте механізми в один SPF-запис. Інші TXT-записи залиште без змін.

4) Симптом: Ви вирізали include і раптом критичний бізнес-потік перестав проходити SPF

Корінна причина: Ви видалили include, який справді авторизував відправника, що використовує ваш домен у envelope-from, або неправильно ідентифікували домен, що перевіряється (корінь проти піддомену).

Виправлення: Визначте потік, що падає, за заголовками; повторно авторизуйте правильного провайдера; розгляньте переміщення цього відправника на окремий піддомен, щоб уникнути майбутнього зв’язування.

5) Симптом: SPF-запис «виглядає коротким», але все одно досягає ліміту запитів

Корінна причина: Вкладені include: запис короткий, бо ви делегували складність кудись ще.

Виправлення: Розгорніть include і порахуйте запити у повному дереві залежностей. Зменшуйте у джерелі, усуваючи include або ізолюючи відправників.

6) Симптом: Отримувач каже SPF permerror, але внутрішні перевірки показують pass

Корінна причина: Різне середовище оцінки: кешування, поведінка резолвера або ваш інструмент не застосовує ті самі ліміти; також можете перевіряти не ту ідентичність (MAIL FROM vs HELO).

Виправлення: Валідируйте за реальними заголовками отримувача; підтвердіть, який домен оцінюється; використайте кілька інструментів і перевірте розгортання запитів.

7) Симптом: Після флаттенінгу виникають спорадичні збої у різних отримувачів

Корінна причина: Перевеликий TXT у відповіді SPF викликає усічення або проблеми з фрагментацією DNS; або застарілі флаттенні IP-діапазони.

Виправлення: Перестаньте флаттенити все підряд. Використовуйте піддомени для динамічних провайдерів. Тримайте кореневий SPF компактним і стабільним.

Контрольні списки / поетапний план

План змін: зменшити SPF без порушення пошти

Зберіть докази: Для кожної вихідної системи захопіть зразки заголовків принаймні від двох отримувачів (одного споживчого, одного корпоративного). Визначте envelope-from домен і IP відправника.
Інвентаризуйте поточні залежності SPF: Розгорніть include і redirect цілі; перелічіть усі домени, що залучені.
Порахуйте споживачів запитів: Визначте механізми, що викликають DNS-запити (include, a, mx, exists, redirect). Оцініть найгірший випадок.
Приберіть зайве: Видаліть include для постачальників, які не використовують ваш домен як MAIL FROM.
Ізолюйте змінність: Створіть піддомени для маркетингу/сповіщень та перемістіть туди відправні ідентичності. Опублікуйте окремий SPF для піддомену.
Віддавайте перевагу явним IP для власних MTA: Замініть a/mx на ip4/ip6 для стабільних вихідних IP.
Стендуйте запис: Опублікуйте кандидат SPF на spf-test.example.com і виконайте перевірки для всіх очікуваних IP-відправників.
Розгорніть по таймеру: Здійснюйте зміну в продакшен DNS у вікні; врахуйте TTL (якщо TTL = 300s, очікуйте кілька хвилин на конвергенцію, але плануйте довше).
Моніторте сигнали отримувачів: Слідкуйте за метриками доставлення, bounce-повідомленнями і агрегованими даними DMARC. Підтвердіть SPF-результати в вибіркових заголовках.
Документуйте власність: Зміни SPF має погоджувати одна команда або процес. «Будь-хто може додати include» — шлях повного відновлення проблеми.

Операційний чекліст: перед затвердженням нового include SPF

Чи є у нас зразок заголовків, що доводить, що провайдер використовує наш домен у envelope-from?
Скільки запитів додасть цей include при розгортанні (включно з вкладеними include)?
Чи можемо ми використати піддомен замість кореневого домену?
Чи можемо ми авторизувати IP (якщо стабільні) замість делегування через include?
Чи налаштовано DKIM для видимого From-домену, щоб DMARC пройшов, навіть якщо SPF матиме проблеми?
Який план відкату (збережене попереднє значення TXT, відомий TTL)?

FAQ

1) Що саме рахується до ліміту у 10 DNS-запитів?

Механізми, що вимагають DNS-запитів під час оцінки: include, redirect, a, mx, ptr і exists. Ліміт стосується кількості таких DNS-інтерактивних механізмів, включно з тими, що підтягуються через include.

2) Якщо я збільшу TTL, чи виправить це «занадто багато DNS-запитів»?

Ні. TTL може зменшити таймаути DNS і підвищити стабільність, але він не змінює жорсткий ліміт у 10 запитів, визначений специфікацією. TTL може допомогти з temperror, але не з permerror через ліміт запитів.

3) Чи краще `redirect=`, ніж `include:` щодо ліміту запитів?

Не обов’язково. Обидва можуть коштувати запитів. redirect корисний для централізації політики, особливо коли багато доменів ділять один SPF. Це не лазівка для бюджету запитів.

4) Чому просто не поміняти `-all` на `~all`?

Бо відмови через ліміт запитів часто не дозволяють оцінювачу дійти до механізму all. Навіть якщо він туди доходить, зміна примусу не зменшує кількість запитів. Це лише послаблює захист від спуфінгу.

5) Чи можна публікувати SPF у кількох TXT-записах і очікувати, що отримувачі їх об’єднають?

Ні. Багато SPF-записів на одному імені зазвичай призводять до permerror. Ви можете мати кілька TXT-записів для інших цілей, але лише один має бути вашою SPF-політикою.

6) Чи варто флаттенити SPF?

Іноді. Флаттенінг доречний, коли ви можете автоматизувати оновлення і публікацію, і коли кінцевий запис залишається в межах практичних розмірів DNS. Якщо ви не можете автоматизувати — надайте перевагу піддоменам і менше include.

7) Як піддомени допомагають з лімітом запитів?

Ліміт застосовується на одну оцінку SPF. Якщо маркетинг надсилає з bounce@m.example.com, отримувач оцінює SPF для m.example.com, а не для example.com. Це дає окремі бюджети по 10 запитів і ізолює зміни.

8) Що робити, якщо нам треба багато провайдерів і не вдається впасти нижче 10?

Тоді потрібна архітектура, а не героїчні вчинки: консолідуйте провайдерів, перемістіть потоки на піддомени і зробіть DKIM сильним, щоб DMARC міг проходити навіть коли SPF обмежений. Також перегляньте, чи можуть деякі системи припинити використовувати ваш домен як envelope-from.

9) Чи робить IPv6 це простішим або складнішим?

Безпосередньо — ні. Механізми ip6 не коштують DNS-запитів. Але двостекові провайдери можуть збільшити розмір запису, якщо ви флаттените все. Тримайте запис акуратним і авторизуйте лише те, що використовуєте.

10) У чому різниця між SPF fail і SPF permerror?

Fail означає, що запис було оцінено і IP не авторизовано. Permerror означає, що сам запис зламаний (занадто багато запитів, кілька записів, некоректний синтаксис). Permerror часто трактують як серйозний негативний сигнал.

Висновок: наступні кроки, що працюють

Виправлення «SPF: занадто багато DNS-запитів» — це не про хитрощі, а про відмову дозволяти кореневому домену стати сміттєвим майданчиком для кожного чекліста SaaS. Тримайте кореневий SPF малим, стабільним і під контролем. Переносьте мінливість на піддомени. Використовуйте явні IP, коли ви ними керуєте. Делегуйте лише коли потрібно — і завжди рахуйте вартість.

Наступні кроки:

Отримайте поточний SPF і розгорніть кожен include у список залежностей.
Для кожного include доведіть його необхідність реальними заголовками з вашим MAIL FROM.
Перенесіть маркетинг і джерела з високою мінливістю на окремі піддомени з їхнім SPF/DKIM/DMARC.
Замініть mx/a на ip4/ip6 для стабільних вихідних MTA.
Стендуйте і тестуйте на піддомені, потім розгорніть із планом відкату та моніторингом.