SPF: Softfail (~all) чи Fail (-all) — оберіть налаштування, яке не підведе

Що таке SPF (і що ним не є): перестаньте звинувачувати не той інструмент

SPF (Sender Policy Framework) відповідає на одне вузьке запитання: чи дозволено цій IP-адресі надсилати пошту від імені цього домену в SMTP MAIL FROM / return-path?
І все. Він прямо не автентифікує заголовок «From:». Він не підтверджує особисту ідентичність відправника. І він однозначно не зупиняє фішера від того, щоб вписати ім’я вашого CEO у поле відображуваного імені.

SPF — це перевірка авторизації, яку виконує приймач, на основі IP відправника та DNS. Приймач оцінює SPF-запис для домену в
конверті відправника (envelope sender / bounce address), а не видимого заголовка From:. DMARC — це шар, який пов’язує SPF (і/або DKIM) з доменом у From: через вирівнювання.

Основні коди результату SPF, які ви справді бачите

• pass: надсилаюча IP-адреса авторизована.
• fail: явно не авторизована (зазвичай від -all).
• softfail: не авторизована, але «можливо» (зазвичай від ~all).
• neutral: немає твердження (часто від ?all або неоднозначних механізмів).
• none: запис SPF не знайдено.
• temperror: тимчасова проблема (тайм-аут DNS, SERVFAIL).
• permerror: постійна помилка оцінки (синтаксична помилка, надто багато DNS-запитів).

Операційний підводний камінь: приймачі трактують ці результати по-різному. SPF — це не універсальний «вимикач відхилення». Це сигнал.
Деякі системи ставляться до softfail майже як до fail; інші трактують fail як сильний індикатор спаму, але все одно доставляють. Ви не контролюєте приймача.
Ви контролюєте лише наскільки захищеним і однозначним є ваш сигнал.

Парафраз ідеї від Gene Kranz: «Твердий і компетентний». Це позиція, яку ви хочете для аутентифікації пошти: суворо там, де це допомагає, обережно там, де це ламає.

~all vs -all: що вони означають і як приймачі насправді їх трактують

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

• ~all (softfail): «Не авторизовано, але не карайте строго.» Приймачі часто приймають, але маркують або додають бали ризику.
• -all (fail): «Не авторизовано. Це явно неправильно.» Приймачі можуть відхиляти, поміщати до карантину або додавати великі штрафні бали.

Поведіка приймачів: неприємна правда

SPF fail не гарантує відхилення. SPF softfail не гарантує доставки. Приймачі комбінують SPF з репутацією, скануванням вмісту,
DKIM, DMARC, ARC, історичною поведінкою відправника і іноді тим, що їм продав їхній постачальник розвідданих цього кварталу.

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

Два великі режими відмов

1. Хибні негативи (ви блокуєте власну легітимну пошту).
   Поширені причини: постачальники, що не внесені в запис, SaaS-платформи з ротацією IP, шлюзи «scan-and-send», CRM-системи, системи тикетингу і
   класика: «ми змінили маршрутизацію вихідної пошти і забули про SPF».
2. Хибні позитиви (зловмисники отримують м’якший прийом).
   При ~all неавторизовані джерела отримують «м’яку» відмову. Багато приймачів доставляють, але в папку спаму. Деякі доставляють у вхідні, якщо інші сигнали виглядають добре.
   Це не перемога.

Жарт №1: SPF — як швейцар біля дверей з блокнотом. Якщо список невірний, VIP відштовхують, а порушник заходить у підробних вусах.

Моя категорична рекомендація (і коли її порушити)

Рекомендація за замовчуванням: переходьте на -all, коли маєте інвентар і моніторинг

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

Проте ви не просто «вмикаєте -all» за відчуттями. Робіть це коли:

• у вас є повний перелік джерел вихідної пошти (MTA, ретранслятори, SaaS-відправники, служби підтримки, маркетинг, зарплата, моніторинг),
• ви можете тестувати оцінку SPF з різних точок спостереження,
• у вас немає постійних permerror від SPF (ліміт запитів),
• у вас увімкнено DMARC-звіти і ви їх справді читаєте,
• у вас є план відкату (дисципліна TTL DNS, контроль змін).

Коли ~all виправданий

