Електронна пошта: include у SPF — як спростити, не порушивши доставку

Чому include у SPF псуються (і чому це важливо)

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

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

Ось чому include перетворюються на безлад:

• Include — це транзитивно. Кожен include: може сам містити інші SPF‑записи, кожна з яких додає нові запити. Ви не контролюєте, що ваш постачальник додасть пізніше.
• Include ховають роботу. Ваш SPF‑запис виглядає коротким, але ефективна політика може бути невеликою новелою DNS‑запитів.
• Треті сторони часто змінюються. Постачальники змінюють інфраструктуру. Їхній SPF змінюється. Іноді вони додають вкладені include. Ви успадковуєте їхню складність.
• Ви продовжуєте додавати відправників. Ніхто не видаляє старі інструменти. Вони просто «призупиняють кампанії». Що по‑корпоративному означає «ми повернемося через 18 місяців».

Операційно SPF — це проблема графа залежностей. Не рядкова проблема. Ставтеся до неї як до управління залежностями: інвентаризуйте, закрепіть вимоги, скоротіть опціональні залежності і моніторьте дрейф.

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

Як насправді виглядає «злам пошти»

Рідко трапляється чисте відключення. Це повільна втрата якості:

• Нові реєстрації перестають отримувати підтвердження на певних ISP.
• Продажні листи «раптом» потрапляють у спам (переклад: це триває тижнями).
• DMARC‑звіти показують зростання SPF‑помилок від легітимних джерел, що ви забули.
• Підтримка надсилає квитки з кодами відмов, які різняться залежно від приймача і настрою.

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

Цікаві факти та коротка історія

Шість‑десять коротких контекстних пунктів — бо розуміння походження SPF робить нинішній безлад… неминучим.

1. SPF зʼявився раніше за сучасний сплеск хмарної пошти. Його проєктували, коли «ваші вихідні поштові сервери» були невеликою, переважно статичною множиною.
2. Ліміт у 10 запитів — навмисний. Це механізм проти зловживань та DoS: приймачі не повинні бути вимушені виконувати необмежену DNS‑роботу на повідомлення.
3. include — ефективно умовний перехід. include: каже «якщо відправник проходить ту іншу політику, вважай це проходом тут». Це не просто злиття списків.
4. SPF перевіряє домен у MAIL FROM, а не заголовок From: це дивує людей і дотепер, і саме тому існує DMARC для вирівнювання ідентичності.
5. SPF може ламатись при переадресації. Класична пересилка часто ламає SPF, бо пересилювач не авторизований оригінальним SPF.
6. Приймачі не завжди погоджуються у крайніх випадках. Специфікація ясна в багатьох моментах, але реальна поведінка щодо permerror, temperror і неоднозначних DNS‑відповідей відрізняється.
7. TTL у DNS — це оперативний важіль. Короткі TTL полегшують швидкі зміни, але збільшують трафік DNS; довгі TTL роблять помилки тривалими.
8. «Flattening» SPF став домашньою індустрією. Через глибокі ланцюги include люди почали попередньо розвʼязувати include у конкретні IP — іноді безпечно, іноді ні.
9. SPF широко використовується, бо це дешево. Публікувати TXT‑запис легше, ніж керувати ключами (DKIM) або забезпечувати вирівнювання (DMARC), тож SPF часто стає «першим і єдиним» контролем.

Ментальна модель: як SPF насправді оцінюється

Коли приймач оцінює SPF, він виконує маленьку програму: починає з домену в SMTP‑конверті (MAIL FROM) і запитує у DNS політику SPF для цього домену (зазвичай через TXT‑запис, що починається з v=spf1). Потім перевіряє механізми зліва направо, доки один із них не співпаде й не поверне результат.

Механізми, що важливі для include

• include: змушує оцінювача запросити та оцінити SPF включеного домену. Це коштує DNS‑запитів (принаймні один TXT‑запит, плюс те, що тригерить включений запис).
• a та mx теж можуть викликати запити. Якщо ваш запис використовує mx, оцінка SPF мусить опитати MX, а потім розвʼязати A/AAAA для кожного MX‑цільового імені.
• exists запускає запити й може бути зловживаним. Ставтеся до нього підозріло, якщо немає вагомої причини.
• ptr застарілий з причин продуктивності та можливостей підробки. Якщо у вас він ще є — ви тягнете історичний борг із відсотками.
• ip4/ip6 «безкоштовні» з точки зору обліку DNS‑запитів. Вони не вимагають запитів під час оцінки. Проте їх підтримка може бути операційно витратною.
• redirect= схожий на «замінити мою політику на політику іншого домену». Корисно централізувати SPF для піддоменів.

