Я узнал о 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 друг в друга так глубоко, что достигают этого лимита, и всё ломается. Уменьшайте вложения, предпочтите диапазоны IP вместо вложенных цепочек и удаляйте неиспользуемые сервисы. Если массовый отправитель постоянно меняет IP, требуйте у них стабильный include с SLA.

Пересылка — ещё одна ловушка. Она ломает SPF, потому что IP-адрес соединения меняется. Если пересылка использует SRS (Sender Rewriting Scheme), всё в порядке. Если нет — softfail может стать единственной преградой для дружественного взаимодействия. Поэтому я больше полагаюсь на DKIM и DMARC для таких случаев.

Реальный чек-лист внедрения, который я усовершенствовал со временем: картировать все почтовые серверы и рабочие процессы, валидировать DKIM везде, включить DMARC с p=none для сбора телеметрии, перевести SPF в режим softfail и наблюдать минимум два цикла отправки, исследовать все неавторизованные отправители и либо разрешить их, либо отключить поток, затем поэтапно внедрять политику reject с принудительным DMARC, прежде чем перейти на hardfail. Этот последний шаг — переход на hardfail только после полного покрытия легитимных отправителей — обязательен.

Ещё заметил: Google и Yahoo значительно ужесточили свои стандарты. Политика обработки почты теперь включает режим SPF, подписи DKIM, политику DMARC, анализ содержимого и оценку репутации. Поэтому я никогда не рассматриваю SPF изолированно. Hardfail по SPF без надёжной поддержки DKIM всё равно может негативно сказаться на доставляемости, если в вашей среде часто используют пересылку.

Самые распространённые ошибки: вложение include до превышения лимита в 10 DNS-запросов, забывание сезонных поставщиков, которые отправляют от вашего домена, полагание, что DMARC спасёт при неправильной настройке SPF, постоянное использование softfail, пока злоумышленники не адаптируются, или переход на hardfail до того, как DKIM полностью внедрён. Особенно последний — хорошо для безопасности, плохо для доставляемости при частой пересылке.

Если сейчас у вас softfail и вы думаете, стоит ли переходить — ответ: только когда будете готовы. Проверили ли вы всех отправителей? Совпадает ли DKIM? Количество ложных срабатываний близко к нулю? Если да, то переход на hardfail имеет смысл. Если нет — оставайтесь терпеливы. Softfail — это не навсегда, а контрольная точка.