Використовуйте ~all тимчасово, якщо виконується хоча б одна з умов:

• ви ще виявляєте відправників і у вас немає DMARC-звітів;
• ваш бізнес покладається на форвардери або розсилки, де SPF ламається, і у вас немає покриття DKIM;
• ви успадкували домен з невідомими «shadow IT» відправниками і вам потрібне безпечне вікно для інвентаризації без негласного відкидання критичної пошти.

Підступ: «тимчасовий» ~all має звичку ставати постійним. Поставте дату. Призначте власника. Якщо не можете — ви обираєте дрейф.

Коли варто уникати обох і виправляти більшу проблему

Якщо ви намагаєтесь використати політику SPF для вирішення проблеми підробки заголовка From:, ви взяли не той ключ.
Це задача DMARC (а DKIM виконує більшість роботи для пересилань). Ваш SPF має бути точним і суворим,
але стратегія протидії спуфінгу — це SPF + DKIM + DMARC, а не лише SPF.

Факти та історія: чому SPF поводиться саме так

• SPF з’явився на початку 2000-х коли оператори намагалися зменшити підроблених відправників конвертів і знизити backscatter від відбитих повідомлень.
• Оцінка SPF прив’язана до SMTP-конверта (MAIL FROM / return-path), а не до видимого заголовка From:, який бачать люди.
• Ліміт у 10 DNS-запитів існує тому, що рання оцінка SPF могла навантажувати DNS і стати вектором відмови в обслуговуванні.
• Механізм ptr фактично виведено з практики, бо він повільний, крихкий і може бути зловживаний через контроль DNS.
• SPF «ламається» при пересиланні за конструкцією: форвардер змінює IP-відправника, але зазвичай не переписує return-path на домен, яким він володіє.
• DKIM введено частково через пересилання: криптографічний підпис переживає транзит, якщо проміжні ланки не змінюють підписані заголовки.
• DMARC з’явився пізніше, щоб зв’язати результати автентифікації з видимим доменом From: і надати політику та звітування.
• ARC (Authenticated Received Chain) існує тому, що суворий DMARC може порушити легітимні пересилки (списки розсилки, шлюзи), і приймачі хотіли спосіб довіряти проміжним ланкам.
• Великі приймачі трактують автентифікацію як вхід для репутації, а не як бінарний фільтр, бо зловмисники швидко адаптуються, а помилкові відхилення дорогі.

Швидкий план діагностики: знайдіть вузьке місце за лічені хвилини

Коли доставка пошти починає дивно поводитись після зміни SPF, треба припинити гадати. Ось порядок дій, який швидко знайде проблему.

Спочатку: підтвердьте, який SPF-запис бачить світ

• Запитуйте авторитетні або публічні резолвери (не лише кеш вашого ноутбука).
• Переконайтеся, що існує рівно один SPF TXT-запис (або принаймні не кілька записів зі «v=spf1»).
• Перевірте TTL; можливо, ви женетесь за привидами пропагації.

Друге: підтвердьте, який IP фактично надсилає

• Використайте заголовки Received з прикладного повідомлення, щоб ідентифікувати IP, що підключався до отримувача.
• Не плутайте внутрішні хопи з зовнішнім handoff IP.
• Перевірте, чи постачальник надсилає напряму, чи через ваш релей.

Третє: оцініть SPF і порахуйте DNS-запити

• Запустіть оцінювач SPF (або розпарсуйте логи, якщо ви приймач).
• Шукайте permerror (забагато запитів) або temperror (помилки DNS).
• Перевірте include та redirect; вони множать запити.

Четверте: перевірте вирівнювання DMARC і покриття DKIM

• Якщо проблема — «підробка», DMARC — це політика управління.
• Якщо проблема — «пересилання», DKIM — ваш рятівник.
• Якщо у вас є примусовий DMARC без DKIM-покриття, ви створили пастку для себе.

П’яте: вирішіть негайну дію

• Якщо бізнес-пошта заблокована: відкатіть зміну SPF (або тимчасово пом’якште) і відкрийте інцидент для повної інвентаризації відправників.
• Якщо підробка проходить: загостріть SPF до -all і рухайте DMARC у бік quarantine/reject, коли DKIM стабільний.
• Якщо permerror: зменшіть кількість запитів, спростіть запис або переведіть відправників за контрольований релей.

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