Чому ліміт запитів кусається сильніше, ніж здається

Ліміт враховує ті механізми та модифікатори, що спричиняють DNS‑запити: include, a, mx, ptr, exists і redirect. Те, що здається «одним include», може бути «одним include плюс пʼять MX плюс вісім A/AAAA‑резольвів».

Також оцінка SPF може включати як A, так і AAAA‑запити. Навіть якщо ви не використовуєте IPv6 навмисно, ваш DNS або DNS постачальника може публікувати AAAA, і деякі оцінювачі опитують обидва типи.

Субʼєктивна думка: якщо ви не можете пояснити кількість DNS‑запитів свого SPF‑запису на дошці з памʼяті, ви ним не володієте. Ви його орендуєте у випадку.

Цитата про надійність (парафраз)

Парафразована думка (Werner Vogels, AWS): «Проєктуйте так, щоб відмови були очікуваними, і створюйте системи, які продовжують працювати, коли частини ламаються.» Include у SPF — це частини.

Швидкий план діагностики

Що робити, коли доставлення горить і хтось щойно вставив у Slack скріншот bounce‑повідомлення.

Перше: ідентифікуйте, яка ідентичність фейлить

1. Перевірте MAIL FROM / Return‑Path у заголовках невдалого листа (або в конфігурації відправника). SPF оцінює саме його, а не видимий From.
2. Підтвердіть IP відправника із заголовків Received або логів MTA.
3. Запитайте: це новий відправник чи шлях переадресації? Новий відправник — інвентаризаційна прогалина SPF; переадресація — очікувана проблема SPF, потрібна стратегія DKIM/DMARC.

Друге: визначте, «політика неправильна» чи «політика зламана»

1. Запитайте TXT‑запис SPF і підтвердіть, що для цього домену є рівно одна політика SPF.
2. Порахуйте DNS‑запити (або хоча б визначте глибину include‑ланцюга). Якщо ви близькі або вище 10 — припускайте permerror в полі.
3. Перевірте проблеми з DNS: NXDOMAIN, SERVFAIL, таймаути або сюрпризи split‑horizon.

Третє: оберіть найменш ризикове помʼякшення

1. Якщо проблема в ліміті запитів: видаліть неважливі include, або перемістіть відправника на піддомен з власним SPF, або тимчасово авторизуйте конкретний діапазон IP за допомогою ip4/ip6 (з чітким планом змін для подальшого видалення).
2. Якщо просто відсутній IP відправника: додайте правильну авторизацію, але лише після перевірки, що система справді відправляє з домену конверта.
3. Якщо це розрив через переадресацію: не «виправляйте» SPF авторизацією пересилача; це whack‑a‑mole. Використовуйте DKIM/DMARC і/або ARC там, де це застосовно.

Одне правило: не «оптимізуйте» під час діагностики. Спочатку стабілізуйте, потім спрощуйте.

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

Це реальні операційні завдання. Кожне містить команду, приклад виводу, що це означає, і наступне рішення. Запускайте їх з Linux‑хоста зі стандартними інструментами. Якщо цих інструментів немає — встановіть їх на jump‑боксі, а не на ваших поштових серверах під час інциденту.

Завдання 1: Отримати SPF‑запис (і перевірити, чи їх не кілька)

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

Що це означає: Є рівно один рядок політики SPF (той, що починається з v=spf1). Добре.

Рішення: Якщо ви бачите більше ніж один рядок v=spf1, його треба консолідувати; кілька SPF‑записів часто дають permerror.

Завдання 2: Підтвердити домен конверта у повідомленні (локальний MTA)

cr0x@server:~$ postcat -q 1A2B3C4D | sed -n '1,40p'
*** ENVELOPE RECORDS ***
message_arrival_time: Tue Jan  2 12:01:09 2026
original_recipient: user@example.net
sender: bounce@mailer.example.com
*** MESSAGE CONTENTS ***
Return-Path: <bounce@mailer.example.com>
From: "Example Billing" <billing@example.com>
To: user@example.net
Subject: Invoice

