SPF спря да работи след смяна на пощенски доставчик — поправката при миграция (2026)

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

Данни към 2026-06-29 · методология v7. Обобщени данни от census за 261 милиона оценени домейна. Вижте как оценяваме.

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

Поправката отнема около десет минути: сканирайте домейна, за да видите точно какво е оставила миграцията зад себе си, изброете всеки SPF запис на авторитативните ви сървъри за имена, слейте ги в един запис, включващ само новия ви доставчик, и проверете отново с dig. Това ръководство описва всяка стъпка, плюс DKIM и проверките на сървъра за имена, които повечето миграции пропускат.

Защо SPF се срина точно след миграцията?

Защото ръководството за настройка на новия доставчик казваше „добавете този TXT запис” — и вие го направихте, до стария. Това е единственото нещо, което стандартът SPF не позволява. RFC 7208 (§3.2, prescribed error result in §4.5) разрешава точно един v=spf1 запис на домейн; получател, намиращ два или повече, трябва да върне PermError вместо да гадае кой е авторитативен. PermError означава, че SPF е анулиран: не старият запис, не новият, никакъв SPF.

И не спира дотам. DMARC третира PermError като неуспех по SPF компонента, така че пощата ви вече разчита изцяло на DKIM. Ако DKIM на новия доставчик също не е настроен — обичайно по средата на миграцията — изпращате неавтентикирани точно в момента, в който сте сменили инфраструктурата, когато получателите ви следят най-стриктно.

Това е копирането и поставянето, анулиращо защитата при смяна на доставчик, и не е рядко: 1,013,416 домейна публикуват два или повече SPF записа в момента — около един на 138 от 139 милиона популация, опитваща SPF, според census на Defaults.Exposed за 261 милиона домейна (данни към 2026-06-29). Пълните числа за капана с два записа имат свой отделен доклад; тази страница е процедурната поправка.

Какво е оставила миграцията зад себе си?

Пет остатъка причиняват почти всеки SPF неуспех след миграция. Проверете ги в тази последователност:

Какво е останало	Какво виждате	Поправката
Старият SPF запис, все още в DNS до новия (два `v=spf1` записа)	Проверяващите съобщават „множество SPF записи” или 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, по средата на прехвърлянето:
```
Преди:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

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

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

Получателите оценяват SPF спрямо Return-Path (RFC5321.MailFrom) домейна — адреса за отвърнати писма — а не заглавието From, видяно от получателите ви. След миграция това е важно два пъти: новият ви доставчик може да използва собствения си домейн за отвърнати писма, докато не конфигурирате персонализиран, и SPF „преминаване” на домейн, различен от вашия, няма да съответства за DMARC. Поправката за това е DKIM на новия доставчик, подписан с вашия домейн.

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

Сменихте и домейна заедно с доставчика? Третирайте ги като две задачи. Новият домейн се нуждае от пълния стак — SPF, DKIM, DMARC — от самото начало; използвайте контролния списък за имейл на нов домейн. Старият домейн остава автентикиран, докато препращане или трафик за отговори минава през него, и се заключва изрично (а не просто изоставя) след паркирането. Стар домейн с остатъчен, полусчупен SPF е цел за подправяне, носеща старото ви ime.

Често задавани въпроси

Мога ли да запазя два SPF записа по време на миграцията? Не. Стандартът не предвижда гратисен период — два v=spf1 записа са PermError от момента на добавяне на втория, и 1,013,416 домейна са в това положение към census (2026-06-29). Безопасният модел по време на миграция е един запис, носещ includes и на двата доставчика по времето на припокриването.

Колко дълго трябва да запазвам include на стария доставчик? Докато нищо не изпраща чрез стария доставчик — обикновено дължината на вашия прозорец на припокриване, дни до няколко седмици. Наблюдавайте Return-Path на всичко, пристигащо още чрез старата система; когато трафикът спре, премахнете include и проверете отново броя на търсенията.

Защо проверяващият все още показва стария ми запис след поправянето? DNS кеширането спазва TTL на записа, и ако сервърите ви за имена са сменени, някои резолвери все още питат стария набор. Проверете директно на авторитативните сървъри за имена с dig TXT yourdomain.com @<ns> — ако отговорът е правилен там, поправката е готова и кешовете ще се синхронизират. Ако е грешен при единия набор NS, вижте ‘SPF запис не е намерен’ — истинските причини.

Трябва ли да сменям DMARC при смяна на доставчик? Обикновено не самия запис — той назовава пощенската ви кутия за доклади и политиката, а не доставчика ви. Но резултатите ви от DMARC зависят от SPF и DKIM, току-що мигрирани: очаквайте спад в докладите по времето на прекъсването и потвърдете, че и двата компонента преминават, преди да затегнете политиката. Започнете от поправяне на SPF, ако сканирането показва, че SPF компонентът все още не успява.

Изпратете на собственика доклада

Ако правите тази миграция за клиент, завършете с доказателство. Пуснете отново безплатното сканиране след като сливането е активно и препратете оценения доклад на собственика на бизнеса: SPF, DKIM и DMARC преминаващи при новия доставчик, разбираемо, датирано. Това е артефактът, подаван при подновяване на киберзастраховката и следващия въпросник за сигурност от доставчик — доказателство, че миграцията е оставила домейна по-добре автентикиран, отколкото е бил.

Проверете вашия домейн → · DKIM не успява след смяна на инструменти за имейл → · ‘SPF запис не е намерен’ — истинските причини → · Как оценяваме → · Само обобщени данни. Данните се съхраняват и обработват в ЕС.