Глобальная проверка валидации SPF
Sender Policy Framework (SPF) — это критически важный протокол аутентификации электронной почты, который предотвращает спуфинг (подделку) домена путем публикации криптографического белого списка (whitelist) авторизованных IP-адресов для отправки. Хотя сам протокол SPF имеет важное значение для современной доставляемости писем, выделенный тип DNS-записи SPF (Type 99) имеет невероятно запутанную историю и официально устарел.
Взлет и падение Record Type 99
Когда протокол SPF был изначально концептуализирован (RFC 4408), IETF разработала специальную ресурсную запись DNS (Type 99), явно предназначенную для изоляции SPF Payload от стандартных данных TXT. Теория заключалась в том, что сохранение выделенного типа записи ускорит парсинг резолвера. Однако внедрение обернулось масштабным провалом. Устаревшие DNS-серверы, брандмауэры и аппаратные балансировщики нагрузки не распознавали новый синтаксис Type 99 и часто отбрасывали пакеты, вызывая повсеместные сбои электронной почты. Признав эту аппаратную несовместимость, IETF опубликовала RFC 7208, который официально объявил устаревшей запись Type 99. Сегодня все конфигурации SPF должны публиковаться как стандартные записи TXT. Если администратор продолжит развертывать устаревшую SPF-запись Type 99, современные платформы, такие как Microsoft Exchange и Google Workspace, полностью проигнорируют ее, что приведет к немедленным сбоям DMARC.
Механический лимит в 10 запросов (10-Lookup Limit)
Самой заметной точкой технического сбоя для разработчиков, управляющих SPF, является строгий порог в 10 DNS lookups (поисков). Поскольку запись SPF позволяет администраторам вкладывать другие политики домена с помощью директивы include: (например, include:_spf.salesforce.com), принимающий почтовый сервер должен выполнить рекурсивный DNS-запрос, чтобы получить IP-адреса от этого стороннего провайдера. Чтобы защитить MTA от бесконечных циклов маршрутизации и целевых атак усиления DDoS, протокол жестко ограничивает выполнение 10 рекурсивными запросами DNS. Если компания объединяет слишком много провайдеров SaaS и достигает 11 запросов, выполнение останавливается, возвращая SPF "PermError". Это мгновенно приводит к тому, что легитимные исходящие электронные письма получают жесткий отказ (hard-bounce) или попадают в карантин.
Flattening (сглаживание) и диагностика
Чтобы обойти ограничения на количество запросов, сетевые инженеры используют инструменты "SPF Flattening". Эти скрипты выполняются ежечасно, разворачивая все директивы include: через API, удаляя имена хостов и компилируя сырые блоки IPv4/IPv6 в одну массивную плоскую (flat) запись TXT. Использование глобального диагностического чекера гарантирует, что ваш синтаксис верен, ваши вложенные include не превысили молча порог DNS, а ваша политика явно завершается строгим флагом -all (fail) или ~all (softfail) для отклонения поддельных Payload.