Що це означає: SPF буде оцінюватися відносно mailer.example.com (Return‑Path / sender), а не example.com у видимому From.

Рішення: Аудитуйте SPF для домену конверта, що фактично відправляє, а не того, який маркетинг думає використовувати.

Завдання 3: Швидка перевірка через OpenSSL (перевірка банера SMTP та TLS)

cr0x@server:~$ openssl s_client -starttls smtp -crlf -connect mx1.receiver.net:25 </dev/null | sed -n '1,15p'
CONNECTED(00000003)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R3
verify return:1
depth=0 CN=mx1.receiver.net
verify return:1
250 mx1.receiver.net ESMTP ready

Що це означає: Це не безпосередньо SPF, але ви підтверджуєте, що до приймача можна дійти й що TLS‑негоціація не є реальною проблемою під час тестів.

Рішення: Якщо мережеве підключення/TLS падає — виправте це перед тим, як звинувачувати SPF. «Аварії» доставлення іноді починаються з вашої мережі.

Завдання 4: Рекурсивно інспектувати include у SPF (базово)

cr0x@server:~$ dig +short TXT _spf.google.com
"v=spf1 ip4:74.125.0.0/16 ip4:173.194.0.0/16 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"

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

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

Завдання 5: Порахувати кількість SPF‑рядків (захист від випадкового дублювання)

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

Що це означає: Один SPF‑запис. Чудово.

Рішення: Якщо вивід — 2 або більше, консолідуйте в один. Видаліть зайві. Не намагайтеся «розділити» SPF по записах; SPF так не працює.

Завдання 6: Перевірити, чи піддомен вже має власний SPF

cr0x@server:~$ dig +short TXT mailer.example.com
"v=spf1 include:spf.vendor-mail.com -all"

Що це означає: Постачальник уже підтримує відправку з делегованого піддомену з окремим SPF.

Рішення: Надавайте перевагу переміщенню відправників постачальника на їхній піддомен SPF замість накопичення записів на апексі домена.

Завдання 7: Знайти MX‑записи (і усвідомити, що mx може коштувати запитів)

cr0x@server:~$ dig +short MX example.com
10 mx01.mailhost.example.net.
20 mx02.mailhost.example.net.

Що це означає: Якщо ваш SPF використовує mx, оцінка може розвʼязувати ці імена і їхні A/AAAA‑записи. Це кілька запитів.

Рішення: Уникайте mx у SPF, якщо ви дійсно не відправляєте вихідну пошту з ваших вхідних MX‑хостів (рідко у сучасних налаштуваннях).

Завдання 8: Розвʼязати A та AAAA для MX‑цілей (бюджетування запитів)

cr0x@server:~$ dig +short A mx01.mailhost.example.net
203.0.113.10
203.0.113.11

cr0x@server:~$ dig +short AAAA mx01.mailhost.example.net
2001:db8:10::10

Що це означає: Багато адрес означає додаткову роботу для резольверів. Деякі опитують і A, і AAAA.

Рішення: Якщо ви планували використовувати mx або a у SPF, розгляньте явні ip4/ip6 для передбачуваності (з планом підтримки).

Завдання 9: Виміряти час відповіді DNS і виявити ненадійність резольвінгу

cr0x@server:~$ dig example.com TXT +stats | tail -n 5
;; Query time: 142 msec
;; SERVER: 10.0.0.53#53(10.0.0.53) (UDP)
;; WHEN: Tue Jan  2 12:20:11 UTC 2026
;; MSG SIZE  rcvd: 232

Що це означає: 142 ms — не катастрофа, але якщо ваші include потребують багатьох запитів, латентність наростає. Якщо бачите секунди — у вас проблема з DNS.

Рішення: Якщо DNS повільний або падає, оцінка SPF стає ненадійною. Виправте здоровʼя DNS (авторитетні сервери, резольвери, таймаути) перед «спрощенням» SPF.

Завдання 10: Перевірити авторитетні відповіді проти рекурсивних (пастки split‑horizon)

cr0x@server:~$ dig @ns1.example-dns.net example.com TXT +norecurse +short
"v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

