SPF перестал работать после смены почтового провайдера — исправление при миграции (2026)

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

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

SPF после смены почтового провайдера обычно ломается потому, что запись нового провайдера была добавлена рядом со старой. Две записи v=spf1 — это постоянная ошибка: SPF аннулируется целиком. В этом состоянии находятся 1 013 416 доменов — примерно один из 138 среди тех, кто вообще пытается использовать SPF, — по данным переписи Defaults.Exposed из 261 млн доменов. Слейте их в одну.

Исправление занимает около десяти минут: проверьте домен, чтобы увидеть, что именно осталось после миграции, перечислите все SPF-записи на своих авторитативных серверах имён, слейте их в одну запись, включающую только нового провайдера, и перепроверьте через dig. Это руководство проводит по каждому шагу, плюс проверки DKIM и серверов имён, о которых забывает большинство миграций.

Почему SPF сломался сразу после миграции?

Потому что в инструкции нового провайдера было сказано «добавьте эту TXT-запись» — и вы добавили её рядом со старой. Это ровно то единственное, чего стандарт SPF не допускает. RFC 7208 (§3.2, результат-ошибка предписан в §4.5) разрешает ровно одну запись v=spf1 на домен; получатель, нашедший две и более, обязан вернуть PermError, а не гадать, какая из них авторитетна. PermError означает, что SPF аннулирован: не старая запись, не новая — никакого SPF вообще.

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

Это та самая копипаста, которая аннулирует защиту при смене провайдера, и она не редкость: прямо сейчас 1 013 416 доменов публикуют две и более SPF-записи — примерно один из 138 в популяции из 139 млн доменов, пытающихся использовать SPF, — по данным переписи Defaults.Exposed из 261 млн доменов (данные по состоянию на 2026-06-29). У полных цифр о ловушке двух записей есть отдельный отчёт; эта страница — процедура исправления.

Что осталось после миграции?

Почти каждый пост-миграционный сбой SPF вызывают пять «хвостов». Проверяйте их в этом порядке:

Что осталось	Что вы видите	Исправление
Старая SPF-запись, всё ещё лежащая в DNS рядом с новой (две записи `v=spf1`)	Чекеры сообщают “multiple SPF records” или PermError; SPF полностью перестаёт работать	Слейте в одну запись, удалите остальные — шаги ниже
`include:` старого провайдера внутри вашей единственной записи	SPF работает, но вы впустую тратите DNS-запросы, а серверы старого провайдера всё ещё могут отправлять от вашего имени	Удалите его, когда почта полностью перестанет идти через старую систему
`include:` нового провайдера так и не добавлен	Почта от нового провайдера не проходит SPF у получателей	Добавьте его в единственную существующую запись — никогда как новую запись
DKIM-селекторы для нового провайдера не созданы	`dkim=fail` или подписи от домена провайдера по умолчанию; у DMARC нет второй ноги	Опубликуйте новые селекторы — шаг 6 ниже
Запись обновлена только на старых серверах имён	Разные ответы в зависимости от того, кого спрашивать; периодические сбои	Исправьте зону на авторитативных серверах имён; на время перехода проверяйте оба набора

Как это исправить? Чек-лист миграции

