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

Давайте розберемо, що тут насправді має значення. SPF (Sender Policy Framework) — це в основному ваш домен, який повідомляє приймальним серверам: ось мій DNS TXT-запис, у якому перераховані хости, що можуть легально надсилати пошту від мого імені. Коли надходить лист, отримувач перевіряє ваш SPF-запис щодо домену Return-Path, оцінює ваші механізми (ip4, ip6, a, mx, include) і приймає рішення, що робити. Це рішення залежить від одного: вашого кваліфікатора наприкінці — режиму, який ви обираєте.

Ось основна різниця, яка вводить в оману людей. Softfail (~all) означає «це виглядає неавторизованим, але можливо, все гаразд — діяти обережно». Зазвичай його використовують для спам-фільтрації, а не для повного відхилення. Hardfail (-all) означає «тільки ті хости, що я перерахував, є легальними — все інше блокую». Це однозначно, і коли це поєднується з DMARC, ви отримуєте справжнє відхилення повідомлень.

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

Практичний підхід, який я застосовую, — це систематичний процес: починаю з ?all для чистого спостереження, переходжу до softfail (~all), коли починаю отримувати зведені звіти DMARC, і лише потім переключаюся на hardfail (-all), коли підтвердив усіх авторизованих відправників і кількість хибних спрацьовувань близька до нуля. Я ніколи не поспішаю. Я роблю інвентаризацію всього — CRM, автоматизація маркетингу, квитки, HR, білінг, навіть дивні речі, як принтери. Підтверджую, які постачальники підтримують DKIM і DMARC. Документую, хто відповідає за кожну зміну.

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

Пересилання — ще один підводний камінь. Воно порушує SPF, оскільки IP-адреса з’єднання змінюється. Якщо пересилання використовує SRS (Sender Rewriting Scheme), все гаразд. Якщо ні — softfail може бути єдиним захистом від випадкових помилок. Тому я більше покладаюся на DKIM і DMARC для таких шляхів.

Мій удосконалений чекліст розгортання: картографуйте всі поштові сервери та робочі процеси, перевіряйте DKIM скрізь, увімкніть DMARC у політиці p=none для збору телеметрії, переводьте SPF у режим softfail і спостерігайте хоча б два цикли відправки, досліджуйте кожного неавторизованого відправника і або авторизуйте його, або припиніть потік, а потім поступово впроваджуйте політику reject з enforcement DMARC, перш ніж перейти до hardfail. Останній крок — перехід до hardfail лише після повної перевірки легітимності відправників — є обов’язковим.

Ще одне, що я помітив: Google і Yahoo значно посилили свої стандарти. Відповідність поштової політики тепер поєднує режим SPF, підпис DKIM, політику DMARC, аналіз контенту та репутаційний рейтинг. Тому я ніколи не розглядаю SPF ізольовано. Hardfail без надійної підтримки DKIM може все одно погіршити доставку, якщо у вас поширене пересилання.

Найбільші помилки, які я бачу: вкладати include, доки не перевищите ліміт у 10 запитів; забувати сезонних постачальників, що надсилають від імені вашого домену; думати, що DMARC врятує зламаний SPF; довго покладатися на softfail, поки зловмисники адаптуються; або переходити до hardfail, не маючи повного покриття легітимних відправників. Особливо останнє — добре для безпеки, але погано для доставляємості, якщо багато пересилань.

Якщо зараз у вас softfail і ви сумніваєтеся, чи варто переходити — відповідь: тільки коли будете готові. Ви підтвердили всіх відправників? DKIM у порядку? Хибні спрацьовування близькі до нуля? Якщо так — перехід до hardfail має сенс. Якщо ні — залишайтеся терплячими. Softfail — це не назавжди, а контрольна точка.