<b>SPF ломается не на DNS, а на первой же пересылке и пересечении лимитов</b>

<b>SPF ломается не на DNS, а на первой же пересылке и пересечении лимитов</b>

SPF — это не «галочка в DNS», а механизм проверки, может ли этот сервер отправлять письма от вашего домена. Если в записи нет нужного сервера, проверка падает. Если запись слишком длинная и начинает собираться из нескольких include, вы уже живёте на грани лимита в 10 DNS-lookups.

Из источника: типовые поломки SPF почти всегда одинаковые:
— забыли обновить запись после подключения нового сервиса;
— оставили старый include от выключенного инструмента;
— поставили несколько SPF-записей вместо одной;
— загнали всё подряд в include и словили <code>permerror</code>;
— не учли, что пересылка часто ломает выравнивание и делает SPF бесполезным для части цепочки.

Что важно: SPF проверяет не «кто написал письмо», а сервер, который его физически отправил. Поэтому для подписчиков и внутренних маршрутов он работает, а для пересылок и некоторых relay-сценариев — уже нет. Отсюда и вечная путаница: письмо «от нашего домена», а SPF всё равно fail.

Что делать на практике:
— держать одну SPF-запись на домен;
— пересчитать все include, ip4/ip6 и redirect;
— проверять, не превышен ли лимит lookup;
— удалять всё, что больше не отправляет;
— после любого подключения ESP сразу обновлять запись.

SPF нужен не сам по себе, а вместе с DKIM и DMARC. Если оставить его «как-нибудь потом», потом обычно и прилетает.