Що це означає: Ви бачите те, що публікує авторитетний сервер. Якщо це відрізняється від відповіді вашого внутрішнього резольвера — у вас split‑horizon DNS або кеш‑проблеми.

Рішення: Переконайтеся, що публічний авторитетний запис правильний; приймачі використовують публічний DNS, а не ваш внутрішній вигляд.

Завдання 11: Знайти биту include‑ціль (NXDOMAIN/SERVFAIL)

cr0x@server:~$ dig +short TXT spf.dead-vendor.example

Що це означає: Порожній вивід зазвичай означає NXDOMAIN або відсутність TXT. Це include зламає оцінку в залежності від поведінки приймача і тлумачення специфікації.

Рішення: Негайно видаліть мертві include. Якщо вам все ще потрібен цей відправник — замініть include на їхній поточний підтримуваний домен або явні IP.

Завдання 12: Виявити надто великі TXT‑рядки SPF (ліміти DNS і лапкування)

cr0x@server:~$ dig +short TXT example.com | awk 'length($0) {print length($0), $0}'
92 "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"
33 "google-site-verification=abc123"

Що це означає: TXT‑записи можуть розбиватися на кілька процитованих рядків сервером DNS; деякі інструменти і люди неправильно обробляють це. Великі SPF‑записи також можуть перевищувати практичні ліміти й сприйматися як пошкоджені.

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

Завдання 13: Підтвердити, що конкретний IP пройде SPF (локальна перевірка spfquery)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@mailer.example.com -helo mailer.example.com
pass

Що це означає: Для цього домену конверта та IP SPF має проходити.

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

Завдання 14: Перевірити підказки вирівнювання DMARC (щоб не «виправити» невірний рівень)

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc@reports.example.com; adkim=s; aspf=s"

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

Рішення: При спрощенні SPF враховуйте архітектуру ідентичностей: вирівняйте відправників під правильний піддомен або забезпечте вирівнювання DKIM.

Завдання 15: Перевірити останні логи пошти на патерни «SPF permerror» (приклад Postfix)

cr0x@server:~$ sudo grep -i "spf" /var/log/mail.log | tail -n 8
Jan  2 12:12:41 mx postfix/smtpd[22191]: warning: SPF: permerror (too many DNS lookups) identity=mailfrom; client-ip=198.51.100.77; helo=mailer.example.com; envelope-from=bounce@mailer.example.com; receiver=mx
Jan  2 12:13:02 mx postfix/smtpd[22191]: warning: SPF: fail identity=mailfrom; client-ip=203.0.113.55; envelope-from=noreply@example.com

Що це означає: У вас є і перевищення ліміту запитів, і простий fail для іншої ідентичності. Два різні проблеми за один тиждень. Класика.

Рішення: Пріоритезуйте permerror спочатку; воно може зруйнувати доставлення навіть для легітимного трафіку. Потім розбирайтесь із відсутніми відправниками.

Завдання 16: Перевірити, що TXT‑зміни проросли (слідкуйте за TTL і кешуванням)

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

Що це означає: TTL — 300 секунд (5 хвилин). Це дружньо під час інциденту.

Рішення: Для планованих міграцій знизьте TTL за день до змін. Для стабільної роботи підвищуйте TTL, щоб зменшити навантаження на резольвери й покращити кеш‑попадання.

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

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

1) Перестаньте трактувати апекс‑домен як смітник

Переносьте сторонніх відправників на піддомени, коли це можливо. Це найбільш дієвий крок. Приклади:

• mailer.example.com для маркетингової автоматизації
• support.example.com для тикет‑системи
• notify.example.com для нотифікацій продукту

Потім публікуєте окремі SPF для кожного піддомену. Ваш апекс‑SPF залишається лаконічним: лише інфраструктура, яка справді надсилає листи як @example.com.

Компроміс: потрібно переконатися, що видимі From‑домени і DKIM вирівнюються з DMARC, інакше ви виправите SPF, але все ще програєте DMARC.

2) Віддавайте перевагу redirect= для узгодженості між піддоменами

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

• v=spf1 redirect=_spf.example.com
• А потім визначте реальну політику в _spf.example.com

Це не зменшує кількість запитів магічно, але зменшує адміністративні помилки. Це спрощення контроль‑площини, а не дано‑площини.

3) Будьте безжальні у видаленні застарілих відправників

