Збої SPF електронної пошти: 5 помилок у записах, що руйнують доставку (і їх виправлення)

SPF простими словами для операцій (що він насправді робить)

SPF (Sender Policy Framework) — це політика, опублікована в DNS, яка каже приймачу, які IP-адреси дозволено використовувати для відправлення пошти від імені домену в ідентифікації SMTP «envelope-from» (домен Return-Path). Приймач порівнює IP, що підключився, з цією політикою і отримує результат: pass, fail, softfail, neutral, none, temperror або permerror.

У продакшені SPF виконує дві задачі:

• Зупиняє випадкове підроблення вашого домену в envelope-from (не обовʼязково в видимому заголовку From:).
• Живить політику далі, зокрема DMARC. DMARC використовує SPF (і/або DKIM) плюс правила вирівнювання, щоб вирішити, чи помістити лист в карантин або відхилити.

SPF — це не магія. Він не шифрує. Він не доводить, що людина написала лист. Часто він не витримує пересилання. Це перевірка політики, привʼязана до SMTP-клієнтського IP у момент доставки. Саме тому «коректний» на папері SPF може провалюватися, коли шлях доставки листа змінюється.

Ще нюанс: SPF оцінюється по envelope-from домену (Return-Path), а не по привабливому заголовку From:, який бачать люди. Якщо ваш постачальник використовує bounces.vendor.example як return-path, а ваш DMARC-домен — example.com, SPF може проходити, але не вирівнюватися. Це окрема проблема з таким же симптомом: «DMARC не пройшов».

Парафразуючи ідею Вернера Фогельса: Ви будуєте — ви експлуатуєте. Пошта не виняток. Якщо ви делегуєте відправлення постачальникам, ви все одно відповідаєте за результати автентифікації.

Жарт №1: SPF як вахтер у нічному клубі, що перевіряє список гостей. Якщо ви постійно переписуєте список під час зміни, не дивуйтесь, що ніхто не проходить.

Цікаві факти та історичний контекст

• SPF зʼявився раніше за DMARC. SPF набув широкого поширення в середині 2000-х; DMARC зʼявився пізніше, щоб уніфікувати SPF і DKIM під політикою власника домену.
• Ліміт «10 DNS-запитів» — навмисне обмеження. Він існує, щоб не змушувати приймача виконувати дорогі рекурсивні DNS-операції на повідомлення (класичний вектор DoS).
• TXT виграв боротьбу типів записів. Для SPF колись була спеціальна RR-типізація, але TXT став практичним стандартом через непослідовну підтримку DNS і інструментів.
• SPF перевіряє підключений IP, а не «відправника». Тому вихідні ретранслятори, загальні SaaS-пули і on-prem NAT часто стають пастками.
• «~all» стало популярним, бо здавалося безпечнішим. Softfail часто використовують під час розгортання, але багато організацій ніколи не завершують перехід на «-all», залишаючи вразливі шляхи для підроблення.
• Приймачі суворо ставляться до permerror. Синтаксична помилка або «вибух» запитів можуть спричинити permerror, і деякі приймачі фактично трактують це як відмову при застосуванні політик.
• Макроси SPF існують і рідко виправдані. Вони потужні й крихкі, можуть створювати непередбачувану поведінку запитів у різних приймачів.
• Вирівнювання — причина, чому DMARC змінив правила гри. Простий SPF “pass” недостатній; він має вирівнюватися з видимим From:, щоб DMARC визнав автентифікацію через SPF.
• Флеттенінг SPF — тимчасовий обхід, а не чеснота. Це обмінює DNS-індентифікацію на підтримку списку IP, і такий список швидко застаріває без автоматизації.

План швидкої діагностики

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

Перше: визначте, яка ідентичність провалюється (SPF проти DMARC проти «щось від постачальника»)

