„DKIM подписът не е валиден” — Причините в реда за проверка (2026)

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

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

„DKIM подписът не е валиден” има пет чести причини, проверявани най-добре в ред: съдържание, модифицирано при транзит, съкратен запис на ключ, публикуван ключ, несъвпадащ с подписващия, грешен селектор и крехка канонизация. Само 10,092,481 от 261,086,232 оценени домейна (3.87%) притежават пълната триада SPF + DKIM + прилагащ DMARC, според census-а на Defaults.Exposed (2026-06-29).

Редът на поправката е важен, защото най-честата причина изобщо не е в DNS-а ви. Проверете първо какво е променило съобщението при транзит, след това работете навътре: целостта на записа на ключа, дали съвпада с това, с което пощенският сървър реално подписва, селектора и накрая настройките за подписване. Повечето невалидни подписи се поправят на стъпка едно или две.

Какво всъщност означава „DKIM подписът не е валиден”?

Всяко DKIM-подписано съобщение носи хедър DKIM-Signature, посочващ домейн (d=), селектор (s=), хеш на тялото на съобщението (bh=) и криптографски подпис върху хеша на тялото плюс избрани хедъри (b=). Получателят извлича публичния ключ от DNS на <selector>._domainkey.<domain>, преизчислява двата хеша и проверява подписа (RFC 6376). „Подписът не е валиден” е езикът на проверяващи и хедъри за: тази верификация е изпълнена и е неуспешна — ключът е намерен, но математиката не е дала резултат.

Последната клауза е диагностичното злато. Проверяващ, който не може да намери ключа ви, казва нещо различно — обикновено хедър като dkim=fail (no key for signature) — и това е проблем с селектор, разгледан в DKIM „no key for signature” — поправки на селектори и ротация. А проверяващ, преизчисляващ различен body hash, обикновено го казва изрично: body hash did not verify — Microsoft го докладва като dkim=fail (body hash did not verify), докато Gmail часто рендира същата диагноза като dkim=neutral (body hash did not verify). Така или иначе сочи към модификация на съдържанието, разгледана в „body hash did not verify” — какво е променило съобщението. Прочетете точната формулировка в хедъра Authentication-Results преди да докосвате каквото и да е: тя ви казва коя от петте причини имате.

Правилното реализиране е рядкост: само 51.84% от оценените домейни публикуват открит DKIM ключ в DNS изобщо, според census-а на Defaults.Exposed, а само 3.87% от 261 милиона оценени домейна комбинират SPF, DKIM и прилагаща DMARC политика — конфигурацията, която правилата за масови изпращачи сега приемат за даденост. Картината стъпка по стъпка е в модела за зрялост при приемане на SPF.

Какви са петте причини, в ред?

#	Причина	Признакът	Поправката
1	Съдържание, модифицирано при транзит — footer-и на шлюзове, правни disclaimer-и, тагове в темата на пощенски списъци	`body hash did not verify` в Authentication-Results;外部 пощата не минава, директната минава	*Подписвайте след* модификацията или спрете модифицирането — вижте ръководството за body hash**
2	Съкратен или повреден дълъг ключ	Публикуваният `p=` е видимо по-кратък от генерирания ключ; всеки получател не минава	Публикувайте отново 2048-bit ключа като правилно разделени TXT низове
3	Публикуваният ключ не съвпада с подписващия	Неуспехите започват веднага след ротация, миграция или смяна на доставчик	Копирайте отново текущия публичен ключ от подписващия; предпочитайте CNAME делегиране
4	Грешен или липсващ селектор	`no key for signature` — самото търсене не успява	Публикувайте селектора, действително използван от подписващия — вижте ръководството за селектори
5	Крехка канонизация или таг `l=`	Непостоянни неуспехи при незначително преформатирани съобщения	`c=relaxed/relaxed`; премахнете `l=` напълно

Причина 1 е маркирана, защото чупи подписи на съобщения, подписани перфектно. Шлюз за сигурност добавя disclaimer, footer за съответствие се поставя след подписване, пощенски списък добавя [listname] в темата — тялото или подписаните хедъри се променят, хешовете вече не съвпадат и подписът е невалиден без никаква грешка от страна на DNS-а ви. Ако неуспехите корелират с поща, минала през шлюз, списък или хоп за архивиране, започнете оттам.

Как да поправя „DKIM подписът не е валиден”?