Більшість організацій тримає include для постачальників, якими вони не користуються роками. Include коштують бюджету запитів і збільшують зону впливу змін постачальника.

Операційний рух: вимагайте «власника» для кожного include з квартальною переатестацією. Немає власника — немає include.

4) Уникайте mx і a, якщо ви не маєте на увазі їх буквально

mx у SPF — класичний трюк: «якщо він може приймати пошту для нас, він може й надсилати». У сучасних середовищах вхідна і вихідна пошта часто розділені. Використання mx часто авторизує хости, які не повинні відправляти від вашого імені.

Рекомендація: Якщо у вас невеликий, стабільний пул вихідних серверів — використовуйте явні ip4/ip6. Якщо ні — використовуйте піддомени і include постачальників. Не використовуйте mx як лінивий скорочувач.

5) Flattening: корисно, ризиковано, іноді необхідно

«Flattening» означає заміняти include на отримані діапазони IP (ip4/ip6), щоб під час оцінки не було потреби в багатьох DNS‑запитах. Це може бути ефективним для утримання в межах 10‑запитного ліміту.

Але flattening має гострі кути:

• IP‑діапазони постачальника можуть змінитись без повідомлення. Ваш flattened‑запис застаріє, і ви почнете втрачати легітимну пошту.
• Великі списки IP роблять TXT‑записи довгими й більш схильними до помилок при редагуванні.
• Ви можете випадково авторизувати більше, ніж потрібно, якщо флаттените занадто широко.

Коли flattening прийнятний: для відправників з опублікованими, стабільними діапазонами IP і процесом зміни у вас, щоб регулярно оновлювати їх. Ставтеся до цього як до правила брандмауера: планово, з ревʼю та моніторингом.

Другий короткий жарт: Flattening SPF як приготування їжі наперед: економить час під час тижня, доки ви не забудете його в холодильнику й воно не перетвориться на науковий проєкт.

6) Робіть із SPF продукт: версіонуйте, тестуйте й етапуйте

Зміни SPF мають проходити ту саму дисципліну, що й продакшн‑конфіг:

• Тримайте запис у git (як текст з коментарем у репозиторії).
• Майте тестову рантайм‑среду, що рахує запити і валідовує синтаксис.
• Використовуйте поетапне розгортання через зниження TTL, потім деплой і моніторинг DMARC‑звітів та бонсу.

7) Вирівнюйте архітектуру ідентичностей з DMARC, а не проти нього

Команди часто намагаються виправити доставлення, запхавши більше в SPF, коли справжня проблема — невідповідність ідентичностей. Якщо у вас суворий DMARC, ви мусите забезпечити або:

• SPF проходить і вирівнюється (домен конверта вирівнюється з From), або
• DKIM проходить і вирівнюється (d= домен вирівнюється з From)

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

Три корпоративні міні‑історії з полігонів SPF

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

Середня SaaS‑компанія відправляла пошту з трьох місць: Google Workspace для людей, транзакційний провайдер для продукту і маркетингова платформа для кампаній. Їхній SPF на апексі вже був важким, але переважно проходив, що у пошті заохочує погану поведінку.

Нова інтеграція випустила функцію: «Відправляти запрошення з вашого домену». Інженери припустили, що це означає додати DKIM‑ключ і підписувати як example.com. Розумне припущення. Команда інтеграції налаштувала постачальника на використання bounce@vendor.example.net як envelope sender за замовчуванням, і ніхто не запитав, яка саме «SPF‑ідентичність» буде оцінюватися.

Через два тижні запрошення почали відскакувати у великого приймача. У bounce‑повідомленні йшлося про помилки SPF для vendor.example.net, а не для example.com. Підтримка передала це SRE. SRE дивився на апекс‑SPF 10 хвилин, перш ніж зрозуміти, що він тут ні до чого. Невірний домен. Невірна ідентичність.

Виправлення не було «додати ще один include». Виправлення — перемістити envelope sender постачальника на mailer.example.com і опублікувати для піддомену присвячений SPF. DKIM‑вирівнювання оновили. Інцидент швидко завершився, але постмортем був відвертим: не можна розмірковувати про аутентифікацію пошти, дивлячись тільки на From‑заголовок і інтуїцію.

Міні‑історія 2: Оптимізація, що дала відкат