1. Здобудьте реальний bounce або заголовок приймача з невдалої доставки. Шукайте: spf=, dmarc=, dkim=, Authentication-Results: або явно «SPF fail».
2. Витягніть envelope-from домен (Return-Path) і підключений IP (зазвичай вказується в bounce або в логах SMTP).
3. Вирішіть, чи виправляєте SPF, вирівнювання чи маршрутизацію. Якщо SPF проходить, але DMARC не проходить — ви, можливо, маєте справу з вирівнюванням або DKIM.

Друге: перевірте публікацію DNS і поширення

4. Запитайте авторитетний вигляд DNS (не кешований резолвер вашого ноутбука). Підтвердіть, що є рівно одна узгоджена політика SPF і вона починається з v=spf1.
5. Порівняйте результати з кількох резолверів (публічних і внутрішніх). Якщо відповіді різняться — це питання поширення або split-horizon DNS.
6. Перевірте TTL, щоб оцінити, коли світ сконвергує зміни. Не здогадуйтеся. Читайте TTL.

Третє: оцініть SPF-запис так, як це робитиме приймач

7. Порахуйте DNS-запити (include, a, mx, ptr, exists, redirect). Якщо ви близькі до 10 — припустіть, що десь ви перевищуєте ліміт.
8. Протестуйте конкретний IP відправника проти запису. SPF перевіряє IP, що підключився, а не бренд постачальника.
9. Шукайте крихкі механізми: ptr, макроси, ланцюги з redirect, занадто широкі include.

Четверте: вирішіть найменш ризикове виправлення

• Якщо у вас кілька SPF TXT-записів: злийте в один. Це зазвичай найшвидший шлях до відновлення.
• Якщо ви перевищили ліміт запитів: зменшіть кількість include, приберіть a/mx якщо не потрібно, або флеттеньте (з автоматизацією) в крайньому разі.
• Якщо відхилення через те, що постачальник відправляє з несподіваних IP: виправляйте шлях відправлення або налаштування постачальника, а не лише SPF-запис.
• Якщо DMARC застосовується і SPF не вирівнюється: виправте вирівнювання (custom return-path) або кладіться на вирівнювання DKIM.

П’ять помилок у SPF-записах, що ламають доставку (і як їх виправити)

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

SPF permerror зʼявляється раптово після «невеликої зміни DNS»

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

Коренева причина: Ви перетнули ліміт у 10 запитів, додавши ще одне include, або створили кілька SPF TXT-записів.

Виправлення: Злийте в один SPF TXT-запис і зменшіть кількість запитів. Видаліть непотрібні include; замініть a/mx явними діапазонами IP, коли це можливо.

SPF проходить, але DMARC не проходить (і приймач все одно відкидає)

Симптоми: У заголовку видно spf=pass але dmarc=fail; у відмовах згадується політика DMARC. Користувачі повідомляють «в Gmail працює, а в корпоративних доменах — ні» або навпаки.

Коренева причина: SPF пройшов для envelope-from домену, який не вирівнюється з From: доменом. Або DKIM відсутній/пошкоджений і SPF — єдина надія.

Виправлення: Налаштуйте кастомний return-path під вашим доменом (вирівнювання) або забезпечте підпис DKIM, що вирівнюється з From: доменом і переживає шлях доставки.

SPF не проходить лише для одного потоку постачальника

Симптоми: Пошта Office 365 проходить; маркетингова платформа не проходить. Або транзакційна проходить; підтримка не проходить.

Коренева причина: Постачальник відправляє з IP, що не покриті SPF-записом для відповідного return-path домену; або використовує інший envelope-from домен, ніж ви припускали.

Виправлення: Визначте підключений IP і envelope-from домен з реальних заголовків. Оновіть правильний SPF-запис (часто це піддомен). Віддавайте перевагу include постачальника для їхнього пулу, якщо він не перевищує ліміти запитів.

SPF «none» зʼявляється, хоча ви «налаштували SPF місяці тому»

Симптоми: Приймачі показують spf=none. Ви стверджуєте, що SPF існує.

Коренева причина: Ви опублікували SPF на www.example.com або іншому домені, ніж той, який використовується в return-path. Або split-horizon DNS дає різні відповіді зовні та зсередини.

