SPF Flattening: как оптимизировать DNS-записи и не сломать доставляемость писем

SPF flatten: когда ускорять доставку, а когда ловить спуф

Для тех, кто ведёт рассылки и ловит падение опенрейтов из-за непроходящей аутентификации, разбор особенно ценен: он чётко показывает, в каких случаях flatten спасает доставляемость, а в каких сам становится источником проблем.

Что такое flatten и зачем он вообще нужен

SPF проверка по RFC 7208 ограничена десятью DNS-запросами за одну оценку: в лимит входят include, a, mx, ptr, exists и redirects. Как только запись переваливает за порог, получатель останавливает проверку и помечает письмо как SPF=fail — даже если отправитель полностью легитимный. Flatten по сути сжимает цепочку: вместо include:_spf.vendor1.com, include:_spf.vendor2.com и так далее в TXT-запись вписываются конкретные IPv4/IPv6. Меньше DNS-lookup'ов — быстрее проходит проверка, меньше шанс словить таймаут на стороне ESP.

Имеет смысл, если SPF-запись близка к лимиту или уже за ним, а все авторизованные адреса стабильны — например, выделенный почтовый шлюз или фиксированный релей с известным пулом IP.

Где flatten убивает доставляемость

Опасный сценарий — крупные ESP, рассыльщики и CDN, которые регулярно меняют свои пулы. Вы сплющили запись вчера, а сегодня вендор выкатил новые IP — ваша SPF-проверка падает, хотя include отслеживал бы изменения автоматически. Для проектов с динамической инфраструктурой логичнее использовать инструменты динамического SPF-менеджмента: они мониторят vendor include и подтягивают свежие адреса без ручной правки DNS. Часть таких платформ также даёт алерты и дашборды для отслеживания проблем до того, как они ударят по проду.

Чек-лист на ближайшие выходные

Прежде чем что-то сплющивать — аудит. Без него любые оптимизации превращаются в русскую рулетку с доставляемостью. Порядок действий:

• выгрузить текущую SPF-запись и посчитать количество механизмов с DNS-запросами;
• составить список всех отправителей: свои серверы, ESP, CRM, транзакционные шлюзы, формы на лендингах;
• проверить для каждого источника поддержку SPF alignment (MAIL FROM / return-path совпадает с header From) и DKIM alignment — без него DMARC не закроет;
• выделить источники со стабильными IP — их сплющивать в первую очередь;
• для источников с ротацией IP оставить include или перевести на динамический SPF-менеджмент;
• зафиксировать baseline по опенрейту, кликрейту и bounce rate до правок и сравнить через 7–10 дней после.

DKIM в этой связке перевешивает SPF при пересылках, поэтому если раньше откладывали его внедрение — повод наконец закрыть. Кстати, параллельно полезно следить за трендами в контенте и вирусных форматах — например, в ежедневных трендах соцсетей хорошо видно, какие приёмы в тексте и визуале сейчас заходят аудитории; эти наблюдения напрямую пригодятся для сегментации и прогрева базы.

Главный вывод простой: flatten — это не «хорошая практика» сама по себе, а инструмент под конкретный профиль инфраструктуры. Стабильные IP — сплющиваем, динамические вендоры — оставляем include или подключаем автообновление. Всё остальное — деньги на ветер и риск для репутации домена.