Defaults.Exposed › Исправления › Guides

SPF не проходит для ваших SaaS-инструментов? Почему это происходит и порядок исправления — европейское издание (2026)

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

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

Когда SaaS-инструмент «не проходит SPF», проблема обычно не в вашей записи: письмо не проходит выравнивание DMARC, либо ваша цепочка include превысила лимит SPF в 10 DNS-запросов. 2 119 539 из 138 927 207 доменов, публикующих SPF, находятся на уровне 9–10 запросов — в одном SaaS-include от обрыва, — по данным переписи Defaults.Exposed, охватившей 261 086 232 доменов.

Ниже: как определить, какая из двух проблем у вас, затем порядок исправления — сначала сканирование, потом поиск домена, с которого инструмент на самом деле отправляет, переключение поставщика на DKIM для собственного домена и добавление include в SPF только там, где это действительно помогает, — плюс особенности для HubSpot, Salesforce, Mailchimp и SendGrid.

Почему письма из SaaS-инструмента не проходят SPF?

Три сценария покрывают почти все случаи:

Данные по состоянию на 2026-06-29.

Строка, выделенная жирным, — та, в которой стоит большинство. Добавление строк include: для каждого инструмента её не решает — а каждая строка приближает вас ко второй строке таблицы: как минимум 797 263 доменов уже перешагнули лимит в 10 запросов, и их SPF теперь возвращает PermError, который ничего не защищает. Полные цифры — в отчёте об SPF PermError.

Какой домен на самом деле проверяет SPF?

Не тот, что в вашем заголовке From. Получатели проверяют SPF по домену Return-Path (RFC5321.MailFrom, также называемому bounce- или envelope-from-адресом) — заголовок From, который видит ваш получатель, в самой проверке SPF никакой роли не играет.

Один этот факт объясняет большинство «SPF-сбоев SaaS». Ваша маркетинговая платформа отправляет письма с Return-Path вида [email protected]; SPF проверяется по vendor.com и спокойно проходит. Затем DMARC спрашивает, совпадает ли этот проверенный SPF домен с вашим доменом From. Он не совпадает, поэтому SPF-ветка DMARC не проходит, и ваша панель показывает «SPF failing». Правкой собственной SPF-записи это не исправить — к вашей записи никто и не обращался.

В каком порядке исправлять?

1. Сначала запустите бесплатную проверку. Она за один проход показывает, отсутствует ли ваш SPF, продублирован ли он, превышен ли лимит запросов или всё в порядке, и в каком состоянии DMARC — до того, как вы тронете DNS.
2. Найдите Return-Path, который инструмент реально использует. Отправьте себе тестовое письмо из инструмента и прочитайте в исходнике сообщения заголовок Return-Path (и Authentication-Results). Это покажет, в какой строке таблицы выше вы находитесь.
3. Включите у поставщика DKIM для собственного домена. Любой серьёзный SaaS-инструмент предлагает «domain authentication»: несколько CNAME-записей, позволяющих ему подписывать письма DKIM от имени вашего домена. Такая подпись выравнивается с вашим доменом From, поэтому DMARC проходит через DKIM — устойчиво и даже при пересылке письма. Это исправление, которое работает надолго.
4. Добавляйте SPF-include поставщика, только если он использует ваш return-path — вы включили его собственный bounce-домен, или он действительно отправляет письма с вашим доменом в конверте. Include для поставщика, который возвращает отлупы через собственный домен, ничего не даёт и расходует ваш бюджет запросов.
5. Посчитайте DNS-запросы перед сохранением. Лимит — 10 разрешаемых запросов, include считаются рекурсивно, и 2 119 539 доменов уже находятся на уровне 9–10 — 99-й перцентиль переписи равен 9. Стоите у края? Сначала удалите include для инструментов, которыми больше не пользуетесь. Недавно сменили почтового провайдера? Проверьте, не осталась ли вторая запись — две SPF-записи означают PermError.
6. Пересканируйте и подтвердите. SPF проходит на правильном домене, DKIM выровнен, DMARC проходит. Полный справочник — на странице как исправить SPF; пошаговые инструкции по провайдерам, такие как SPF на GoDaddy и DMARC на IONOS, описывают конкретные шаги в DNS-панели.

Что делать для HubSpot, Salesforce, Mailchimp и SendGrid?

HubSpot. Подключите свой отправляющий домен в настройках HubSpot и опубликуйте две DKIM-записи CNAME, которые он выдаёт (hs1-… / hs2-…). Это выравнивает DKIM с вашим доменом From. SPF-include для HubSpot не нужен, если только вы не настроили HubSpot на использование вашего собственного bounce-домена.