Виправлення: Запитайте фактичний return-path домен із повідомлення. Перевірте авторитетний зовнішній DNS. Приберіть внутрішні записи або узгодьте внутрішні/зовнішні зони.

SPF не проходить після ввімкнення нового вихідного ретранслятора або зміни NAT

Симптоми: Все було стабільно; потім відбулися інфраструктурні зміни (нові egress IP, новий пул ретрансляторів). Тепер доставка погіршилася.

Коренева причина: SPF дозволяє лише старі egress IP. SMTP клієнтський IP змінився.

Виправлення: Оновіть SPF з новими egress-діапазонами IP (або з include, опублікованим ретранслятором). Також перевірте, що ретранслятор справді використовується для всіх потоків; гібридні налаштування часто пропускають прямий вихід в інтернет.

Перервні результати SPF у різних отримувачів

Симптоми: Деякі отримувачі бачать pass, інші — fail або none. Це варіюється за регіонами/провайдерами.

Коренева причина: Різниця в поширенні DNS, застарілі кеші або несинхронізовані авторитетні NS. Інколи причина — помилка DNSSEC або проблема на шляху резолвера.

Виправлення: Перевірте авторитетні сервери безпосередньо та порівняйте відповіді через різні резолвери. Забезпечте ідентичні TXT-відповіді на всіх NS. Виправте процес розгортання DNS; тимчасово знизьте TTL під час контрольованих змін.

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

Нижче — перевірені в полі завдання, які можна виконати з Linux-хоста з поширеними інструментами. Кожне завдання містить: команду, типовий вихід, що це означає, і яке рішення прийняти.

Завдання 1: Витягнути опублікований SPF TXT-запис (простий вигляд)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Що це означає: Існує принаймні один TXT-запис; один рядок виглядає як SPF.

Рішення: Якщо ви бачите більше одного рядка з v=spf1, ймовірно у вас проблема «кілька SPF TXT» і потрібно негайно зливати записи.

Завдання 2: Явно виявити кілька SPF-записів

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 -all"
example.com.  300 IN TXT "v=spf1 include:spf.mailvendor.example ~all"

Що це означає: На одному імені опубліковано два SPF-політики.

Рішення: Розглядайте це як ризик permerror. Замініть обидва на один обʼєднаний SPF-рядок. Не «залишайте обидва і сподівайтеся, що приймачі виберуть один» — вони не повинні цього робити.

Завдання 3: Запитувати авторитетні nameserver-и (уникати обману кешу)

cr0x@server:~$ dig +short NS example.com
ns1.dnsprovider.example.
ns2.dnsprovider.example.

cr0x@server:~$ dig +noall +answer TXT example.com @ns1.dnsprovider.example
example.com.  300 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Що це означає: Ви дивитесь, що авторитетний сервер видає, а не те, що якийсь резолвер кешував вчора.

Рішення: Якщо ns1 і ns2 дають різні відповіді — у вас проблема публікації DNS. Виправте це спочатку; пошта — вже потім.

Завдання 4: Перевірити TTL, щоб оцінити час поширення

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.  3600 IN TXT "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Що це означає: TTL — 3600 секунд (одна година). Приймачі можуть кешувати до цього часу (іноді довше, якщо резолвери неправильно працюють).

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

Завдання 5: Перевірити, чи зовнішній IP виходу відповідає вашим очікуванням

cr0x@server:~$ curl -s ifconfig.me
203.0.113.55

Що це означає: Інтернет-егоуз IP цього хоста — 203.0.113.55.

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

Завдання 6: Підтвердити, який SMTP-клієнт насправді підключається до інтернету (логи Postfix)

cr0x@server:~$ sudo grep -E "to=<|relay=" /var/log/mail.log | tail -n 3
Jan 03 10:11:12 mx1 postfix/smtp[23144]: 3F2A0123: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.2, delays=0.1/0.1/0.4/0.6, dsn=2.0.0, status=sent
Jan 03 10:12:01 mx1 postfix/smtp[23188]: 9ABCD456: to=, relay=203.0.113.200[203.0.113.200]:587, delay=0.9, delays=0.1/0.1/0.2/0.5, dsn=2.0.0, status=sent
Jan 03 10:12:45 mx1 postfix/smtp[23210]: 7CDE9012: to=, relay=aspmx.l.google.com[142.250.115.27]:25, delay=1.0, delays=0.1/0.1/0.3/0.5, dsn=2.0.0, status=sent