Команда IT великого підприємства вирішила «очистити DNS». Вони помітили, що їхній SPF використовує include: для провайдера, який фактично розгортав багато ip4 діапазонів. Вони чули про flattening SPF, і це здалося перемогою продуктивності. Тож вони вручну флаттенили.

Спочатку було добре: менше DNS‑запитів, коротший include‑ланцюг, менше інтермітентних temperror квитків від приймачів зі строгими таймаутами. Вони оголосили перемогу й перейшли далі. Місяць потому почався повільний приплив скарг «скидання паролів не приходить» з деяких провайдерів пошти.

Постачальник додав нові IP. Include‑запис оновився. Flattened‑запис — ні. Пошта не падала всюди; вона падала настільки, щоб стати дорогою і складною для доведення. Ніхто не хотів відкотити, бо flattening подавали як поліпшення безпеки. Це не брехня, але не вся правда.

Вони врешті переглянули підхід: автоматизувати flattening з плановим оновленням, робити diff‑ревʼю змін і обмежувати список лише сервісами постачальника, якими реально користуються. Відкат стався не через сам flattening, а через його застосування без ставлення до нього як до живої залежності.

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

Глобальна компанія мала репутацію «повільної» щодо змін пошти. Кожне оновлення SPF вимагало власника, квитка, плану відкату і 24‑годинного періоду спостереження. Люди скаржилися. Маркетинг скаржився голосніше. Це природний порядок речей.

Одного ранку відомий постачальник пошти мав DNS‑аварію. Їхній include‑домен періодично повертав SERVFAIL. Багато клієнтів бачили спорадичні temperror під час оцінки SPF. Деякі приймачі відкладали пошту. Деякі трактували це як підозріле. Хаос, але ввічливий хаос.

Ця компанія мала дві переваги: (1) їхній апекс‑SPF мав лише один сторонній include, бо майже вся пошта від постачальників йшла через делеговані піддомени, і (2) у них був моніторинг, який вибірково опитував SPF‑резольвінг з кількох публічних резольверів і оповіщував про SERVFAIL та аномалії в лічильнику запитів.

Відповідь була нудною: тимчасово спрямувати критичну транзакційну пошту через вторинного провайдера, який уже був авторизований на піддомені, і дочекатися відновлення DNS постачальника. Жодних панічних правок апекс‑SPF. Жодних «просто додайте цей include» о 9‑й ранку. Пост‑інцидентний аналіз був так само нудним: вони задокументували залежність від провайдера і залишили архітектуру. У продукційних системах «нудно» — це комплімент.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: періодичні відмови, іноді «permerror»

Корінь: надто багато DNS‑запитів через вкладені include, плюс механізми mx/a всередині include‑ланцюгів.

Виправлення: зменште залежності: перемістіть постачальників на піддомени, видаліть застарілі include, уникайте mx/a у SPF, розгляньте кероване flattening з оновленням.

2) Симптом: «SPF fail», але ви клянетесь, що From‑домен правильний

Корінь: ви дивитесь на заголовок From; SPF перевіряє домен конверта (Return‑Path).

Виправлення: перевірте заголовки/логи, щоб знайти MAIL FROM. Виправте конфігурацію домена конверта або опублікуйте SPF для фактичного домену конверта.

3) Симптом: SPF раптом ламається після «невеликого прибирання DNS»

Корінь: існує кілька SPF‑записів (кілька рядків v=spf1), або хтось зіпсував лапкування/пробіли і зламав розбір.

Виправлення: опублікуйте рівно одну політику SPF на домен; валідовуйте інструментами; тримайте SPF у системі контролю версій.

4) Симптом: переадресація пошти викликає SPF‑помилки

Корінь: пересилювачі відправляють зі своїх IP; оригінальний домен SPF їх не авторизує.

Виправлення: не авторизуйте весь світ. Використовуйте DKIM‑підписування з вирівнюванням і DMARC; для пересилювачів/пересилки, що підтримують ARC, ARC може зберегти результати аутентифікації.

5) Симптом: SPF проходить, але DMARC відхиляє

Корінь: SPF проходить для домену конверта, який не вирівнюється з From під DMARC (особливо при суворому вирівнюванні).