Це не «приємні додатки». Це ручки, які ви вертіте о 2:00 ночі, коли відділ продажів каже, що пропозиції зникли.
Кожне завдання містить: команду, що означає її вивід, і рішення, яке ви приймаєте.

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

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"
"google-site-verification=abc123"

Значення: Існує один SPF-запис (добре). Інший TXT не пов’язаний. Якщо ви бачите два окремі рядки, що починаються з v=spf1,
багато приймачів трактуватимуть це як permerror.

Рішення: Якщо є дублікати — об’єднайте в один SPF-запис негайно.

Завдання 2: Перевірити запис як бачать конкретні резолвери (пропагація)

cr0x@server:~$ dig @8.8.8.8 +short TXT example.com
"v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Значення: Публічний резолвер бачить очікуване значення.

Рішення: Якщо різні резолвери розходяться — не «ліпіть» SPF знову; зачекайте TTL або знайдіть проблеми зі split-horizon DNS.

Завдання 3: Перевірити TTL, щоб оцінити радіус впливу

cr0x@server:~$ dig TXT example.com +noall +answer
example.com.        3600    IN      TXT     "v=spf1 ip4:203.0.113.0/24 include:_spf.vendor.example ~all"

Значення: TTL — 3600 секунд. У гіршому випадку кеші зберігатимуть старі дані близько години.

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

Завдання 4: Підтвердити IP відправника з заголовка received (сироватка правди)

cr0x@server:~$ grep -iE '^(received: from|authentication-results:)' sample.eml | head
Received: from outbound.vendor.example (outbound.vendor.example [198.51.100.77])
Authentication-Results: mx.receiver.example; spf=softfail (example.com: domain of bounce@example.com does not designate 198.51.100.77 as permitted sender)

Значення: Приймач оцінив SPF для example.com, і підключаючий IP був 198.51.100.77.

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

Завдання 5: Оцінити SPF локальним інструментом (швидко і грубо)

cr0x@server:~$ spfquery -ip 198.51.100.77 -sender bounce@example.com -helo outbound.vendor.example
fail

Значення: Для домену envelope sender ця IP-адреса не авторизована.

Рішення: Не змінюйте -all на ~all, щоб «полагодити» це. Виправте список авторизації або шлях надсилання.

Завдання 6: Оцінити ризик кількості DNS-запитів при інспекції SPF (виявити кандидати на permerror)

cr0x@server:~$ dig +short TXT example.com
"v=spf1 include:_spf.a.example include:_spf.b.example include:_spf.c.example include:_spf.d.example -all"

Значення: Кожне include може спричинити кілька запитів. Ви швидко можете досягти 10.

Рішення: Якщо підходите до ліміту — консолідуйте відправників за релей або акуратно спростіть запис (див. Завдання 9/10).

Завдання 7: Виявити SPF permerror (забагато DNS-запитів) через логи приймача (приклад Postfix)

cr0x@server:~$ sudo grep -i spf /var/log/mail.log | tail -5
Jan  4 11:02:18 mx postfix/smtpd[22190]: NOQUEUE: reject: RCPT from unknown[203.0.113.55]: 550 5.7.1 SPF permerror; too many DNS lookups; from=<bounce@example.com> to=<user@receiver.example> proto=ESMTP helo=<sender.example>

Значення: Оцінка SPF завершилась постійною помилкою. Деякі приймачі відхиляють при permerror, інші трактують як neutral; у будь-якому випадку це недбало.

Рішення: Зменшіть includes/redirects. Розглядайте permerror як стан аварії для доставлянності.

Завдання 8: Підтвердити, що ви не опублікували два SPF-записи (класичне самопідривання)

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

Значення: Існує два SPF-записи. Багато приймачів повернуть permerror.

Рішення: Зливайте негайно в один запис. Потім перевірте з кількома резолверами.

Завдання 9: Витягнути і перевірити include-цілі (ви залежите від зламаного постачальника?)

cr0x@server:~$ dig +short TXT _spf.vendor.example
"v=spf1 ip4:198.51.100.0/24 ip4:203.0.113.128/25 -all"

Значення: Постачальник публікує чистий SPF з явними IP-діапазонами і -all.

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