Що це означає: Частина пошти йде напряму до отримувачів; частина — через смартхост за адресою 203.0.113.200.

Рішення: Змішаний маршрут ускладнює SPF, бо змінюється підключений IP. Вирішіть, чи навʼязати єдиний вихідний шлях (бажано), чи забезпечити SPF, що покриває всі можливі egress IP.

Завдання 7: Витягнути Return-Path і Authentication-Results з сирого повідомлення

cr0x@server:~$ sed -n '1,80p' message.eml | egrep -i '^(return-path|authentication-results|received|from:|dkim-signature):'
Return-Path: 
Authentication-Results: mx.recipient.example; spf=fail (sender IP is 198.51.100.77) smtp.mailfrom=bounce.mail.example.com; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
Received: from mta77.vendor.example (mta77.vendor.example [198.51.100.77])
From: Billing 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...

Що це означає: SPF не пройшов для bounce.mail.example.com з IP 198.51.100.77, але DKIM пройшов і DMARC пройшов (оскільки DKIM вирівняний з example.com).

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

Завдання 8: Розгорнути chain include (і знайти приховані «бомби» запитів)

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

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

Рішення: Коли ви поєднуєте кілька «великих» include-ів, ви ставитеся як до ставки, що не перевищите 10 запитів. Якщо ви близькі — рефакторьте, поки не зламалося.

Завдання 9: Орієнтовний підрахунок DNS-запитів (практичний метод)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounces@bounce.mail.example.com -helo mta77.vendor.example
result: pass
smtp.mailfrom: bounce.mail.example.com
Received-SPF: pass (bounce.mail.example.com: domain of bounces@bounce.mail.example.com designates 198.51.100.77 as permitted sender)

Що це означає: Локальна оцінка SPF повертає pass для цього IP і відправника. Це не ідентично поведінці всіх приймачів, але дає сильний сигнал.

Рішення: Якщо ваш тест показує pass, а приймач каже fail — підозрюйте, що вони оцінювали інший домен (проблема вирівнювання/return-path), бачили інший DNS (поширення/split-horizon) або стикнулися з обмеженнями запитів через відмінності в резолюванні.

Завдання 10: Перевірити, чи випадково не опублікували SPF під неправильним імʼям

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

cr0x@server:~$ dig +short TXT example.com
"google-site-verification=abc123"

Що це означає: SPF існує на www.example.com, але на кореневому example.com — немає.

Рішення: Якщо ваша пошта використовує example.com в return-path, то SPF фактично відсутній. Перенесіть SPF на правильне імʼя домену (або встановіть його на тому return-path-домені, який фактично використовується).

Завдання 11: Перевірити split-horizon DNS (внутрішні vs зовнішні відповіді)

cr0x@server:~$ dig +short TXT example.com @10.0.0.53
"v=spf1 ip4:10.10.10.10 -all"

cr0x@server:~$ dig +short TXT example.com @1.1.1.1
"v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

Що це означає: Внутрішній резолвер повертає внутрішній SPF (безглуздий для публічного інтернету), а публічні резолвери бачать реальну політику.

Рішення: Якщо внутрішні системи відправляють пошту в інтернет і залежать від SPF (або рішення про маршрут/підпис залежать від нього), split-horizon може спричинити самостійні відмови. Узгодьте зони або забезпечте внутрішнім резолверам доступ до тієї ж публічної відповіді SPF.

Завдання 12: Підтвердити вирівнювання DKIM, коли SPF крихкий

cr0x@server:~$ sed -n '1,120p' message.eml | egrep -i '^(from:|dkim-signature|authentication-results):'
From: Notifications 
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ...
Authentication-Results: mx.recipient.example; spf=softfail smtp.mailfrom=bounce.vendor.example; dkim=pass header.d=example.com; dmarc=pass header.from=example.com

