„DKIM signature not valid" — Az okok abban a sorrendben, amelyben ellenőrizni kell (2026)

Közzétéve 2026-07-08

Adatok: 2026-06-29 · 7. módszertan. Összesített népszámlálási adatok 261 millió értékelt domain alapján. Lásd: hogyan értékelünk.

A „DKIM signature not valid” hibának öt általános oka van, amelyeket a legjobb ebben a sorrendben ellenőrizni: szállítás közbeni tartalommódosítás, csonkított kulcsrekord, az aláíróval nem egyező közzétett kulcs, rossz selector, és törékeny kanonizáció. A Defaults.Exposed népszámlálása szerint (2026-06-29) 261,086,232 értékelt domainből mindössze 10,092,481 (3.87%) rendelkezik a teljes SPF + DKIM + érvényesítő DMARC hármassal.

A javítás sorrendje számít, mert a leggyakoribb ok egyáltalán nem a DNS-ben van. Először ellenőrizze, mi módosította az üzenetet szállítás közben, majd haladjon befelé: a kulcsrekord integritása, hogy egyezik-e azzal, amivel a levelezőszerver valójában aláír, a selector, végül az aláírási beállítások. A legtöbb érvénytelen aláírást az első vagy második lépésnél orvosolják.

Mit jelent ténylegesen a „DKIM signature not valid”?

Minden DKIM-aláírt üzenet tartalmaz egy DKIM-Signature fejlécet, amely megnevez egy domaint (d=), egy selectort (s=), az üzenet törzsének kivonatát (bh=), és egy kriptográfiai aláírást a törzskivonat plusz a kiválasztott fejlécek felett (b=). A vevő lekéri a nyilvános kulcsát a DNS-ből a <selector>._domainkey.<domain> névről, újraszámolja mindkét kivonatot, és ellenőrzi az aláírást (RFC 6376). A „Signature not valid” az ellenőrző és a fejléc szóhasználata arra, hogy: az ellenőrzés lefutott és megbukott — a kulcsot megtalálta, de a matematika nem stimmelt.

Ez az utóbbi kitétel az értékes diagnosztikai adat. Az a vevő, amely nem találja a kulcsát, mást mond — általában egy fejlécet mint dkim=fail (no key for signature) —, és ez selector-probléma, amelyet a DKIM „no key for signature” — selector és kulcscsere javítása útmutató fed le. Egy vevő, amely eltérő body hash-t számol ki, általában ezt explicit módon jelzi: body hash did not verify — a Microsoft dkim=fail (body hash did not verify) értékként jelenti, míg a Gmail ugyanezt dkim=neutral (body hash did not verify) értékként jeleníti meg. Mindkét esetben tartalommódosításra utal, amelyet a „body hash did not verify” — mi módosította az üzenetét útmutató ismertet. Olvassa el a pontos szöveget az Authentication-Results fejlécben, mielőtt bármit is megérint: megmondja, melyik az öt ok közül.

Ezt helyesen megcsináltuk nagyon ritkán: a Defaults.Exposed népszámlálása szerint az értékelt domaineknek mindössze 51.84%-a tesz egyáltalán közzé felderíthető DKIM-kulcsot a DNS-ben, és a 261 millió értékelt domain mindössze 3.87%-a kombinálja az SPF-et, a DKIM-et és egy érvényesítő DMARC-szabályzatot — azt a konfigurációt, amelyet a tömeges küldőkre vonatkozó szabályok most feltételeznek. A szakaszos képet az SPF-bevezetési érettségi modell mutatja.

Melyek az öt ok, sorrendben?

#	Ok	Az árulkodó jel	A javítás
1	Szállítás közbeni tartalommódosítás — átjáró láblécek, jogi nyilatkozatok, levelezőlista tárgycímkék	`body hash did not verify` az Authentication-Results fejlécben; a külső levél megbukik, a közvetlen levél átmegy	*Aláírjon a módosítás után, vagy hagyja abba a módosítást — lásd: body-hash útmutató*
2	Csonkított vagy megrongált hosszú kulcs	A közzétett `p=` láthatóan rövidebb az Ön által generált kulcsnál; minden vevő megbukik	Tegye újra közzé a 2048 bites kulcsot megfelelően feldarabolt TXT-karakterláncokként
3	A közzétett kulcs nem egyezik az aláíróval	A hibák egy kulcscsere, migráció vagy szolgáltatóváltás után kezdődnek	Másolja újra az aktuális nyilvános kulcsot az aláírótól; részesítse előnyben a CNAME-delegálást
4	Rossz vagy hiányzó selector	`no key for signature` — maga a keresés megbukik	Tegye közzé azt a selectort, amelyet az aláíró ténylegesen használ — lásd: selector útmutató
5	Törékeny kanonizáció vagy `l=` tag	Időszakos hibák triviálisan újraformázott üzeneteken	`c=relaxed/relaxed`; távolítsa el teljesen az `l=`-t