Завдання 10: Перевірити використання redirect (і зрозуміти радіус впливу)

cr0x@server:~$ dig +short TXT mail.example.com
"v=spf1 redirect=example.com"

Значення: SPF субдомену повністю делеговано політиці апексу.

Рішення: Якщо вам потрібні різні відправники для субдоменів (маркетинг проти транзакційних), уникайте redirect і задавайте явно.

Завдання 11: Перевірити наявність DKIM для відправника, який буде пересланий (SPF-резистентність)

cr0x@server:~$ grep -i '^dkim-signature:' sample.eml | head -1
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=from:to:subject:date; bh=...; b=...

Значення: Повідомлення підписане DKIM від example.com. Це може пережити пересилання і зберегти вирівнювання DMARC навіть коли SPF не проходить.

Рішення: Якщо пересилка критична — пріоритет DKIM над спробами «змушувати» SPF працювати через форвардери.

Завдання 12: Запитати політику DMARC (бо суворість SPF сама по собі — не суть)

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

Значення: DMARC встановлено на quarantine і вимагає суворого вирівнювання для DKIM і SPF.

Рішення: Якщо у вас немає повного DKIM-покриття для всіх легітимних відправників, суворе вирівнювання плюс SPF fail може спричинити біль для користувачів. Спочатку виправте конфіги відправників.

Завдання 13: Перевірити симптоми вирівнювання в Authentication-Results

cr0x@server:~$ grep -i '^authentication-results:' sample.eml | head -1
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.example.com; dkim=pass header.d=example.com; dmarc=fail header.from=example.com

Значення: SPF пройшов для bounce.example.com, DKIM пройшов для example.com, але DMARC не пройшов для header.from=example.com.
Це невідповідність вирівнювання: домени не узгоджені згідно DMARC.

Рішення: Вирівняйте домен envelope sender з From доменом (або пом’якшіть вирівнювання) і забезпечте, щоб DKIM використовував домен From там, де можливо.

Завдання 14: Визначити, хто надсилає від вашого імені (приклад логів Postfix outbound)

cr0x@server:~$ sudo grep -E 'status=sent|relay=' /var/log/mail.log | tail -5
Jan  4 10:55:01 mta postfix/smtp[21011]: 1A2B3C4D: to=<user@outside.example>, relay=aspmx.l.google.com[142.250.102.27]:25, delay=1.2, status=sent (250 2.0.0 OK)
Jan  4 10:56:44 mta postfix/smtp[21022]: 5E6F7A8B: to=<user@outside.example>, relay=mail.protection.outlook.com[52.101.73.5]:25, delay=0.9, status=sent (250 2.6.0 Queued mail for delivery)

Значення: Ви бачите кінцеві точки вихідної доставки, але також можете зробити висновок, чи надсилаєте напряму, чи через смарт-хост.

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

Завдання 15: Перевірити ваш публічний egress IP (сюрпризи cloud NAT)

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

Значення: Екземпляр має egress IP 203.0.113.55 з точки зору Інтернету.

Рішення: Переконайтеся, що ця IP або NAT-діапазон авторизовані в SPF, якщо вони можуть надсилати пошту напряму. Якщо IP змінюється, перестаньте надсилати напряму; використовуйте стабільний релей.

Три корпоративні міні-історії з поля бою

1) Інцидент через неправильне припущення: «Постачальник використовує наш релей»

Середня компанія мала внутрішній SMTP-relay і акуратний SPF-запис: один IP-діапазон, одне include, -all.
Вони також підключили нову HR-платформу, яка надсилала листи з онбордингу. Усі вірили, що платформа налаштована надсилати через релей.
В адмінці навіть було написано «SMTP configured», речення, яке ввело в оману більше людей, ніж будь-яка фішингова розсилка.

Першим симптомом не був bounce. Це було мовчання. Нові працівники не отримували посилань для онбордингу, менеджери не отримували затверджень,
і HR думав, що «додаток лагає». Тим часом деякі зовнішні отримувачі все ж отримали повідомлення — але в спамі.
Різні приймачі — різна поведінка. Ось таке життя SPF.

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

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

2) Оптимізація, що відбилася боком: «Зрівняємо SPF заради продуктивності»

