Defaults.Exposed › Отчёты

Почему мой SPF не работает? Проблема 10 запросов SaaS для отправителей в Великобритании и ЕС (2026)

Опубликовано 2026-07-09

Данные по состоянию на 2026-06-29 · методология v7. Совокупные данные переписи по 261 миллионам оцениваемых доменов. Смотрите как мы выставляем оценки.

Когда SPF перестаёт работать у компании, использующей SaaS-инструменты в Великобритании или ЕС, наиболее вероятная причина — одно правило RFC, о котором вам никогда не приходилось думать: после 10 DNS-запросов SPF не возвращает «fail» — он возвращает PermError, что означает, что запись трактуется так, будто её не существует. Как минимум 797 263 доменов уже пересекли эту черту. Ещё 2 119 539 находятся ровно на 9–10 запросах — и всего один новый инструмент отделяет их от того же обрыва.

Почему SPF ломается при подключении нового SaaS-инструмента?

SPF работает, перечисляя почтовые серверы, которым разрешено отправлять письма от имени вашего домена. Современные компании не используют собственные почтовые серверы — они используют Google Workspace для внутренней переписки, Mailchimp для рассылок, HubSpot для торговых последовательностей, Pipedrive для CRM-коммуникаций. Каждая платформа выдаёт вам строку include:, которую нужно вставить в DNS.

Проблема: каждый include: сам по себе является DNS-запросом. А каждая запись внутри этого include может рекурсивно вызывать новые запросы. RFC 7208 §4.6.4 устанавливает жёсткий предел в десять запросов. После десяти принимающий почтовый сервер прекращает оценку и возвращает PermError — а PermError — это не мягкий сбой, из-за которого письма попадают в спам. Это означает, что ваша SPF-запись считается отсутствующей. Аутентификация электронной почты по SPF-ветви завершается неудачей.

Вы не увидите этого в панели управления DNS. Счётчик срабатывает только во время живой проверки. У вас может быть три строки include: в видимой записи, и при этом цепочка уходит на двенадцать запросов вглубь — ведь каждый поставщик имеет собственную SPF-запись с вложенными include.

Сколько доменов уже превысило лимит?

Как минимум 797 263. Это количество, полученное после того, как мы разрешили каждый SPF-include: цели, упоминаемой 100 и более раз, — 10 842 уникальных целей, охватывающих 95,2% всех ссылок include, — и оценили полную цепочку для каждого домена. Поверхностный подсчёт (когда считаются только видимые строки в записи) даёт приблизительно 7 958. Цифра с учётом полной цепочки в 100 раз больше, потому что почти весь ущерб скрыт внутри целей include.

Ситуация, наиболее вероятно затрагивающая европейский бизнес:

Европейские хостинг-провайдеры и слабые настройки SPF по умолчанию

Хостинг-провайдер, с которого вы начинали, имеет значение — потому что некоторые устанавливают настройки SPF по умолчанию, которые уже расходуют несколько из десяти ваших запросов ещё до подключения первого SaaS-инструмента.

Среди крупнейших хостинг-провайдеров, используемых европейскими доменами в нашей переписи:

IONOS выделяется особо: лишь 1,0% доменов на IONOS имеют обязывающий DMARC, а значит, у подавляющего большинства нет никакой значимой аутентификации отправителей. Домены OVH показывают лучший результат по строгому SPF (43,7%), но снижаются до 2,2% по применению DMARC — SPF в одиночку, без DMARC для привязки к заголовку From:, защищает только конверт, но не то, что видит получатель.

Microsoft 365 является исключением в положительном смысле: 85,0% доменов Microsoft используют строгий SPF, прежде всего потому, что мастер настройки почты Microsoft устанавливает -all по умолчанию. Google Workspace по умолчанию устанавливает ~all (softfail), оставляя 92% своих доменов без строгой защиты.

Как диагностировать сбой SPF менее чем за 60 секунд

Самый быстрый способ — бесплатный инструмент, который оценивает полную цепочку запросов, а не только видимую запись. Запустите в командной строке nslookup -type=TXT yourdomain.com и подсчитайте все include:, которые видите. Затем найдите каждую из этих записей и подсчитайте их. Если пальцев на руках не хватает раньше, чем заканчиваются include, — вы в опасной зоне.

Более надёжный подход: проверьте свой домен здесь — сканер оценивает полную разрешённую цепочку, помечает PermError и показывает, какие механизмы расходуют ваш бюджет запросов.

Три возможных результата диагностики:

• PermError — вы уже превысили десять запросов. Каждое отправленное вами письмо не проходит проверку SPF у получателя.
• 9–10 запросов — вы на краю обрыва. Следующая SaaS-интеграция опрокинет вас за него.
• Softfail (~all) вместо hardfail (-all) — вы в пределах лимита, но запись настроена слишком мягко для реальной защиты. Смотрите отчёт об ошибках настройки SPF для полной картины сравнения -all и ~all.

Как исправить SPF при использовании нескольких SaaS-инструментов

