DKIM „No Key for Signature”: Поправки на селектори и ротация (2026)

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

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

„No key for signature” означава, че получателят е запитал DNS записа, към който DKIM подписът ви сочи — selector._domainkey.yourdomain — и не е намерил ключ: никога не е публикуван, или е изтрит по средата на ротация. Публикувайте селектора, който подписващият действително използва. Само 10,092,481 домейна — 3.87% — завършват триадата SPF+DKIM+DMARC, според census-а на Defaults.Exposed от 261,086,232 оценени домейна.

Поправката е един DNS запис, намерен в един хедър. Прочетете таговете s= и d= от реален хедър DKIM-Signature, за да разберете с кой селектор е подписана пощата ви, публикувайте (или поправете) точно този запис и предпочитайте CNAME делегиране, за да може доставчикът да ротира ключовете за вас. След това ротирайте по наръчника по-долу — тази грешка обикновено означава, че някой е изтрил стар селектор твърде рано.

Какво означава „dkim no key for signature”?

Всеки DKIM подпис носи два тага, казващи на получателя откъде да вземе публичния ключ: d= (домейн за подписване) и s= (селектор). Получателят запитва едно DNS ime, построено от тях — s._domainkey.d — за ключа. „No key for signature” означава, че тази заявка е върнала нищо: подписът съществува, но ключът, който той посочва, не.

Формулировката се появява в хедърите Authentication-Results и DMARC агрегираните доклади — точното изписване варира при различните получатели, но два варианта имат значение:

Резултатен низ (фрагмент, широко наблюдаван)	Какво реално се е случило	Временно?
`dkim=temperror (no key for signature)`	DNS заявката е неуспешна или е изтекла — получателят не е могъл да получи отговор	Да — повторните опити често минават; разследвайте само ако е постоянно
`dkim=permerror (no key for signature)`	DNS заявката е успяла и отговорът е „няма такъв запис” — селекторът наистина липсва	Не — записът липсва, докато не го публикувате

Еднократна temperror е DNS „лошо време”. Permerror — или temperror, повтарящо се при различни получатели с дни — означава, че записът, към който подписът сочи, не е в зоната ви. Това е настоящото ръководство.

Последицата: неверифицируем подпис се брои като никакъв DKIM, така че DMARC пада назад само на SPF — а SPF се чупи при препращане. Ако подписът е налице, но невалиден, а не липсващ (body hash, повреден ключ), това е различен неуспех — вижте „DKIM подписът не е валиден”.

Как да разбера с кой селектор е подписана пощата ми?

Не познавайте от документацията на доставчика — прочетете го от реално съобщение:

Изпратете съобщение от засегнатата система до пощенска кутия, която контролирате (Gmail адрес работи добре).
Отворете суровия код („Show original” в Gmail, „View message source” в Outlook).
Намерете хедъра DKIM-Signature: и прочетете два тага: s= е селекторът, d= е домейнът за подписване. Илюстративен пример: DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
Записът, запитван от получателя, е s._domainkey.d — тук mail2026._domainkey.yourdomain.com. Проверете сами: dig TXT mail2026._domainkey.yourdomain.com +short. Празен отговор = грешката е реална за всеки получател.
Повторете за всяка изпращаща система. Едно съобщение може да носи множество DKIM подписи — доставчик на пощенска кутия, инструмент за бюлетини, helpdesk — всеки с собствена двойка s=/d= и запис. Поправете неминаващия и отбележете d=: само подпис, чийто d= съвпада с вашия From домейн, помага на DMARC.

Защо селекторният запис липсва?

Четири причини обясняват почти всички тези грешки — проверявайте ги в този ред:

Никога не е публикуван. Подписващият е бил включен (или включен по подразбиране) с селектор, който никой не е добавил към DNS. Честа ситуация при нови инструменти и шлюзове, подписващи неочаквано.
Изтрит е по средата на ротация. Някой е „почистил” стария селектор, докато съобщения, подписани с него, все още са в транзит, опашки за повторен опит или чакат препращане. Тази поща вече е подписана с s=old; изтриването на old._domainkey ретроактивно чупи всяко едно от тези съобщения.
DNS потребителският интерфейс е повредил CNAME цел. Много доставчици делегират чрез CNAME (s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com), и много DNS панели безшумно прикачват зоната ви към целта — съхранявайки s1.domainkey.u123.esp.com.yourdomain.com, което не разрешава до нищо. Верифицирайте целта: dig CNAME s1._domainkey.yourdomain.com +short. Същата клопка захапва при миграции на инструменти — вижте DKIM не минава след смяна на имейл инструменти.
Доставчикът е ротирал, зоната ви — не. Ключ на доставчик, поставен като статичен TXT запис (вместо CNAME), е осиротял от тяхната планирана ротация — подписващият се е преместил към селектор, който никога не сте публикували. Само 51.84% от 261 милиона домейна в census-а представят открит DKIM ключ при сканиране (данни към 2026-06-29).