Виправлення: вирівняйте ідентичності: використайте однаковий домен конверта (часто піддомен From) і/або забезпечте вирівнювання DKIM d= з From.

6) Симптом: SPF працює для IPv4, але падає в деяких приймачів

Корінь: деякі хости відправляють через IPv6, але SPF авторизує лише IPv4, або include‑ланцюг поводиться інакше при AAAA‑запитах і таймаутах.

Виправлення: інвентаризуйте фактичні IP‑адреси відправників, включно з IPv6; авторизуйте ip6: за потреби; переконайтеся, що вихідні MTA не витікають через несподівані IPv6‑шляхи.

7) Симптом: пошта постачальника падає лише в деяких регіонах

Корінь: ви флаттенили SPF і пропустили нові пулі IP постачальника, або постачальник має кілька include‑доменів для різних продуктів і ви включили неправильний.

Виправлення: поверніться до include постачальника, якщо дозволяєте бюджет запитів, або впровадьте автоматичне оновлення flatten з ревʼю; перевірте, що ви використовуєте правильний SPF include для потрібного продукту.

8) Симптом: приймачі повідомляють «temperror» у SPF

Корінь: таймаути DNS, SERVFAIL або ненадійні авторитетні сервери як ваші, так і include‑цільові.

Виправлення: зміцніть DNS (резервність авторитетних серверів, здоровʼя резольверів), зменшіть кількість запитів, щоб скоротити час на DNS, моніторьте з кількох публічних резольверів.

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

Покроково: безпечно спростити include у SPF

1. Інвентаризуйте відправників. Перелічіть кожну систему, що відправляє пошту від вашого бренду: поштові скриньки людей, транзакційні, маркетинг, підтримка, фінанси, моніторинг, CI і «запрошення продукту». Привʼяжіть кожну до власника.
2. Для кожного відправника зафіксуйте ідентичності. From‑домен, домен конверта, DKIM d= домен, діапазони IP (v4/v6) і чи підтримує він кастомний return‑path.
3. Намалюйте поточний граф залежностей SPF. Апекс‑SPF плюс усі include і include всередині include. Порахуйте орієнтовні DNS‑запити.
4. Визначте стратегію доменів. Які відправники дійсно мають відправляти як @example.com? Все інше йде на делеговані піддомени.
5. Переміщайте по одному відправнику на піддомен. Налаштуйте постачальника на використання bounce@mailer.example.com (або подібного), опублікуйте SPF для піддомену, забезпечте DKIM‑вирівнювання.
6. Тримайте апекс‑SPF мінімальним. Зазвичай: корпоративний поштовий провайдер + основний транзакційний провайдер, і лише якщо вони повинні використовувати апекс‑домен.
7. Видаліть застарілі include. Якщо інструмент «неактивний», видаліть його. Якщо хтось пожаліється пізніше — нехай реавторизує його свідомо.
8. Знизьте TTL перед великими змінами. Робіть це принаймні за день до, якщо можете. Після стабілізації підвищуйте TTL назад.
9. Перевірте синтаксис і бюджет запитів. Запустіть тести оцінки SPF для репрезентативних IP і ідентичностей.
10. Розгорніть і спостерігайте. Слідкуйте за DMARC‑агрегатами і incoming bounce. Очікуйте затримки через кеші і період звітності.
11. Задокументуйте контракт. Для кожного include/піддомену опишіть: власник, постачальник, навіщо існує, що авторизує і як його ротувати.
12. Моніторьте дрейф. Include можуть змінюватися під вами. Слідкуйте за лічильником запитів і здоровʼям DNS як безперервний сигнал.

Операційний контрольний список: перед тим як додати новий include:

• Чи дійсно потрібно відправляти з апекс‑домену, чи можна використати піддомен?
• Який envelope‑from у постачальника і чи підтримує він кастомний return‑path?
• Який наш поточний бюджет запитів і скільки коштуватиме це include після розгортання?
• Хто власник цього відправника і чи переатестує він щоквартально?
• Чи є у нас DKIM‑вирівнювання, що задовольнить DMARC?
• Який відкат, якщо це include спричинить permerror?

Аварійний контрольний список: «Ми отримали permerror»

