DKIM не минава след смяна на имейл инструменти: Ръководство за CNAME и миграция на селектори (2026)

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

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

DKIM се чупи след смяна на инструмент по две механични причини: DNS панелът е повредил CNAME целите на новия инструмент — обикновено като е прикачил вашата собствена зона — или старите селектори на стария инструмент са изтрити преди пощата му да се изтощи. Само 3.87% от домейните — 10,092,481 — завършват триадата SPF+DKIM+DMARC, според census-а на Defaults.Exposed от 261,086,232 оценени домейна.

Редът на поправката: сканирайте домейна, след това проверете съхранената цел на всеки нов CNAME с dig — цел, завършваща с вашето собствено домейн име, е дим от пистолета. Поправете записите при авторитетните nameserver-и, потвърдете, че новият инструмент подписва и минава преди да насочите реална поща през него, и запазете старите селектори на стария инструмент публикувани, докато трафикът му се изтощи.

Защо DKIM се счупи при смяна на инструменти?

Нищо относно самия DKIM не се е променило — селекторите ви са се променили. Старият инструмент е подписвал с неговите селектори; новият подписва с различни, обикновено делегирани чрез два или три CNAME записа, добавени при въвеждането. Четири клопки обясняват почти всеки неуспех на DKIM след миграция:

DNS панелът ви е прикачил зоната към CNAME целта. Много панели третират всяко поставено hostname като относително и безшумно съхраняват target.provider.com.yourdomain.com вместо target.provider.com. Записът съществува, панелът показва зелена отметка и не разрешава до нищо.
Объркване с trailing dot. Някои панели изискват trailing dot (target.provider.com.) да означава „абсолютно — спри да добавяш зоната ми”; други отхвърлят точката като невалидна и сами управляват абсолютността. Едно и също поставено стойност е правилна в единия панел и повредена в следващия.
Старите селектори на инструмента са изтрити в деня на смяната. Поща, която старият инструмент вече е подписал, стои в retry опашки и маршрути за препращане с дни; премахването на селекторите му — или затварянето на стария акаунт, което унищожава делегираните CNAME — ретроактивно чупи тази поща.
Верифицирали сте при грешните nameserver-и. Ако миграцията е включвала смяна на nameserver, поправените записи може да съществуват при единия набор NS, докато получателите все още запитват другия.

Само 51.84% от 261 милиона домейна в census-а представят открит DKIM ключ при сканиране (данни към 2026-06-29).

Същата миграция обикновено оставя и SPF отломки — 1,013,416 домейна, приблизително 1 на 138 от тези, опитващи SPF, работят с два v=spf1 записа, класическият признак, че смяна на доставчик е добавила запис вместо да го обедини. Тази страна на преместването има собствено ръководство: SPF е спрял да работи след смяна на имейл доставчика.

Как да разпозная повреден CNAME запис?

Не се доверявайте на панела — попитайте DNS какво в действителност е съхранено. Запитайте CNAME целта за всеки селектор, даден от новия инструмент. Илюстративен пример, имитиращ делегиран селектор в стил SendGrid (формата на целта на вашия доставчик ще се различава):

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

Доставчикът е поискал s1.domainkey.u1234567.wl123.sendgrid.net — но съхранената цел завършва с .yourdomain.com. Панелът е прикачил зоната; това име не разрешава до нищо, така че получателите не намират ключ. Здравословната версия:

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(Единична trailing dot в изхода на dig е нормална — маркира напълно квалифицирано ime.) Ако целта е правилна, проследете я един хоп: dig TXT s1._domainkey.yourdomain.com +short трябва да върне ключа на доставчика. Празен отговор с правилен CNAME означава, че проблемът е от страна на доставчика на делегирането — завършете тяхната стъпка за верификация или вижте DKIM „no key for signature” за диагностиката на ниво селектор.

Наръчникът за миграция: преди, по време на, след

Неуспехът обикновено не е в записите — а в реда. Миграциите на DKIM се объркват при смяната, защото верификацията се случва след смяната, когато реалната поща вече не минава.

Фаза	Какво да правите	Портал преди да преминете
Преди смяната	Добавете DKIM CNAME записите на новия инструмент (и bounce-domain записите), след това ги докажете: `dig` всяка съхранена CNAME цел от извън мрежата ви, завършете собствената стъпка за верификация на инструмента и изпратете тест през новия инструмент до пощенска кутия, която контролирате	Тестовото съобщение показва `dkim=pass` с `d=` = вашия домейн — никога не насочвайте реална поща през неверифициран инструмент
Ден на смяната	Преместете реалния трафик към новия инструмент. Не докосвайте нищо, принадлежащо на стария инструмент: оставете селекторите, CNAME записите и акаунта живи	Пощата на новия инструмент минава при реалните получатели; старият инструмент продължава да минава за всичко, все още течащо през него
След изтощаването	Следете DMARC агрегираните доклади, докато селекторите на стария инструмент спрат да се появяват (retry опашките и препращанията работят с дни — позволете седмица или повече), след което оттеглете записите и акаунта	Старите селектори отсъстват от докладите ≥ 7 дни преди премахването