Salesforce. Создайте DKIM-ключ в Salesforce Setup и опубликуйте пару CNAME, которую он сгенерирует. Если Salesforce отправляет письма с return-path вашей организации, добавьте include:_spf.salesforce.com и настройте bounce-домен — это та самая крупная CRM, где SPF-include действительно часто нужен.

Mailchimp. Аутентифицируйте свой домен и опубликуйте DKIM-записи CNAME k2 / k3. Выравнивание в Mailchimp работает только через DKIM — SPF-include добавлять больше нечего, а добавление его по старой инструкции лишь тратит запросы.

SendGrid. Пройдите аутентификацию домена («automated security»): три CNAME, закрывающие и DKIM, и return-path на вашем собственном поддомене. SPF-include не нужен. Из 740 321 доменов, чей SPF авторизует sendgrid.net, лишь у 18,0% действует принуждающая политика DMARC (данные по состоянию на 2026-06-29) — большинство отправителей через SendGrid останавливаются в одном шаге от финиша.

Zendesk и всё остальное: та же схема. Найдите у инструмента страницу «domain authentication», опубликуйте его DKIM-записи CNAME и трогайте SPF только если инструмент документирует, что использует ваш return-path.

Отличается ли SPF для европейского бизнеса?

Нет — SPF, DKIM и DMARC везде работают одинаково. В Европе отличается контекст: кто спрашивает и что уже сделали ваши соседи.

Ваш национальный домен задаёт местную планку. Европейские ccTLD публикуют SPF заметно чаще, чем .com, но домены, доводящие дело до конца — до принуждающей политики DMARC сверху, — везде в меньшинстве:

Данные по состоянию на 2026-06-29. Франция: 13,65% с принуждающим DMARC; Италия: 5,24%.

Настройки по умолчанию у вашего европейского хостера имеют значение. 4 346 526 доменов авторизуют в своём SPF европейские почтовые серверы IONOS (_spf-eu.ionos.com) — и лишь 0,3% заканчиваются строгим -all, при 1,0% с принуждающим DMARC. У OVH 2 132 049 доменов лучше со строгостью (43,7%), но лишь 2,2% принуждают DMARC (данные по состоянию на 2026-06-29). Если вы никогда не трогали свою запись, вы стоите на этих настройках по умолчанию.

Регуляторы теперь называют это прямо. Статья 21(2)(j) NIS2 требует от организаций в её сфере действия защищать свои коммуникации, а Имплементационный регламент Комиссии (ЕС) 2024/2690 конкретизирует меры по безопасности электронной почты и DNS. Аутентификация электронной почты — конкретный, проверяемый элемент, и, что для комплаенса необычно, исправляется бесплатно.

О размещении данных: сканер и перепись Defaults.Exposed работают в AWS eu-west-1, мы публикуем только агрегированные цифры, а проверка затрагивает только тот домен, о котором вы спрашиваете.

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

Мой SPF-чекер говорит «pass», а панель инструмента показывает, что SPF не проходит, — почему? Чекер проверил вашу запись; получатель проверил домен Return-Path, который инструмент реально использовал, а затем DMARC сравнил его с вашим доменом From. Это сбой выравнивания, а не записи — он исправляется DKIM поставщика для вашего собственного домена, а не правками SPF.

Может, просто добавить SPF-include для каждого инструмента, которым мы пользуемся? Нет. Каждый include расходует часть бюджета SPF в 10 запросов, причём рекурсивно: 2 119 539 из 138 927 207 доменов, публикующих SPF, находятся на уровне 9–10 запросов, а как минимум 797 263 уже за пределом — их SPF возвращает PermError и ничего не защищает (данные по состоянию на 2026-06-29).

Исправит ли include и DMARC тоже? Только если инструмент отправляет письма с вашим return-path, так что SPF проходит и выравнивается. У большинства SaaS-инструментов это не так — именно поэтому выровненный DKIM, а не SPF, является той веткой, благодаря которой DMARC проходит для SaaS-почты.

Является ли это юридическим требованием в ЕС? Для организаций в сфере действия NIS2 статья 21(2)(j) и Имплементационный регламент (ЕС) 2024/2690 делают безопасность электронной почты обязанностью. Даже вне этой сферы страховщики и клиентские анкеты спрашивают об этом всё чаще — а по состоянию на 2026-06-29 ни один национальный домен ЕС не доводит даже треть своих доменов до принуждающей политики DMARC (29,43% в .nl в лучшем случае; 5,24% в .it).

Отправьте владельцу отчёт

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

Проверьте свой домен бесплатно

Посмотрите, какая именно ветка SPF, DKIM и DMARC не проходит, — приватно и только для владельца.

Проверить свой домен → · Исправить SPF → · SPF PermError: «too many DNS lookups» → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.