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

Пересланное письмо не проходит SPF — почему это нельзя исправить и что действительно работает (2026)

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

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

Вы не можете заставить SPF проходить для пересланной почты — пересылка ломает SPF по самой его конструкции, и честное решение — выровненный DKIM, который пересылку переживает. Масштаб виден по всей переписи: 7 355 985 из 138 927 207 доменов, публикующих SPF, авторизуют только include пересылки Namecheap, при доле строгого SPF <0.1%, по данным переписи Defaults.Exposed из 261 млн доменов.

Ниже: почему никакая SPF-запись, какую бы вы ни написали, не переживёт пересылку, почему SRS и ARC — не инструменты под вашим контролем, и решение, которое держится — подписание DKIM вашим собственным доменом как ваш проход DMARC, — плюс единственный случай, который ломает и DKIM (списки рассылки, изменяющие сообщения), и что делать с этим остатком.

Почему пересылка ломает SPF?

Получатели проверяют SPF по домену Return-Path (RFC5321.MailFrom), а не по заголовку From. Когда вы отправляете напрямую, IP вашего сервера есть в вашей SPF-записи, и проверка проходит. Когда ваш получатель автоматически пересылает сообщение дальше — на личный Gmail, через университетский алиас, через сервис пересылки регистратора — сообщение повторно передаёт сервер пересыльщика, обычно сохраняя ваш домен в Return-Path. Конечный получатель теперь спрашивает: авторизован ли этот пересылающий сервер в вашей SPF-записи?

Нет — и никогда не будет: вы не выбирали пересыльщика, вы не знаете о его существовании, а то же сообщение, пересланное завтра через другой сервис, не пройдёт уже с другого IP. SPF отвечает на один вопрос — «пришёл ли этот IP с сервера, авторизованного доменом Return-Path?» — и для пересланной почты честный ответ — нет. Этот провал — SPF, работающий по спецификации, а не ошибка в вашей записи.

Перепись показывает, насколько массовый это путь: 7 355 985 доменов авторизуют include пересылки почты Namecheap (spf.efwd.registrar-servers.com) — продукт пересылки одного-единственного провайдера, из 139 млн публикующих SPF — при доле строгого SPF <0.1% и лишь 0,2% с принуждением DMARC. Этот мягкий шаблон — не небрежность: пересылка — ровно та ситуация, где строгий -all даёт осечку, и провайдер, чей продукт и есть пересылка, настраивает соответственно. Полная история о квалификаторах — в нашем отчёте ~all против -all, а картина по провайдерам — в статье какой почтовый провайдер даёт самый сильный SPF.

А нельзя просто добавить сервер пересыльщика в мою SPF-запись?

Нет — и объяснение почему и есть вся эта статья:

1. Вы не можете перечислить всех пересыльщиков. Любой получатель, где угодно, может переслать вашу почту через любой сервис. Вашей SPF-записи пришлось бы перечислять серверы, о которых вы не можете знать заранее.
2. Перечислить их — значит уничтожить смысл проверки. Крупные сервисы пересылки ретранслируют почту миллионов клиентов. Впишите их диапазоны в свою запись — и каждое сообщение, которое ретранслирует любой из их пользователей, включая злоумышленника, будет проходить SPF от вашего имени.

Та же логика исключает и смягчение квалификатора «чтобы пересылка заработала»: квалификатор — не причина, по которой пересланная почта не проходит, а с включённым DMARC он меняет меньше, чем утверждает большинство руководств — см. данные о квалификаторах. Запись здесь — не тот рычаг. Перестаньте его дёргать.

А как же SRS и ARC — разве они не чинят пересылку?

Они её адресуют — но ни один из них не в ваших руках:

Данные и статус механизмов по состоянию на 2026-06-29.

SRS решает проблему SPF пересыльщика, а не вашу: переписывание Return-Path меняет, чей SPF проверяется, а ваш заголовок From — домен, который защищает DMARC, — остаётся нетронутым. ARC — это решение о доверии между операторами инфраструктуры. Если руководство советует вам «внедрить SRS» как владельцу домена, оно перепутало вас с провайдером пересылки.

Как сделать так, чтобы моя почта переживала пересылку?

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