Сначала запустите бесплатную проверку на defaults.exposed. Она читает ваш живой DNS и говорит, есть ли у вас несколько SPF-записей, отсутствующий include или пробел в DKIM — диагностируйте, прежде чем что-либо трогать.
Перечислите все SPF-записи на авторитативных серверах имён. dig +short NS yourdomain.com, затем dig +short TXT yourdomain.com @<nameserver> к одному из них. Посчитайте строки, начинающиеся с v=spf1. Единственное безопасное число — 1.
Слейте всё в одну запись. Одна запись, начинающаяся с v=spf1, содержащая include вашего нового провайдера и всех остальных отправителей, которыми вы ещё пользуетесь (сервис выставления счетов, CRM, платформа рассылок), с одним завершающим -all или ~all. Пример — старый Google Workspace, новый Microsoft 365, переходный период:
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
Значения провайдеров и особенности DNS-панелей — в руководствах по настройке для Google Workspace и Microsoft 365.
Удалите лишние записи. Слияние без удаления ничего не исправляет — PermError возникает из-за количества записей.
Держите include старого провайдера, только пока старая система ещё отправляет — плановые отчёты, старый коннектор CRM, забытый почтовый ящик. Когда поток иссякнет, удалите его: залежавшийся include оставляет старой инфраструктуре разрешение отправлять от вашего имени, а каждый include стоит DNS-запросов при жёстком лимите SPF в 10 — как минимум 797 263 доменов аннулировали свой SPF, пробив этот лимит (перепись, 2026-06-29).
Настройте DKIM нового провайдера — и пока не удаляйте старые селекторы. Новые селекторы подписывают новую почту; старые селекторы должны оставаться опубликованными, пока каждое подписанное ими сообщение не будет доставлено и не улягутся пересылки. Полный разбор — в руководстве DKIM сломался после смены почтовых инструментов.
Если вы сменили и серверы имён, проверьте оба набора. DNS-миграции часто идут в связке с почтовыми. Запросите старый и новый наборы NS напрямую (dig TXT yourdomain.com @old-ns и @new-ns) — пока делегирование у регистратора полностью не распространится, часть получателей всё ещё спрашивает старые серверы, так что исправленная запись должна существовать на любом наборе, который отвечает.
Запустите проверку заново и убедитесь, что SPF показывает одну действительную запись с результатом pass.

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

Получатели вычисляют SPF по домену Return-Path (RFC5321.MailFrom) — адресу возвратов, — а не по заголовку From, который видят ваши адресаты. После миграции это важно вдвойне: новый провайдер может использовать собственный домен возвратов, пока вы не настроите свой, а «прохождение» SPF на домене, который вам не принадлежит, не даст выравнивания для DMARC. Лекарство от этого — DKIM нового провайдера, подписывающий вашим доменом.

Миграция и ребрендинг одновременно?

Сменили не только провайдера, но и домен? Считайте это двумя разными задачами. Новому домену нужен весь стек — SPF, DKIM, DMARC — с первого дня; используйте почтовый чек-лист для нового домена. Старый домен остаётся аутентифицированным, пока через него идут пересылки или ответный трафик, а после парковки его явно запирают (а не просто бросают). Старый домен с недоломанным, забытым SPF — это мишень для спуфинга, носящая ваше прежнее имя.

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

Можно ли держать две SPF-записи на время миграции? Нет. В стандарте нет льготного периода — две записи v=spf1 дают PermError с момента появления второй, и по данным переписи (2026-06-29) в этом состоянии сидят 1 013 416 доменов. Безопасный для миграции приём — одна запись, несущая include обоих провайдеров на время переходного окна.

Как долго держать include старого провайдера? Пока через старого провайдера ничего не отправляется — обычно это длина вашего переходного окна, от нескольких дней до пары недель. Следите за Return-Path всего, что ещё приходит через старую систему; когда этот трафик прекратится, удалите include и перепроверьте свой счётчик DNS-запросов.

Почему чекер всё ещё показывает мою старую запись после исправления? Кэширование DNS соблюдает TTL записи, а если ваши серверы имён сменились, часть резолверов всё ещё опрашивает старый набор. Проверьте напрямую на авторитативных серверах имён через dig TXT yourdomain.com @<ns> — если там ответ правильный, исправление завершено, и кэши подтянутся. Если на одном из наборов NS он неправильный — см. «SPF-запись не найдена» — настоящие причины.

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

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

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

Проверьте свой домен → · DKIM сломался после смены почтовых инструментов → · «SPF-запись не найдена» — настоящие причины → · Как мы ставим оценки → · Только агрегированные данные. Данные хранятся и обрабатываются в ЕС.