• Підтвердьте permerror (too many DNS lookups) у логах або зворотному фідбеку приймача.
• Визначте останню зміну SPF (diff ваших DNS‑записів).
• Тимчасово видаліть найменш критичні include, щоб опуститись нижче ліміту.
• Якщо видалення ламає бізнес‑критичний відправник, перемістіть його на піддомен з власним SPF як реальне виправлення.
• Після стабілізації проведіть повну інвентаризацію відправників і спростіть правильно.

Питання і відповіді

1) Чому в SPF є ліміт «10 DNS‑запитів»?

Тому що приймачі повинні оцінювати SPF для величезних обсягів пошти. Без ліміту SPF можна зловживати, змушуючи виконувати надмірну DNS‑роботу на повідомлення, перетворюючи прийом пошти на тест навантаження DNS.

2) Чи додають ip4: записи DNS‑запити?

Ні. Механізми ip4/ip6 не вимагають DNS‑запитів під час оцінки SPF. Вони «дешеві» для приймачів, але ви платите вартість їхнього обслуговування.

3) Чи «погані» a та mx у SPF?

Не обовʼязково, але їх часто використовують ліниво, і вони можуть роздути кількість запитів. Також вони часто авторизують більше хостів, ніж ви мали на увазі. У 2026 році явні IP або піддомени постачальників зазвичай безпечніші.

4) У чому різниця між include: та redirect=?

include: каже «якщо включена політика проходить, вважай це проходом тут» і оцінка продовжується, якщо ні. redirect= каже «використай політику того іншого домену як політику для цього домену» (зазвичай як фінальний модифікатор).

5) Чи можу я мати кілька TXT‑записів SPF, щоб уникнути довжини чи складності?

Ні. Публікація кількох v=spf1 записів — поширена помилка і часто дає permerror. Вам потрібна рівно одна політика SPF на домен.

6) Якщо ми використовуємо DMARC, чи все ще потрібен SPF?

Так. DMARC спирається на те, щоб SPF і/або DKIM проходили і вирівнювалися. SPF залишається основним вхідним сигналом, і багато приймачів використовують результати SPF поза межами DMARC‑оцінки.

7) Чому переадресація ламає SPF і що робити?

Пересилювачі відправляють зі своїх IP, які не входять у ваш SPF. Довготривале рішення — підписувати DKIM з вирівнюванням і застосовувати DMARC. У деяких середовищах ARC допомагає зберегти результати аутентифікації при переадресації.

8) Використовувати ~all чи -all?

Використовуйте -all, коли впевнені в інвентарі і застосовуєте жорстку політику. Використовуйте ~all під час міграцій, якщо потрібна телеметрія і хочете зменшити жорсткі відмови. Але не тримайте ~all вічно; це стає постійною невизначеністю в DNS.

9) Який кращий спосіб спростити SPF без flattening?

Делегуйте. Переносьте сторонню пошту на піддомени з власним SPF і вирівняним DKIM. Тримайте апекс‑SPF лише для декількох систем, які мають надсилати як апекс‑домен.

10) Як моніторити дрейф include у SPF з часом?

Періодично розвʼязуйте свій SPF‑запис, прогуляйте include і відстежуйте лічильник запитів та DNS‑помилки з кількох резольверів. Ставте оповіщення на зміни, особливо нові вкладені include або нові механізми як exists.

Висновок: практичні наступні кроки

Якщо ваш SPF‑запис — купа include, у вас немає SPF‑запису. У вас є граф залежностей, яким ви не керуєте. Вихід не в героїчному DNS‑кунг‑фу; вихід у архітектурі та власності.

1. Сьогодні: витягніть поточний SPF, підтвердіть, що у вас рівно один v=spf1, і визначте, чи ви не близькі до ліміту 10 DNS‑запитів.
2. Цього тижня: інвентаризуйте відправників і перемістіть принаймні одного великого стороннього відправника на делегований піддомен з власним SPF і вирівняним DKIM.
3. Цього місяця: встановіть власність для кожного відправника/include, впровадьте легкий конвеєр валідації (синтаксис + бюджет запитів) і додайте моніторинг DNS‑помилок та несподіваного дрейфу include.

SPF не потрібно робити ідеальним. Потрібно, щоб він був оперований. Тримайте його в межах ліміту запитів, вирівнюйте з тим, як ваша пошта фактично відправляється, і не ховайте складність у DNS. Ваші поштові скриньки — і ваш сон — покращаться.