Стартирайте безплатното сканиране на defaults.exposed преди да докосвате DNS. Показва дали публикуваният запис на ключ е налице, добре оформен и пълен — разграничавайки „DNS-ът ви е счупен” (причини 2–4) от „DNS-ът ви е наред, съобщението се променя” (причина 1) в една стъпка.
Прочетете хедъра Authentication-Results на неминаващо съобщение. body hash did not verify → причина 1, отидете на ръководството за body hash — обичайните заподозрени са footer-и и disclaimer-и на шлюзове, а поправката е да подписвате след модификацията. no key for signature → причина 4, отидете на ръководството за селектори. Обикновен неуспех на подпис → продължете.
Проверете публикувания ключ за съкращаване. Потърсете <selector>._domainkey.<yourdomain> като TXT (dig TXT selector._domainkey.example.com). 2048-bit RSA публичен ключ е по-дълъг от 255-символния лимит на единичен TXT низ, така че трябва да бъде публикуван като множество цитирани низове, свързвани от получателите — а уеб потребителските интерфейси на DNS доставчиците са известни с безшумното съкращаване на поставеното, повреждане на разделянето или инжектиране на whitespace и кавички в стойността p=. Сравнете символ по символ с ключа, генериран от подписващия; нашите ръководства за настройка на DKIM покриват спецификите за всеки доставчик.
Потвърдете, че публикуваният ключ съвпада с подписващия. След ротация на ключ, миграция на доставчик или повторно свързване с ESP, честа ситуация е подписващият да притежава нов частен ключ, докато DNS все още служи стария публичен ключ — всеки подпис се верифицира спрямо грешния ключ и не минава. Копирайте отново текущия запис от административната конзола на доставчика. По-добре: където доставчикът предлага CNAME делегиране, използвайте го — доставчикът ротира ключовете от своя страна и целият клас неуспехи изчезва. И никога не изтривайте стар селектор, докато трафикът, подписан с него, не се изтощи.
Поправете настройките за подписване, не само записа. Задайте канонизацията на c=relaxed/relaxed, която толерира пренаписването на whitespace и преформатирането на хедъри, законно правени от междинни сървъри; simple канонизацията не минава при промени, невидими за човек. И не използвайте тага l= за дължина на тялото: замислен е да пропуска footer-и, но позволява на всеки да добави съдържание към подписаното съобщение без да чупи подписа — реален вектор за атака — и все пак не оцелява при повечето модификации на шлюзове. Без l= е и по-сигурен, и по-надежден избор.
Направете ново сканиране, след това проверете alignment-а. Валиден подпис помага на DMARC само ако домейнът d= е aligned с вашия From домейн — подпис, валидиращ като d=yourcompany.gappssmtp.com, минава DKIM и все пак не минава DMARC. Ако сте в тази ситуация, вижте клопката с подразбиращия се подпис, след което се заемете с всичко останало, маркирано от сканирането на страницата за поправка на DKIM.

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

„DKIM подписът не е валиден” същото ли е като „body hash did not verify”? Body hash съобщението е един конкретен подслучай: тялото се е променило след подписване (footer-и, disclaimer-и, пренаписвания от списъци). „Подписът не е валиден” е общата присъда за всяка неуспешна верификация, включително лоши ключове и промени в хедъри — ето защо стъпка 2 по-горе е четене на хедъра, и ето защо случаят с body hash има собствено ръководство.

Невалиден DKIM подпис означава ли, че пощата ми ще бъде отхвърлена? Не само по себе си — получателите третират счупен подпис като липсващ. Щетата пристига чрез DMARC: ако SPF не минава с alignment, съобщението не минава DMARC и публикуваната политика се прилага. Към census-а от 2026-06-29, само 3.87% от 261,086,232 оценени домейна притежават SPF, DKIM и прилагаща DMARC политика заедно — но Gmail и Microsoft сега очакват точно това от изпращачите, така че счупен DKIM крак коства доставяемост дори преди отхвърляне.

Трябва ли да използвам 1024-bit или 2048-bit DKIM ключ? 2048-bit — 1024-bit ключовете са под текущите криптографски препоръки и някои получатели ги оценяват по-ниско. Уловката е чисто оперативна: 2048-bit ключ не се побира в един 255-символен TXT низ, така че трябва да бъде разделен правилно (причина 2 по-горе). CNAME делегирането до доставчика заобикаля изцяло проблема с разделянето.

DKIM минава при проверяващ, но DMARC все пак не минава — как? Почти сигурно е alignment: подписът е валиден, но домейнът d= (да речем, yourcompany.gappssmtp.com или yourtenant.onmicrosoft.com) не съвпада с вашия From домейн, така че DMARC не може да го използва. Активирайте персонализираното подписване за домейн на доставчика — пълното ръководство е в ръководството за клопката с подразбиращия се подпис.

Мога ли просто да изключа DKIM, ако продължава да не минава? Не — от мандатите за масови изпращачи от 2024, Gmail и Yahoo изискват DKIM за масови изпращачи, а прилагащата DMARC политика реалистично се нуждае от DKIM, защото SPF сам по себе си се чупи при препращане. Поправете подписа; причините по-горе са всички поправими за следобед.

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

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

Проверете домейна → · Ръководство „Body hash did not verify” → · Поправете DKIM → · Как оценяваме → · Само агрегирани данни. Данните се съхраняват и обработват в ЕС.