DKIM „Nincs kulcs az aláíráshoz": A selector és a kulcscsere javítása (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 „no key for signature” azt jelenti, hogy a vevő lekérdezte a DNS-rekordot, amelyre a DKIM-aláírása mutat — selector._domainkey.sajatdomain —, és nem talált kulcsot: vagy soha nem tették közzé, vagy törlés áldozata lett kulcscsere közben. Tegye közzé azt a selectort, amelyet az aláíró ténylegesen használ. A Defaults.Exposed által értékelt 261,086,232 domain közül mindössze 10,092,481 — 3.87% — teljesíti az SPF+DKIM+DMARC hármast.

A javítás egy DNS-rekord, amelyet egy fejlécből lehet megtalálni. Olvassa ki az s= és d= tageket egy valódi DKIM-Signature fejlécből, hogy megtudja, melyik selectorral írja alá a leveleit, tegye közzé (vagy javítsa) pontosan azt a rekordot, és részesítse előnyben a CNAME-delegálást, hogy a szolgáltató automatikusan forgassa a kulcsokat. Ezután cserélje a kulcsokat az alábbiakban leírt eljárás szerint — ez a hiba általában azt jelenti, hogy valaki túl korán törölte a régi selectort.

Mit jelent a „dkim no key for signature”?

Minden DKIM-aláírás két taget tartalmaz, amelyek megmondják a vevőnek, honnan töltse le a nyilvános kulcsot: d= (aláíró domain) és s= (selector). A vevő egy DNS-nevet kérdez le, amelyet belőlük épít fel — s._domainkey.d —, hogy megkapja a kulcsot. A „no key for signature” azt jelenti, hogy ez a lekérdezés üresen tért vissza: az aláírás létezik, de a benne hivatkozott kulcs nem.

A szöveg az Authentication-Results fejlécekben és DMARC-összesítő jelentésekben jelenik meg — a pontos megfogalmazás vevőnként eltér, de két változat számít:

Eredményszöveg (részlet, széles körben megfigyelt módon)	Mi történt valójában	Átmeneti?
`dkim=temperror (no key for signature)`	A DNS-lekérdezés sikertelen volt vagy időtúllépést adott — a vevő egyáltalán nem kapott választ	Igen — az újrapróbálkozások sokszor sikerülnek; csak akkor vizsgálja, ha tartós
`dkim=permerror (no key for signature)`	A DNS-lekérdezés sikerült, és a válasz „nincs ilyen rekord” volt — a selector ténylegesen hiányzik	Nem — a rekord addig hiányzik, amíg közzé nem teszi

Az egyszeri temperror csak DNS-időjárás. Egy permerror — vagy több napon és vevőn átívelő, ismétlődő temperror — azt jelenti, hogy az aláírásban hivatkozott rekord nincs a zónájában. Erről szól ez az útmutató.

A következmény: egy nem ellenőrizhető aláírás egyáltalán nem számít DKIM-nek, így a DMARC visszaesik az egyedüli SPF-re — és az SPF a továbbítás során tönkremegy. Ha az aláírás jelen van, de érvénytelen, nem pedig hiányzik (body hash, megrongált kulcs), ez más hiba — lásd: „DKIM signature not valid”.

Hogyan találom meg, melyik selectorral írja alá a levelemet?

Ne találgasson a szolgáltató dokumentációjából — olvassa ki egy valódi üzenetből:

Küldjön üzenetet az érintett rendszerből egy Ön által irányított postafiókba (Gmail-cím jól működik).
Nyissa meg a nyers forrást (Gmailben „Show original”, Outlookban „View message source”).
Keresse meg a DKIM-Signature: fejlécet, és olvassa ki két taget: s= a selector, d= az aláíró domain. Szemléltető példa: DKIM-Signature: v=1; a=rsa-sha256; d=sajatdomain.hu; s=mail2026; ...
A vevő által lekérdezett rekord: s._domainkey.d — itt mail2026._domainkey.sajatdomain.hu. Ellenőrizze maga is: dig TXT mail2026._domainkey.sajatdomain.hu +short. Üres válasz = a hiba minden vevőre valódi.
Ismételje meg küldési rendszerenként. Egy üzenet több DKIM-aláírást is hordozhat — postafiók-szolgáltató, hírlevéleszköz, helpdesk —, mindegyik saját s=/d= párral és rekorddal. Javítsa a hibásat, és jegyezze meg a d= értékét: csak az olyan aláírás segít a DMARC-nak, amelynek d=-je egyezik a Feladó domainjével.