Маркираният ред е там, където миграциите се спасяват или губят: всяка проверка в него може да бъде направена дни преди смяната, без никакъв риск за живата поща. Механиката за оттегляне на селектори — включително защо повторното публикуване с празен p= е по-добро от изтриване — е разгледана в наръчника за ротация; тази таблица е за последователността на самата смяна на инструменти.

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

Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Чете живите записи и показва какво виждат получателите — включително CNAME цели, прикачени към зоната, и селектори, неразрешаващи.
Избройте DKIM записите, които новият инструмент очаква. От административната му конзола — за доставчици на пощенски кутии, ръководствата за настройка на Google Workspace и Microsoft 365 показват къде; инструментите за бюлетини и CRM изброяват CNAME записите под домейн автентикация (вижте Mailchimp/Brevo/Klaviyo имейли, неминаващи DMARC).
Проверете съхранената стойност на всеки запис с dig CNAME <name> +short и я сравнете символ по символ с това, което инструментът е поискал. Цел, завършваща с вашия домейн = прикачена към зоната; въведете я отново, и ако панелът продължава да прикача, добавете trailing dot (или я премахнете, ако панелът отхвърля dots).
Верифицирайте при авторитетните nameserver-и. dig +short NS yourdomain.com, след това повторете проверките на CNAME @<тозинameserver>. Ако миграцията е сменила nameserver-ите, проверете и двата набора — получателите може все още да запитват стария, докато делегирането се разпространи.
Повторете верификацията на инструмента и изпратете тестово съобщение. Хедърът Authentication-Results трябва да показва dkim=pass с d= равно на вашия домейн — pass при домейна по подразбиране на инструмента не е aligned за DMARC.
Оставете старите селектори на инструмента публикувани, докато пощата му се изтощи, след което ги оттеглете съзнателно. След това направете ново сканиране и се заемете с всичко останало, маркирано на страницата за поправка на DKIM.

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

Нужна ли ми е trailing dot на DKIM CNAME или не? Зависи изцяло от панела. Точката означава „абсолютно ime — не добавяй зоната ми”; някои панели я изискват, някои я добавят за вас, някои я отхвърлят. Единственият тест, от значение, е изходът от dig CNAME <selector>._domainkey.yourdomain.com +short след запазване: ако целта завършва с вашия домейн, панелът е прикачил зоната и ви е нужна точката (или различен формат за въвеждане).

Мога ли да изтрия DKIM записите на стария инструмент в деня на смяната? Не. Пощата, подписана от стария инструмент, все още е в retry опашки и маршрути за препращане, а изтриването на ключа, към който сочи, ретроактивно чупи тези съобщения. Запазете старите селектори живи, докато спрат да се появяват в DMARC агрегираните доклади — седмица или повече — и не затваряйте стария акаунт преди тогава.

DNS панелът и новият инструмент и двамата казват „verified”, но получателите все пак не минават DKIM. Как? Два чести случая: инструментът е верифицирал спрямо кеширана проверка, докато авторитетните nameserver-и служат нещо различно (запитайте ги директно с dig @<ns>), или DKIM минава, но при домейна за подписване по подразбиране на инструмента, а не при вашия, така че DMARC все пак не минава alignment. Сканирането разграничава двата случая.

Могат ли DKIM записите на двата инструмента да съществуват едновременно по време на припокриването? Да — и трябва. DKIM няма правило за единичен запис: всеки селектор е свое DNS ime, така че записите на двата инструмента съжителстват без конфликт, което прави правилото за задържане на стари селектори до изтощаване лесно за следване. (SPF е обратното — два v=spf1 записа го анулират, ето защо ръководството за миграция на SPF е за обединяване.)

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

Ако провеждате тази миграция за клиент или работодател, затворете я с доказателства. Щом новият инструмент подписва и е aligned, пуснете отново безплатното сканиране и препратете оценения доклад на собственика на бизнеса: датирано, разбираемо доказателство, че смяната е оставила домейна напълно автентикиран. Това е артефактът, от който ще се нуждаят за подновяването на киберзастраховката и следващия въпросник за сигурност на доставчик — превръща „миграцията е готова” от твърдение в документ.

Проверете DKIM безплатно

Вижте дали селекторите на новия инструмент разрешават — и точно какво да поправите — частно и само за собственика.

Проверете домейна → · SPF се е счупил след смяна на доставчик → · Поправете DKIM → · Настройте DKIM в Google Workspace → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.