1. Запустите бесплатную проверку на defaults.exposed, прежде чем трогать DNS. Она показывает, есть ли у вас DKIM вообще, подписывает ли он вашим доменом и в каком состоянии ваш DMARC — чтобы вы чинили реальный пробел, а не воевали со своей SPF-записью.
2. Убедитесь, что ваша проблема действительно в пересылке. В заголовке Authentication-Results затронутого сообщения прямая почта проходит SPF, а пересланная копия не проходит — с IP-адреса сервиса пересылки. Если SPF и DKIM проходят, а DMARC всё равно не проходит, у вас проблема выравнивания — см. DMARC не проходит, хотя SPF и DKIM проходят.
3. Включите подписание DKIM вашим собственным доменом у каждого отправляющего сервиса — сначала у почтового провайдера, затем у ESP и транзакционных отправителей. Провайдеры по умолчанию часто подписывают своим доменом, который не выравнивается; вам нужен d=yourdomain. Начните со страницы как исправить DKIM, с пошаговыми путями для Google Workspace и Microsoft 365.
4. Проверяйте выравнивание, а не просто прохождение. Домен d= в подписи должен совпадать с вашим доменом в From; dkim=pass на чужом домене ничего не даёт вашему DMARC.
5. Не трогайте свою SPF-запись. Держите её точной для прямой почты — она по-прежнему аутентифицирует большую часть вашего трафика и остаётся вашей второй ногой DMARC. Просто перестаньте пытаться охватить ею пересыльщиков.
6. Перепроверьте, затем осознанно и поэтапно вводите принуждение DMARC — следующий раздел и руководство по развёртыванию от p=none к p=reject.

Эта комбинация — SPF плюс принуждающий DMARC, опирающийся на выровненный DKIM, — и есть устойчивый к пересылке шаблон, и она редка: из 77,5 млн доменов, публикующих ~all, лишь 9,2% (7 116 774) подкрепляют его принуждающей политикой DMARC, и всего 3,87% из 261 млн оценённых доменов (10 092 481) завершают полную триаду SPF + DKIM + принуждённый DMARC, по данным переписи (2026-06-29).

А как же списки рассылки, которые изменяют сообщения?

Единственный путь пересылки, который выровненный DKIM не переживает: списки рассылки, изменяющие сообщение — тег [list-name] в теме, футер с отпиской, вырезанное вложение. Измените подписанное содержимое — и хеш тела больше не совпадает, так что DKIM тоже не проходит (у этого провала есть собственное руководство: dkim=fail: body hash did not verify). Теперь обе ноги DMARC мертвы, и смягчить это может только сам список (переписывание From, запечатывание ARC).

Именно для этого остатка и существует поэтапное принуждение DMARC. Прохождение через p=quarantine с постепенным наращиванием pct, пока вы следите за агрегированными отчётами, показывает, какая часть вашей реальной почты идёт через изменяющие списки, прежде чем политика p=reject начнёт её отбрасывать. Не прыгайте к reject на домене, чьи пользователи живут в списках рассылки; но и не застревайте на p=none навсегда. Руководство по поэтапному развёртыванию проводит по всей лестнице.

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

Ломает ли пересылка и DKIM тоже? Обычная пересылка — нет: подпись едет вместе с сообщением и проверяется у конечного получателя. DKIM ломается, только когда подписанное содержимое изменено в пути — классический случай: теги в теме и футеры списков рассылки, — и именно поэтому остаток от списков решается поэтапной политикой DMARC, а не чем-либо в DNS.

Стоит ли переключиться с -all на ~all, чтобы пересылка перестала падать? Смена квалификатора не заставит пересыльщиков проходить проверку — они падают не из-за него. Показательно, что include пересылки Namecheap — 7 355 985 доменов, крупнейшая в переписи популяция чистой пересылки (2026-06-29) — поставляется с долей строгого SPF <0.1%: мягкий SPF, пожалуй, и есть корректный шаблон для продукта пересылки. Что квалификатор меняет на самом деле — см. отчёт ~all против -all.

Почему моя почта проходит SPF при прямой отправке, но не проходит, когда её кто-то пересылает? Получатель проверяет, авторизован ли IP последнего передающего сервера SPF-записью вашего домена Return-Path. Напрямую: ваш сервер, есть в записи, проход. С пересылкой: сервер пересыльщика, нет в записи, провал. Ваша запись не менялась — изменился передающий IP.

Могу ли я настроить SRS, чтобы это исправить? Только если вы и есть пересыльщик. SRS работает на сервере, выполняющем пересылку, и даже там, где он работает, итоговый проход SPF принадлежит домену пересыльщика и не выравнивается с вашим From — вашему DMARC всё равно нужна нога DKIM.

Бессмыслен ли SPF, раз пересылка его всё равно ломает? Нет. Большая часть почты доставляется напрямую, где SPF работает ровно как задуман, и он остаётся одной из двух ваших ног DMARC. Из 261 086 232 доменов переписи (2026-06-29) 138 927 207 публикуют SPF — держите свой точным через страницу исправления SPF, а пересланный остаток пусть несёт DKIM.

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

Если вы чините это для клиента или работодателя, закройте вопрос доказательством. Когда DKIM с собственным доменом заработал и DMARC развёрнут поэтапно, запустите бесплатную проверку заново и перешлите оценённый отчёт владельцу бизнеса: датированный, на понятном языке, показывающий, что домен остаётся аутентифицированным, даже когда его почту пересылают. Это и есть артефакт для продления киберстраховки и очередной анкеты поставщика — задокументированные «до и после», а не «я что-то включил».

Проверьте свой домен → · DMARC не проходит, хотя SPF и DKIM проходят → · Исправить DKIM → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.