Miért hiányzik a selector-rekord?

Négy ok fedi le szinte az összes ilyen hibát — ellenőrizze ebben a sorrendben:

Soha nem tették közzé. Az aláírót bekapcsolták (vagy alapértelmezés szerint be volt kapcsolva) egy olyan selectorral, amelyet senki nem adott hozzá a DNS-hez. Általános az új eszközöknél és átjáróknál, amelyek váratlanul aláírnak.
Kulcscsere közben törölték. Valaki „kitakarította” a régi selectort, miközben az azzal aláírt üzenetek még úton, újrapróbálkozásra várakozva vagy továbbítva voltak. Ezek az üzenetek már s=régi értékkel vannak aláírva; a régi._domainkey törlése visszafelé hatva érvényteleníti mindegyiket.
A DNS-kezelő panel megrongálta a CNAME-célt. Sok szolgáltató CNAME-en keresztül delegál (s1._domainkey.sajatdomain.hu → s1.domainkey.u123.esp.com), és sok DNS-panel csendesen hozzáfűzi a zónát a célhoz — tárolja a s1.domainkey.u123.esp.com.sajatdomain.hu értéket, amely semmire nem oldódik fel. Ellenőrizze a célt: dig CNAME s1._domainkey.sajatdomain.hu +short. Ugyanez a csapda váltja ki az eszközcsere utáni migrációknál is — lásd: DKIM hibázik az e-mail-eszközök váltása után.
A szolgáltató forgatta a kulcsokat, a zónája nem. A statikus TXT-rekordként beillesztett (a CNAME-ek helyett) szolgáltatói kulcs a tervezett kulcscsere után árváva marad — az aláíró egy olyan selectorra vált, amelyet Ön soha nem tett közzé. A népszámlálás 261 millió domainjéből mindössze 51.84% mutat felderíthető DKIM-kulcsot a vizsgálat idején (adatok: 2026-06-29).

Hogyan javítsam a „no key for signature” hibát?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl a DNS-hez. Megmutatja az élő DKIM-, SPF- és DMARC-rekordokat, és azt, amit a vevők ténylegesen látnak — beleértve azt is, hogy a selector feloldódik-e és a CNAME-cél sérült-e meg — egyetlen lépésben.
Tegye közzé azt a selectort, amelyet az aláíró ténylegesen használ — az s= értékét a fejlécből, nem egy régi leírásból. Kérje le a rekordot a szolgáltatói adminisztrációs konzolból (Google Workspace DKIM-beállítás · Microsoft 365 DKIM-beállítás), és adja hozzá pontosan a s._domainkey.sajatdomain.hu névhez.
Részesítse előnyben a CNAME-delegálást a TXT-kulcs beillesztése helyett. Ha a szolgáltató DKIM CNAME-eket kínál, használja azokat: a kulcs az ő zónájukban él, tehát ők forgatják anélkül, hogy Önnek újra kellene érintenie a DNS-t — a 4. ok lehetetlenné válik. A hírlevélplatformok szinte kivétel nélkül így működnek; lásd: Mailchimp/Brevo/Klaviyo e-mailek megbuknak a DMARC-on.
Ellenőrizze a panelen kívülről. dig TXT s._domainkey.sajatdomain.hu +short (vagy delegált selectorok esetén dig CNAME …) egy hálózaton kívüli gépről. A panel által mutatott rekord semmit sem bizonyít, ha a zóna mást szolgáltat ki.
Futtassa újra a vizsgálatot, és küldjön el ismét egy tesztüzenetet. Az Authentication-Results-nek most dkim=pass értéket kell mutatnia. Majd dolgozza végig mindazt, amit a vizsgálat megjelöl a DKIM javítása oldalon — egy átmenő, de a Feladó domainnel nem igazodó aláírás még mindig megbukik a DMARC-on.

Hogyan cseréljek DKIM-kulcsokat e hiba okozása nélkül?