Az 1. ok azért van kiemelve, mert tönkreteszi a tökéletesen aláírt üzenetek aláírásait. Egy biztonsági átjáró hozzáfűz egy nyilatkozatot, egy megfelelőségi lábléc az aláírás után kerül rá, egy levelezőlista hozzáadja a [listanév]-et a tárgyhoz — a törzs vagy az aláírt fejlécek megváltoznak, a kivonatok már nem egyeznek, és az aláírás érvénytelen lesz, anélkül hogy a DNS-e hibázna. Ha a hibák az átjárón, listán vagy archiváló hopon átment levelekkel korrelálnak, ott kezdje.

Hogyan javítsam a „DKIM signature not valid” hibát?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl a DNS-hez. Megmutatja, hogy a közzétett kulcsrekord jelen van-e, jól formázott és teljes-e — egyetlen lépésben elválasztja a „DNS hibás” (2–4. ok) esetet a „DNS jó, az üzenet módosul” (1. ok) esettől.
Olvassa el az Authentication-Results fejlécet egy megbukott üzenetből. body hash did not verify → 1. ok, menjen a body-hash útmutatóhoz — a szokásos gyanúsítottak az átjáró láblécek és nyilatkozatok, és a javítás az aláírás módosítás utánra tolása. no key for signature → 4. ok, menjen a selector útmutatóhoz. Egyszerű aláírási hiba → folytassa.
Ellenőrizze a közzétett kulcs csonkítását. Keresse meg a <selector>._domainkey.<sajatdomain> TXT-rekordját (dig TXT selector._domainkey.pelda.hu). Egy 2048 bites RSA nyilvános kulcs hosszabb egy TXT-karakterlánc 255 karakteres korlátjánál, tehát több, idézőjelbe tett karakterláncként kell közzétenni, amelyeket a vevők összefűznek — és a DNS-szolgáltatói webes felületek hírhedten csendesen csonkítják a beillesztést, elrontják a felosztást, vagy szóközöket és idézőjeleket fecskendeznek a p= értékbe. Hasonlítsa össze karakterről karakterre az Ön által generált kulccsal; a DKIM-beállítási útmutatóink ismertetik a szolgáltatónkénti sajátosságokat.
Erősítse meg, hogy a közzétett kulcs egyezik az aláíróval. Kulcscsere, szolgáltatói migráció vagy ESP-újracsatlakozás után könnyen megtörténhet, hogy az aláíró egy új privát kulcsot tart, miközben a DNS még a régi nyilvános kulcsot szolgálja ki — minden aláírás a rossz kulcs ellen ellenőriz és megbukik. Másolja újra az aktuális rekordot a szolgáltatói adminisztrációs konzolból. Még jobb: ahol a szolgáltató CNAME-delegálást kínál, használja azt — a szolgáltató a saját oldalán forgatja a kulcsokat, és ez az egész hibaosztály eltűnik. Soha ne töröljön régi selectort, amíg az azzal aláírt forgalom le nem csengett.
Javítsa az aláírási beállításokat, ne csak a rekordot. Állítsa be a kanonizációt c=relaxed/relaxed értékre, amely tolerálja a közbülső szerverek által jogszerűen elvégzett szóköz-újracsomagolást és fejléc-újrahajtogatást; a simple kanonizáció olyan változásokon bukik meg, amelyeket még az ember sem tud észrevenni. Ne használja az l= body-length taget: azt a célt szánták, hogy a lábléceknél átengedjen, de lehetővé teszi bárki számára, hogy tartalmat fűzzön az aláírt üzenethez az aláírás megszakítása nélkül — valódi támadási vektor —, és még ekkor sem éli túl a legtöbb átjárómódosítást. Az l= nélküli megoldás egyszerre biztonságosabb és megbízhatóbb.
Futtassa újra a vizsgálatot, majd ellenőrizze az igazítást. Egy érvényes aláírás csak akkor segít a DMARC-nak, ha a d= domain igazodik a Feladó domainjéhez — a d=sajatvallalat.gappssmtp.com értékkel érvényes aláírás átmegy a DKIM-en, és még mindig megbukik a DMARC-on. Ha ez az Ön esete, lásd: az alapértelmezett aláírás csapdája, majd dolgozza végig mindazt, amit a vizsgálat megjelöl a DKIM javítása oldalon.