Що це означає: DKIM проходить для example.com, і DMARC проходить, хоча SPF — softfail, бо SPF не вирівнюється (або слабкий).

Рішення: Якщо ви не можете швидко виправити SPF (обмеження постачальника, include-ліміти), зробіть DKIM надійним і вирівняним. Але не залишайте SPF зламаним назавжди; він і далі впливає на довіру і деякі евристики приймачів.

Завдання 13: Перевірити, що SPF закінчується на розумний дефолт

cr0x@server:~$ dig +short TXT example.com | tr ' ' '\n' | tail -n 1
-all"

Що це означає: Політика закінчується на -all, чітка позиція.

Рішення: Якщо вона закінчується на ~all і ви впевнені, що знаєте всіх відправників — заплануйте перехід на -all після перевірки логів на невідомі відправлення.

Завдання 14: Перевірити, чи використовуєте ризикові механізми (ptr, exists, макроси)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ptr exists:%{i}._spf.example.com include:spf.mailvendor.example -all"

Що це означає: ptr і exists задіяні; використані макроси. Це просунутий SPF і часто крихкий.

Рішення: Якщо у вас немає дуже специфічної потреби і ви не тестували через кілька приймачів — приберіть ptr і макросні exists. Замініть явними ip4/ip6 або стабільними include-посиланнями постачальників.

Три корпоративні історії з польових боїв SPF

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

Компанія на папері мала чисту конфігурацію: DMARC з p=reject, DKIM-підписування через центральний вихідний ретранслятор і акуратний SPF-запис. Хтось затвердив нову HR-платформу для розсилки вітальних листів. Це було «лише пошта», тож закупівля діяла швидше за інженерів.

Чекліст постачальника сказав: «Додайте цей SPF-запис». Адміністратор HR зробив саме це — додав другий TXT-запис на апекс з новим v=spf1. Ніхто не помітив, бо зміни DNS не сповіщають, поки щось не зламається.

Протягом кількох годин багато приймачів почали повертати permerror по SPF. DMARC почав застосовуватися там, де DKIM був відсутній (деякі транзакційні потоки не підписувалися — застарілі додатки надсилали напряму). Листи почали відскакувати. Видимим симптомом було не «SPF зламався», а «не надходять скидання пароля». Ось так ви дізнаєтесь, що пошта — частина вашої системи автентифікації.

Інженери врешті витягли невдалий заголовок, побачили spf=permerror і знайшли два SPF TXT-відповіді. Вони обʼєднали політики в один запис і видалили дублікати. Потім виявили гірше: половина корпоративної пошти навіть не проходила через ретранслятор послідовно.

Справжнє виправлення було не лише в злитті TXT. Вони зафіксували маршрути виходу, щоб сервери додатків не могли відправляти напряму в інтернет, а потім посилили SPF з -all. Хибне припущення було не технічне, а організаційне: «хтось інший володіє поштою». Насправді — пошта володіє вами.

Міні-історія №2: Оптимізація, яка призвела до проблем

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

Потім відбулося управління змінами. Скрипт не інтегрували в CI/CD; він жив на ноутбуку. Все працювало, поки людина з ноутбуком не пішла у відпустку, а постачальник не провів ротацію інфраструктури. Це не гіпотетика — великі поштові платформи переміщують IP-простір для балансування навантаження і управління репутацією.

За тиждень зʼявилися розрізнені SPF-fail. Постраждали лише деякі одержувачі, бо постачальник використовував різні пули за регіонами і типами повідомлень. Команда два дні шукала «фільтрацію по отримувачам», перш ніж хтось порівняв невдалий IP з флеттен-списком SPF.

Проблема була не в самому флеттені, а в тому, що його зробили без автоматизації, моніторингу і циклічних оновлень. Вони повернулися до include-ів постачальника, а потім повторно впровадили флеттенінг правильно — через заплановане завдання, яке діставало діапазони постачальника і опубліковувало DNS через стандартний пайплайн з відкатом і видимістю diff.