A kulcscsere az, ahol a működő konfigurációk tönkremennek. A megelőző szabály: egy selectort csak azután töröl, hogy az azzal aláírt utolsó üzenet is elfogyott — soha nem az átváltáskor. Az aláírt levelek tovább élnek, mint gondolná: az újrapróbálkozási sorok napokig futnak, és a továbbított üzeneteket minden áthelyezéskor újra ellenőrzik.

Lépés	Művelet	Kapuőr a következő lépés előtt
1. Hozzáadás	Tegye közzé az új selectort (`s2._domainkey…`) a régi mellé	A `dig` megerősíti, hogy kívülről feloldódik
2. Átváltás	Irányítsa az aláírót az új selectorra	A tesztüzenet `s=s2`-t és `dkim=pass`-t mutat
3. Várakozás	Hagyja a régi selectort közzétéve, amíg az úton lévő, várakozó és továbbított forgalom le nem cseng	Legalább 7 nap; figyelje a DMARC-összesítő jelentéseket, amíg a régi selector el nem tűnik
4. Kivonás	Távolítsa el a régi kulcsot — vagy inkább tegye újra közzé üres `p=` taggel: „kivont”, nem „soha nem létezett”	Soha ne kezdje az átváltáskor — az idő előtti törlés a „no key for signature” hiba #1 oka

CNAME-delegálással a szolgáltató pontosan ezt az eljárást futtatja le a saját zónájában, és Ön soha nem látja — ez a delegálás leglényegesebb érve.

Gyakran ismételt kérdések

A „no key for signature” temperror vagy permerror? Mindkét szöveg létezik: a temperror egy sikertelen vagy időtúllépett DNS-lekérdezés — átmeneti, sokszor eltűnik az újrapróbálkozásra —, míg a permerror azt jelenti, hogy a DNS „nincs ilyen rekord” választ adott. Egy több vevőn ismétlődő temperror általában szintén ténylegesen hiányzó rekordnak bizonyul. Ellenőrizze dig-gel, és bízzon a válaszban, ne a feliratban.

Ez a hiba azt jelenti, hogy valaki hamisítja a domainemét? Nem — a hamisító nem írna alá az Ön selectorával. Azt jelenti, hogy saját levelei olyan aláírást hordoznak, amelyet a vevők nem tudnak ellenőrizni, tehát aláíratlannak számít, és a DMARC egyedül az SPF-re támaszkodik. A teljes, igazított hitelesítés ritka: a Defaults.Exposed népszámlálása szerint (adatok: 2026-06-29) mindössze 10,092,481 domain teljesítette az SPF+DKIM+DMARC hármast 261,086,232 közül (3.87%).

Törölhetem a régi selectort, amint az új működik? Nem azonnal. Az azzal aláírt üzenetek még az újrapróbálkozási sorokban és a továbbítási útvonalakon vannak; a kulcs törlése visszafelé hatva érvényteleníti őket. Tartsa meg a régi rekordot legalább egy hétig, figyelje a DMARC-jelentéseket, amíg a régi selector el nem tűnik, majd vonja ki — lehetőleg üres p= értékkel, nem törléssel.

A szolgáltatóm ellenőrzője szerint a DKIM be van állítva, de a vevők még mindig nem találják a kulcsot. Miért? Szinte mindig a CNAME-cél csapdája: a DNS-panel hozzáfűzte a zónát a célhoz (…esp.com.sajatdomain.hu), tehát a rekord létezik, de sehová nem mutat. A dig CNAME selector._domainkey.sajatdomain.hu +short betűről betűre megmutatja a tárolt célt — hasonlítsa össze karakterről karakterre azzal, amit a szolgáltató kért.

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 miután a selector feloldódik, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelven, a DKIM ellenőrzése működik. 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 — egy működő kontroll bizonyítéka, nem csak egy lezárt jegy.

Ellenőrizze a DKIM-jét ingyen

Tekintse meg, hogy a selectorai feloldódnak-e — és pontosan mit kell javítani —, privát módon és csak a tulajdonosra vonatkozóan.

Ellenőrizze a domainjét → · „DKIM signature not valid” → · DKIM javítása → · DKIM beállítása Google Workspace-en → · Csak összesített adatok. Az adatokat az EU-ban tároljuk és dolgozzuk fel.