Інша організація накопичила SPF-запис як шухляду з мотлохом: шість includes, два ip4 блоки і redirect для субдомену.
Їх налякав ліміт у 10 запитів і вони вирішили «зрівняти» все — скопіювати IP-діапазони постачальників прямо в запис.
Це подавалось як «покращення продуктивності» і «стійкості», бо прибирало залежності від DNS постачальників.

Зрівнювання спрацювало місяць. Потім доставність стала хиткою. Маркетингова платформа почала використовувати новий пул IP,
і оскільки організація заморозила старі діапазони у своєму SPF, ці повідомлення почали провалюватись SPF. Деякі приймачі поміщали в карантин; деякі відхиляли.
Include постачальника оновився коректно, але організація відмовилась від цього потоку оновлень.

Режим відмови був тонкий: внутрішнє тестування все ще «проходило», бо інженери тестували з одного регіону і від одного відправника.
У продакшні постачальник маршрутизував через різні egress IP залежно від географії і навантаження. Зрівняний SPF став застарілим знімком,
і організація випадково взяла на себе зобов’язання щодо життєвого циклу IP постачальника.

Вони відкотились назад до includes для постачальників, які підтримують їх добре, і використовували зрівнювання лише для джерел, якими володіють самі.
Більшою зміною став процес: onboarding постачальників тепер вимагав або (a) стабільний include з практикою публікації змін, або (b) маршрутизацію через корпоративний релей.
Оптимізація — це чудово, поки вона не змінює те, хто відповідає за її правильність.

3) Нудна, але правильна практика, що врятувала положення: поетапна суворість з DMARC-звітуванням

Фірма з фінансових послуг вела дисципліновану програму аутентифікації пошти. Не захопливо. Дуже ефективно.
Вони почали зі SPF ~all на старому домені, бо справді не знали всіх відправників. Замість здогадок вони інструментували процес.
DMARC був встановлений на p=none з увімкненим звітуванням, і команда безпеки переглядала агреговані звіти щотижня.

Вони знайшли звичні сюрпризи: система моніторингу, що надсилала alertи «disk full» напряму з colo IP, регіональний принтер з аутентифікацією SMTP,
і невеликий SaaS-інструмент білінгу, про який ніхто не повідомив центральний IT. Жодне з цього не було зловмисним — просто безгосподарне.
Звіти зробили їх видимими, що й має робити хороша телеметрія: загадки перетворюються на тікети.

Після того, як вони вирівняли або замінили ці джерела, переключили SPF на -all і DMARC на p=quarantine.
Лише потім вони підняли до p=reject для основного домену, субдомени оброблялися окремо.
Коли зловмисник спробував базову кампанію підробки, більшість приймачів відхилили її чисто. Внутрішні команди ледве помітили.

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

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

1) Повідомлення раптово потрапляють у спам після переходу з ~all на -all

Симптом: Легітимні транзакційні листи почали потрапляти в спам/карантин у великих провайдерів.

Корінна причина: Один або декілька легітимних відправників так і не були авторизовані; softfail дозволяв їх проходити, fail — ні.

Виправлення: Ідентифікуйте IP відправників з заголовків або логів, авторизуйте через ip4/ip6 або include, або маршрутизуйте через відомий релей. Потім заново протестуйте SPF і вирівнювання DMARC.

2) Випадкові приймачі відхиляють з “SPF permerror”

Симптом: Деякі отримувачі відхиляють з 5.7.1 і згадують permerror або «too many DNS lookups».

Корінна причина: Ваш SPF перевищує 10 DNS-запитів через includes/redirect/a/mx механізми.

Виправлення: Зменшіть кількість запитів: видаліть невживані includes, уникайте a/mx, якщо не потрібно, консолідуйте відправників або використайте релей. Перевірте дублікати та синтаксис.

3) SPF проходить, але DMARC не проходить (і ви не можете пояснити чому)

Симптом: Authentication-Results показує spf=pass, але dmarc=fail.

Корінна причина: SPF пройшов для неузгодженого домену конверта (наприклад, домен bounce постачальника), а DKIM відсутній або неузгоджений.

Виправлення: Забезпечте DKIM-підписування з вашим доменом у From, або вирівняйте envelope sender; змінюйте налаштування вирівнювання DMARC лише після розуміння компромісів.