Gyakran ismételt kérdések

A „DKIM signature not valid” ugyanaz, mint a „body hash did not verify”? A body-hash üzenet egy konkrét részeset: a törzs megváltozott az aláírás után (láblécek, nyilatkozatok, lista-átírások). A „Signature not valid” a gyűjtőítélet minden sikertelen ellenőrzésre, beleértve a rossz kulcsokat és a fejlécmódosításokat — ezért a fenti 2. lépés a fejléc elolvasása, és ezért van a body-hash esetnek saját útmutatója.

Egy érvénytelen DKIM-aláírás azt jelenti, hogy a leveleimet elutasítják? Nem önmagában — a vevők egy megszakadt aláírást ugyanúgy kezelnek, mint a hiányosat. A kár a DMARC-on keresztül jön: ha az SPF sem megy át igazítással, az üzenet megbukik a DMARC-on, és a közzétett szabályzata érvényes rá. A 2026-06-29 népszámlálás szerint az értékelt 261,086,232 domain mindössze 3.87%-a rendelkezik együttesen SPF-fel, DKIM-mel és érvényesítő DMARC-szabályzattal — de a Gmail és a Microsoft most pontosan ezt várja el a küldőktől, tehát egy törött DKIM-igazítás az elutasítás előtt is csökkenti a kézbesíthetőséget.

1024 bites vagy 2048 bites DKIM-kulcsot használjak? 2048 biteset — az 1024 bites kulcsok a jelenlegi kriptográfiai ajánlások alatt vannak, és néhány vevő lepontozza őket. A probléma kizárólag operatív: egy 2048 bites kulcs nem fér el egyetlen 255 karakteres TXT-karakterláncban, tehát megfelelően kell feldarabolni (fenti 2. ok). A CNAME-delegálás a szolgáltatóhoz teljes mértékben megkerüli a felosztási problémát.

A DKIM-em átmegy egy ellenőrzőn, de a DMARC még mindig megbukik — hogyan? Majdnem biztosan igazítás: az aláírás érvényes, de a d= domainje (mondjuk sajatvallalat.gappssmtp.com vagy sajatberlő.onmicrosoft.com) nem egyezik a Feladó domainjével, tehát a DMARC nem tudja felhasználni. Engedélyezze a szolgáltatója egyéni domainre szóló aláírását — a teljes útmutatót az alapértelmezett aláírás csapdája útmutatója tartalmazza.

Egyszerűen ki tudom-e kapcsolni a DKIM-et, ha folyamatosan megbukik? Nem — a 2024-es tömeges küldőre vonatkozó előírások óta a Gmail és a Yahoo megköveteli a DKIM-et a nagy forgalmú küldőktől, és egy érvényesítő DMARC-szabályzat reálisan szükségessé teszi a DKIM-et, mert a csak SPF-re támaszkodás a továbbítás során tönkremegy. Javítsa az aláírást; a fenti okok mind javíthatók egy délután alatt.

Küldje el a tulajdonosnak a jelentést

Ha egy ügyfélért vagy munkaadójáért végzi a javítást, zárja le a kört bizonyítékkal. Futtassa újra az ingyenes vizsgálatot a módosítások után, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelven, a DKIM zöldet mutat. Ez az a dokumentum, amelyre szüksége lesz a kibervédelmi biztosítás megújításakor és a következő szállítói biztonsági kérdőívnél — különbség van a „javítottam egy DNS-dolgot” és egy dokumentált előtte-utána kép között, amely azt mutatja, hogy a domain hitelesíti a leveleit.

Ellenőrizze a domainjét → · „Body hash did not verify” útmutató → · DKIM javítása → · Hogyan értékelünk → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.