Как да поправя „no key for signature”?

Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Чете живите DKIM, SPF и DMARC записи и показва какво виждат получателите — включително дали селекторът разрешава и дали CNAME цел е повредена.
Публикувайте селектора, който подписващият действително използва — стойността s= от хедъра, а не тази в стар наръчник. Вземете записа от административната конзола на доставчика (настройка на DKIM в Google Workspace · настройка на DKIM в Microsoft 365) и го добавете точно на s._domainkey.yourdomain.com.
Предпочитайте CNAME делегиране пред поставяне на TXT ключ. Ако доставчикът предлага DKIM CNAME записи, използвайте ги: ключът живее в тяхната зона, така че те го ротират без да докосвате DNS отново — причина 4 става невъзможна. Платформите за бюлетини почти всички работят по този начин; вижте Mailchimp/Brevo/Klaviyo имейли, неминаващи DMARC.
Верифицирайте от извън панела. dig TXT s._domainkey.yourdomain.com +short (или dig CNAME … за делегирани селектори) от машина извън мрежата ви. Показването на записа от панела не доказва нищо, ако зоната служи нещо различно.
Направете ново сканиране и изпратете отново тестовото съобщение. Authentication-Results трябва сега да чете dkim=pass. След това се заемете с всичко останало, маркирано от сканирането на страницата за поправка на DKIM — минаващ подпис, несъвпадащ с вашия From домейн, все пак не минава DMARC.

Как да ротирам DKIM ключове без да причиня тази грешка?

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

Стъпка	Действие	Портал преди следващата стъпка
1. Добавяне	Публикувайте новия селектор (`s2._domainkey…`) заедно со стария	`dig` потвърждава, че разрешава отвън
2. Смяна	Насочете подписващия към новия селектор	Тестово съобщение показва `s=s2` и `dkim=pass`
3. Изчакване	Оставете стария селектор публикуван, докато в транзит, на опашка и препратеният трафик се изтощи	≥ 7 дни; следете DMARC агрегираните доклади, докато старият селектор спре да се появява
4. Оттегляне	Премахнете стария ключ — или по-добре, повторно публикувайте с празен таг `p=`: „оттеглен”, а не „никога не е съществувал”	Никога не започвайте това при смяната — преждевременното изтриване е причина №1 за „no key for signature”

При CNAME делегиране, доставчикът изпълнява точно този наръчник в собствената си зона и вие никога не го виждате — най-силният аргумент за делегиране.

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

„No key for signature” temperror ли е или permerror? И двата низа съществуват: temperror е DNS заявка, неуспешна или изтекла — временна, часто изчезваща при повторен опит — докато permerror означава, че DNS е отговорил „няма такъв запис”. Temperror, повтаряща се при различни получатели, обикновено се оказва наистина липсващ запис. Проверете с dig и се доверете на отговора, а не на етикета.

Тази грешка означава ли, че някой спуфва домейна ми? Не — спуфърът не би подписал с вашия селектор. Означава, че вашата собствена поща носи подпис, който получателите не могат да верифицират, така че се брои за неподписана и DMARC разчита само на SPF. Пълното, aligned автентикиране е рядко: само 10,092,481 от 261,086,232 домейна (3.87%) са завършили триадата SPF+DKIM+DMARC в census-а на Defaults.Exposed (данни към 2026-06-29).

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

Проверката на доставчика казва, че DKIM е конфигуриран, но получателите все пак съобщават за lipsa ключ. Как? Почти винаги е клопката с CNAME целта: DNS панелът ви е прикачил зоната към целта (…esp.com.yourdomain.com), така че записът съществува, но сочи никъде. dig CNAME selector._domainkey.yourdomain.com +short показва съхранената цел дословно — сравнете я символ по символ с това, което доставчикът е поискал.

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

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

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

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

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