4) Переслані листи провалюють SPF і блокуються після жорсткого DMARC

Симптом: Співробітники, що пересилають пошту на персональні акаунти (або партнерам), бачать відмови/карантин.

Корінна причина: Форвардери ламають SPF; примусовий DMARC покладається на те, що DKIM пройде і буде вирівняний, чого може не бути.

Виправлення: Покращте покриття DKIM для вихідної пошти; розгляньте ARC-освідомлені отримувачі та практики списків/пересилань. Не покладайтеся на SPF для форвард-шляхів.

5) Ви опублікували «v=spf1» як кілька TXT-чанків і деякі системи читають неправильно

Симптом: Періодичні збої SPF; різні інструменти показують різні рядки запису.

Корінна причина: Довжина запису/проблеми з лапками або множинні записи; деякі DNS-інтерфейси неправильно розбивають рядки.

Виправлення: Переконайтесь, що є рівно один TXT RRset для SPF і що він є коректним SPF-рядком. Валідируйте через dig і локальний оцінювач.

6) Постачальник каже використовувати «+all» або «?all», щоб уникнути проблем

Симптом: Підтримка постачальника радить послабити SPF, щоб «вирішити доставку».

Корінна причина: Вони не можуть (або не хочуть) надати стабільну авторизацію відправлення і пропонують вам прийняти все.

Виправлення: Не робіть цього. Маршрутизуйте через ваш релей або вимагайте DKIM-підписування вашим доменом і коректної include-стратегії. Якщо не можуть — перегляньте співпрацю з постачальником.

Чеклісти / покроковий план

Крок-за-кроком: безпечний шлях від ~all до -all

1. Інвентаризуйте відправників: перераховуйте всі системи, що надсилають від вашого домену (люди + додатки + пристрої + постачальники).
2. Увімкніть DMARC-звіти з p=none, якщо ще не маєте; призначте власника для щотижневого перегляду звітів.
3. Підтвердьте покриття DKIM для кожного відправника, де це можливо: маркетинг, тикетинг, виставлення рахунків, HR тощо.
4. Виправте вирівнювання: переконайтесь, що DKIM d= і/або SPF return-path вирівняні з From згідно ваших налаштувань DMARC.
5. Очистіть SPF: один запис, без мертвих includes, уникайте ptr, мінімізуйте a/mx.
6. Перевірте бюджет запитів: тримайте запас під лімітом 10. Не працюйте на 9/10 і не брешіть самому собі.
7. Знизьте TTL заздалегідь (24–48 годин) перед переходом на -all, щоб відкат був реалістичним.
8. Розгорніть поетапно: застосуйте -all спочатку на менш критичних субдоменах або в пілоті, якщо можете.
9. Моніторьте: стежте за відскоками, відгуками приймачів і DMARC-звітами принаймні повний бізнес-цикл (тиждень+).
10. Переключіться на -all і документуйте список відправників як живий артефакт, пов’язаний з onboarding/offboarding постачальників.

Операційний чекліст: перед зміною SPF у DNS

• Чи знаємо ми всі легітимні шляхи надсилання, включно з «малими» інструментами (алерти, принтери, старі додатки)?
• Чи маємо план відкату і недавню копію попереднього TXT-запису?
• Чи достатньо низький TTL, щоб відкат мав значення?
• Чи перевірили ми, що сьогодні є рівно один SPF-запис?
• Чи не підштовхне ця зміна нас до ліміту 10 запитів?
• Чи ми застосовуємо DMARC? Якщо так, чи DKIM вирівняний для основних відправників?
• Хто відповідальний за обробку питань доставності в наступні 24–48 годин?

Рубрика прийняття рішення: що варто опублікувати сьогодні

• Публікуйте -all, якщо: інвентар відправників точний, DKIM широко впроваджено, DMARC-звіти читаються, і ви контролюєте або можете обмежити відправників.
• Публікуйте ~all, якщо: ви активно виявляєте відправників з обмеженим терміном на виконання плану і можете терпіти те, що деяка підробка отримує м’якший рейтинг.
• Не «вирішуйте» проблеми постачальників з ?all або +all. Це не політика; це капітуляція.