Урок: інженерія надійності не любить «одноразові покращення». Якщо покращення створює нове обовʼязкове обслуговування — автоматизуйте його або не робіть.

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

Інша організація мала політику: кожна зміна DNS, що стосується пошти (SPF, селектори DKIM, DMARC, MX), вимагала pull request в infrastructure-as-code з лінтером і простою канарською перевіркою. Ніхто не вважав це гламурним. Це була переважно YAML і суперечки про TTL.

Одної пʼятниці менеджер постачальника надіслав «терміновий» запит: додайте include до SPF до кінця дня, інакше кампанії затримаються. Маркетинг підвищив тон, звісно. Інженер на виклику додав зміну через звичний PR.

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

Вони запропонували нормальну альтернативу: опублікувати виділений піддомен для return-path цього постачальника і тримати апекс SPF компактним. Постачальник погодився, кампанії пройшли, і нічого не зламалося. Нудна практика запобігла не лише інциденту, але й пʼятничній кризі зі стейкхолдерами.

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

Покроково: як безпечно виправляти SPF у продакшені

1. Інвентаризуйте відправників. Перелічіть кожну систему, що надсилає пошту від вашого домену: корпоративний пакет, тикетинг, маркетинг, білінг, моніторинг, CRM, кастомні додатки і «таємні пристрої».
2. Зберіть реальні докази. Для кожного відправника зафіксуйте щонайменше одне доставлене повідомлення і запишіть:
   • Return-Path (envelope-from домен)
   • Підключений IP
   • Рядок Authentication-Results
3. Вирішіть стратегію ідентичностей. Віддавайте перевагу:
   • Одному-двом контрольованим піддоменам return-path для третіх сторін
   • DKIM, вирівняному з видимим From:
   • DMARC-політиці, що відповідає вашій впевненості
4. Побудуйте один SPF-запис на домен. Злийте записи. Видаліть мертвих постачальників. Уникайте ptr. Уникайте довгих ланцюгів include.
5. Порахуйте запити перед публікацією. Include-и розгортаються. Redirect-и рахуються. A/MX рахуються. Тримайте запас.
6. Плануйте TTL. Для планованих змін знижуйте TTL (наприклад, з 3600 до 300) щонайменше один TTL-цикл перед зміною. Після стабільності підніміть його назад.
7. Опублікуйте і перевірте на авторитетних NS. Переконайтеся, що кожен NS відповідає однаково.
8. Перевірте через кілька резолверів. Ви не налагоджуєте «свій DNS», ви налагоджуєте «погляд інтернету на ваш DNS».
9. Моніторте наслідки. Слідкуйте за причинами відмов, агрегованими сигналами DMARC, якщо вони є, і панелями доставки постачальників. Шукайте permerror і зростання softfail.
10. Перейдіть від ~all до -all за дедлайном. Встановіть дату. Призначте відповідального. Інакше softfail стане вашою постійною політикою.

Контрольний список перед додаванням нового include постачальника

• Чи знаємо ми envelope-from домен постачальника і чи може він бути кастомним під нашим доменом?
• Чи збереже цей include нас у межах 10 DNS-запитів у найгіршому випадку?
• Чи випадково ми не додаємо другий SPF-запис?
• Чи вирівняний і стабільний DKIM для цього потоку?
• Чи DMARC-енфорсмент не покарає нас негайно за помилки?
• Чи можемо швидко відкотитися (низький TTL, збережений попередній запис, готовий пайплайн змін)?

Контрольний список екстреного помʼякшення, коли SPF активно ламає доставку

• Припиніть робити паралельні зміни DNS з різних консолей. Один власник змін.
• Якщо існують кілька SPF TXT: обʼєднайте і видаліть дублі перш за все.
• Якщо permerror через запити: приберіть найновіший include і перевірте. Відновіть доставку, потім перерахуйте дизайн.
• Якщо зʼявився новий вихідний IP: тимчасово маршрутуйте трафік через відомий ретранслятор замість розширення SPF наосліп.
• Якщо DMARC відхиляє і ви не можете швидко виправити SPF: переконайтеся, що вирівняне DKIM-підписування працює для ураженого потоку (часто найшвидше обхідне рішення).