Существуют три подхода, в порядке возрастания долговременности:

1. Аудит и удаление лишнего. Начните с перечисления всех include: в текущей записи. Удалите все платформы, которые вы больше не используете — старые ESP, CRM-инструменты из прошлых контрактов, платформы, которые вы тестировали, но забросили. Это бесплатно и нередко позволяет вернуть несколько запросов. Каждый удалённый include: может устранить 1–3 вложенных запроса.

2. Выравнивание SPF-записи. Выравнивание SPF разрешает все цели include: до лежащих в их основе диапазонов IP-адресов и записывает их непосредственно в запись как механизмы ip4: и ip6:. IP-механизмы не вызывают запросов, поэтому выровненная запись может перечислять десятки источников отправки и при этом оставаться на нуле запросов. Недостаток: необходимо повторно выравнивать запись при каждом обновлении отправляющих IP-адресов поставщиком, что происходит без предупреждения. Большинство компаний пользуются платным сервисом выравнивания SPF (PowerDMARC, EasyDMARC, Dmarcian и другие) или создают рабочий процесс мониторинга.

3. Использование SPF-макросов. Макросы RFC 7208 позволяют создавать записи, выполняющие один DNS-запрос на каждую проверку и дающие динамический ответ, вместо цепочки include. Макросы требуют поддержки со стороны хостинга DNS и некоторых усилий по внедрению, но являются архитектурно чистым решением для организаций с множеством SaaS-отправителей.

После исправления SPF дополните его применением DMARC — SPF без DMARC аутентифицирует только отправителя конверта, но не адрес в заголовке From:, который видят получатели.

Часто задаваемые вопросы

Почему моя SPF-запись проходит проверку в DNS-инструменте, но всё равно отказывает в заголовках электронной почты? Большинство DNS-инструментов считают только механизмы, видимые в вашей собственной записи, а не вложенные запросы, которые эти механизмы вызывают. У вас могут быть две строки include:, и при этом лимит будет превышен, если запись каждого поставщика содержит ещё несколько. Только инструмент, оценивающий полную цепочку (или принимающий почтовый сервер), считает полную глубину. Проверьте свой домен, чтобы увидеть реальное количество в цепочке.

Означает ли сбой SPF, что мои письма попадают в спам? PermError (слишком много запросов) означает, что SPF-ветвь аутентификации возвращает несостоятельный результат — фактически отсутствие записи. DMARC оценивает как SPF, так и DKIM; если DKIM прошёл проверку, DMARC может пройти, несмотря на PermError в SPF. Если оба не прошли, DMARC завершается неудачей, и исход зависит от вашей политики DMARC. При p=none письма всё равно доставляются, но сбой фиксируется. При p=quarantine или p=reject письма фильтруются или возвращаются. Исправьте SPF, чтобы не полагаться только на DKIM.

Сколько запросов использует типичный SaaS-стек? Запись p99 SPF в нашей переписи уже находится на 9 запросах — прямо у лимита — ещё до добавления чего-либо. Запись Google Workspace добавляет 3–4 запроса; Mailchimp — 1–2; HubSpot — 1–3 в зависимости от текущей конфигурации. Трёх популярных инструментов плюс настройки хостинг-провайдера по умолчанию часто достаточно, чтобы превысить десять.

Безопасно ли выравнивание SPF? Да, при условии актуального поддержания. Выравнивание преобразует цепочки include: в статические диапазоны IP-адресов — если поставщик меняет свои отправляющие IP-адреса, а вы не выполнили повторное выравнивание, вы начнёте отклонять его письма. Большинство организаций используют управляемый сервис выравнивания, который отслеживает изменения IP-адресов, а не поддерживают его вручную.

Моя SPF оставалась такой годами — почему она вдруг сломалась? Потому что ваши поставщики обновили свои SPF-записи, а не вы. Каждый раз, когда SaaS-платформа добавляет новый диапазон отправляющих IP-адресов или вкладывает ещё один include, стоимость вашей цепочки растёт без каких-либо изменений с вашей стороны. Лимит в 10 запросов оценивается в реальном времени при получении сообщения, поэтому изменение у поставщика в Tuesday утром может сломать ваш SPF уже к Tuesday afternoon.

Улучшает ли исправление SPF доставляемость электронной почты? Это устраняет источник сбоя аутентификации, что является предпосылкой для стабильной доставки — особенно с учётом того, что Google и Yahoo теперь применяют выравнивание DMARC для массовых отправителей. SPF в одиночку — не вся картина: дополните его DKIM и DMARC для полной аутентификации электронной почты.

Бесплатная проверка SPF

Если вы не уверены, превышает ли ваша SPF-запись лимит запросов или настроена слишком мягко для защиты домена, — выполните бесплатную проверку. Она оценивает полную разрешённую цепочку и показывает, куда именно расходуется бюджет.

Проверьте свой домен → · Исправьте SPF → · Отчёт об ошибке SPF PermError → · Отчёт об ошибках настройки SPF → · Модель зрелости внедрения SPF → · Исправьте DMARC → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.