Жарт №2: Змінювати SPF, не перевіривши вирівнювання DMARC — це як затягувати гайки на машині з трьома колесами. Технічно ви щось зробили.

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

1) Чи гарантує -all, що приймачі відхилять неавторизовану пошту?

Ні. Це сигнал «fail», але рішення за приймачем. Багато відхилить, деякі помістять у карантин, деякі все ще доставлять, але з великим штрафом.
Ваш контроль — точність і суворість сигналу, плюс політика DMARC і DKIM.

2) Чи безпечніше ~all, бо воно не зламає легітимну пошту?

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

3) Ми використовуємо кілька постачальників. Чи просто додати всі їхні includes?

Іноді так. Але includes множать запити і у вас є жорсткий ліміт. Якщо стекуєте постачальників, краще маршрутизувати вихідну пошту через центральний релей під вашим контролем і авторизувати лише його в SPF.

4) Чому пересилання ламає SPF?

SPF перевіряє IP підключення щодо SPF-запису домену envelope sender. Форвардер змінює підключаючий IP, але зазвичай зберігає оригінальний envelope sender.
Результат: неавторизований IP, SPF провалюється. DKIM може пережити пересилання і врятувати вирівнювання DMARC, якщо налаштовано коректно.

5) Використовувати include чи вказувати IP-діапазони напряму?

Використовуйте include, коли постачальник його добре підтримує і змінює IP. Вказуйте IP напряму, коли ви ними володієте і контролюєте.
Зрівнювання IP постачальника у ваш SPF робить вас відповідальними за відслідковування їхнього churn, на що ви, ймовірно, не заклали ресурсів.

6) Що гірше: temperror чи permerror?

На практиці permerror гірше, бо це постійна помилка конфігурації (синтаксис, кількість записів, ліміт запитів).
Temperror може бути періодичним (відмови DNS), але на масштабі теж шкодить доставці. Обидві причини — привід спростити і зміцнити DNS.

7) Чи можу я використати SPF, щоб зупинити підробку мого From: адреси?

Не надійно. SPF автентифікує домен envelope sender. Зловмисник може вибрати envelope домен під своїм контролем, підробляючи видимий From:.
DMARC — те, що зв’язує автентифікацію з доменом у From:. Використовуйте SPF як частину набору, а не як єдине рішення.

8) У нас DMARC встановлено на reject. Чи означає це, що SPF має бути -all?

Не обов’язково. DMARC може пройти через DKIM, навіть якщо SPF провалюється. Але якщо покриття DKIM неповне, суворість SPF раптом набуває великого значення.
Якщо ви примушуєте DMARC, спочатку будьте впевнені в DKIM, потім робіть SPF суворим і точним.

9) Що з субдоменами — чи мають вони успадковувати SPF апексу?

Тільки якщо набір відправників дійсно ідентичний. Маркетингові платформи і продуктові системи часто використовують субдомени не випадково. Якщо делегувати все на апекс,
ви можете випадково авторизувати відправників там, де не слід, або зламати легітимних відправників субдомену.

10) Як дізнатись, чи перехід на -all мені відгукнеться боляче?

Якщо ви не можете відповісти «які всі легітимні IP/домени відправників?» і «чи вони DKIM-підписують вирівняно?» з доказами (логи, заголовки, DMARC-звіти),
ви не готові. Використовуйте ~all тимчасово, інструментуйте, виправляйте, а потім переходьте на -all поетапно.

Висновок: що робити далі

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

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

1. Запустіть DNS-перевірки вище й підтвердьте, що маєте рівно один SPF-запис і розумний TTL.
2. Зберіть заголовки з реальних листів і запишіть фактичні підключаючі IP для кожної системи відправника.
3. Виправте DKIM і вирівнювання DMARC для основних відправників, особливо для того, що пересилається.
4. Зменшіть складність SPF-запитів, поки це не перетвориться на рулетку permerror.
5. Перейдіть на -all поетапно, моніторячи щонайменше тиждень реального трафіку.

Мета не опублікувати страшний запис. Мета — опублікувати запис, який ви зможете захистити о 2:00 ночі за допомогою логів, заголовків і плану відкату.
Саме так ви не допустите, щоб аутентифікація пошти перетворилась на випадкову відмову в обслуговуванні для вашого бізнесу.