Поширені питання

1) Чи можу я мати кілька SPF-записів, якщо розбити їх у кілька рядків TXT?

Ви можете розбити один SPF-запис на кілька цитованих рядків всередині того самого TXT RRset (деякі провайдери DNS роблять це автоматично). Ви не можете публікувати кілька окремих TXT-записів, які кожен починається з v=spf1 для одного і того ж імені.

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

-all дає fail для несанкціонованих відправників; ~all дає softfail. Softfail означає «не авторизовано, але можливо прийняти». Деякі приймачі трактують softfail майже так само суворо, як fail, у поєднанні з поганою репутацією або сигналами DMARC.

3) Чому я бачу SPF pass, але мене все одно відкидають?

Бо SPF pass не гарантує DMARC pass. DMARC вимагає вирівнювання між From: доменом і SPF-автентифікованим envelope-from доменом (або вирівнювання DKIM). Також вас можуть відкинути через контент, репутацію, чорні списки або політики, не повʼязані з SPF.

4) Чи захищає SPF видимий заголовок From:?

Не напряму. SPF автентифікує envelope-from (Return-Path) домен. DMARC звʼязує автентифікацію (SPF/DKIM) з видимим заголовком From: через правила вирівнювання.

5) Як пересилання ламає SPF?

Класичне пересилання змінює підключений IP на IP пересилювача, але envelope-from залишається доменом початкового відправника. Якщо оригінальний SPF не авторизує IP пересилювача (зазвичай не авторизує), SPF провалюється. Ось чому DKIM важливий, і чому деякі пересилювачі впроваджують SRS (Sender Rewriting Scheme), щоб зберегти сумісність зі SPF.

6) Чи варто використовувати механізми «a» та «mx» в SPF?

Тільки якщо ви справді розумієте і контролюєте, до чого вони резолвляться. Вони коштують DNS-запитів і можуть ненавмисно авторизувати інфраструктуру, яка не повинна надсилати пошту. Для контрольованого виходу явні ip4/ip6 або відомий include-постачальника зазвичай безпечніші.

7) Що таке SPF «redirect» і чому це може бути небезпечно?

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

8) Скільки часу потрібно, щоб виправлення SPF «попрацювало»?

Залежить від TTL і кешування. У кращому випадку — хвилини, якщо TTL низький і резолвери співпрацюють. У гіршому — кілька годин. Деякі приймачі кешують агресивно. Плануйте зміни з урахуванням TTL і очікуйте хвіст поширення.

9) Чи достатній SPF сам по собі у 2026 році?

Ні. SPF сам по собі недостатній, бо він не витримує пересилання надійно і не автентифікує видимий From:. Використовуйте SPF разом з DKIM і DMARC. Розглядайте SPF як необхідний, але не достатній компонент.

10) Коли слід перейти від ~all до -all?

Після того як ви підтвердили, що всі легітимні відправники авторизовані, і маєте план відкату. На практиці: використовуйте ~all коротко під час виявлення, потім перемикайтеся на -all, коли інвентар відправників точний. Призначте дедлайн, щоб це дійсно сталося.

Висновок: наступні кроки, які можна виконати сьогодні

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

Зробіть це наступне:

1. Витягніть реальне невдале повідомлення і визначте return-path домен та IP відправника.
2. Запитайте авторитетний DNS і підтвердьте, що для цього домену існує рівно один TXT-запис з v=spf1.
3. Перевірте бюджет запитів; приберіть ризикові механізми і непотрібні include.
4. Вирівняйте ідентичності: використовуйте кастомні return-path піддомени для постачальників і забезпечте вирівнювання DKIM з вашим From: доменом.
5. Закріпіть контроль змін для SPF/DKIM/DMARC у пайплайні з лінтингом і відкатом.

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