A DKIM meghibásodik az e-mail-eszközök váltása után: A CNAME és selector migrációs útmutató (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 két mechanikus okból hibásodik meg eszközváltás után: a DNS-panel megrongálta az új eszköz CNAME-céljait — általában hozzáfűzve a saját zónáját —, vagy a régi eszköz selectorait eltávolították, mielőtt a forgalom lecsengett volna. A Defaults.Exposed 261,086,232 értékelt domainre kiterjedő népszámlálása szerint mindössze 3.87% — 10,092,481 domain — teljesíti az SPF+DKIM+DMARC hármast.

A javítás sorrendje: vizsgálja meg a domainjét, majd ellenőrizze minden új CNAME tárolt célját a dig segítségével — a saját domainjére végződő cél az árulkodó jel. Javítsa a rekordokat az autoritatív névszervereken, erősítse meg, hogy az új eszköz aláír és átmegy, mielőtt valódi forgalmat irányít rajta keresztül, és tartsa közzétéve a régi eszköz selectorait, amíg a forgalom le nem csengett.

Miért hibásodott meg a DKIM az eszközök váltásakor?

Magával a DKIM-mel semmi sem változott — a selectorai igen. A régi eszköz a saját selectoraival írt alá; az új más selectorokat használ, amelyeket általában két-három, a beilleszkedés során hozzáadott CNAME-rekordon keresztül delegálnak. Négy buktatót okozza szinte minden migrációs DKIM-hibát:

A DNS-panel hozzáfűzte a zónát a CNAME-célhoz. Sok panel minden beillesztett gépnevet relatívnak kezel, és csendesen a cél.szolgaltato.com.sajatdomain.hu értéket tárolja a cél.szolgaltato.com helyett. A rekord létezik, a panel zöld pipát mutat, és semmire sem oldódik fel.
Záró pont összezavarodás. Néhány panel *megköveteliua a záró pontot (cél.szolgaltato.com.), hogy az „abszolút — ne fűzze hozzá a zónámat” értelmet hordozzon; mások érvénytelenként elutasítják a pontot, és maguk kezelik az abszolútságot. Ugyanaz a beillesztett érték az egyik panelnél helyes, a másikban megrongálva.
A régi eszköz selectorait az átváltás napján törölték. A régi eszköz által már aláírt levelek napokig ülnek az újrapróbálkozási sorokban és a továbbítási útvonalakon; a selectorainak eltávolítása — vagy a régi fiók bezárása, amely elvágja a delegált CNAME-eket — visszafelé hatva érvényteleníti ezeket a leveleket.
A helytelen névszervereken ellenőrzött. Ha a migráció névszerverváltást is tartalmazott, a javított rekordok az egyik NS-készletben létezhetnek, miközben a vevők még a másikat kérdezik.

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).

Ugyanez a migráció általában SPF-törmeléket is hagy maga után — 1,013,416 domain, körülbelül minden 138-ból egy, amely SPF-et kísérel meg, két v=spf1 rekordot futtat, ami a klasszikus jele annak, hogy egy szolgáltatóváltás rekordot adott hozzá ahelyett, hogy egyet összevont volna. Az átköltözés e részének saját útmutatója van: Az SPF leállt az e-mail-szolgáltató váltása után.

Hogyan ismerem fel a megrongált CNAME-rekordot?

Ne bízzon a panelben — kérdezze meg a DNS-t, mit tárolt valójában. Kérdezze le a CNAME-célt minden selectorhoz, amelyet az új eszköz megadott. Szemléltető példa, egy SendGrid-stílusú delegált selectort utánozva (az Ön szolgáltatójának célalakja eltérhet):

$ dig CNAME s1._domainkey.sajatdomain.hu +short
s1.domainkey.u1234567.wl123.sendgrid.net.sajatdomain.hu.

A szolgáltató s1.domainkey.u1234567.wl123.sendgrid.net értéket kért — de a tárolt cél .sajatdomain.hu-ra végződik. A panel hozzáfűzte a zónát; ez a név semmire sem oldódik fel, tehát a vevők nem találnak kulcsot. Az egészséges verzió:

$ dig CNAME s1._domainkey.sajatdomain.hu +short
s1.domainkey.u1234567.wl123.sendgrid.net.

(A dig kimenetben egyetlen záró pont normális — teljesen minősített nevet jelöl.) Ha a cél helyes, kövesse egy ugróponttal: a dig TXT s1._domainkey.sajatdomain.hu +short értéknek a szolgáltató kulcsát kell visszaadnia. Üres válasz helyes CNAME-mel azt jelenti, hogy a probléma a delegálás szolgáltatói oldalán van — fejezze be az ellenőrzési lépésüket, vagy lásd a DKIM „no key for signature” útmutatót a selector-szintű diagnózishoz.

A migrációs eljárás: előtte, közben, utána

A hiba általában nem a rekordokban van — hanem a sorrendben. A DKIM-migrációk az átváltáskor mennek tönkre, mert az ellenőrzés az átváltás után történik, mikor a valódi levelek már hibásak.

Fázis	Mit kell tenni	Kapuőr a továbblépés előtt
Az átváltás előtt	Adja hozzá az új eszköz DKIM CNAME-jeit (és bounce-domain rekordokat), majd bizonyítsa őket: `dig`-gel ellenőrizze minden CNAME tárolt célját a hálózaton kívülről, fejezze be az eszköz saját ellenőrzési lépését, és küldjön tesztet az új eszközön keresztül egy Ön által ellenőrzött postafiókba	A tesztüzenet `dkim=pass` értéket mutat, ahol `d=` = saját domainje — soha ne irányítson valódi levelet egy el nem ellenőrzött eszközön keresztül
Az átváltás napja	Irányítsa a valódi forgalmat az új eszközre. Ne érintsen semmit, ami a régi eszközhöz tartozik: hagyja élőn a selectorait, CNAME-jeit és fiókját	Az új eszköz levelei átmennek a valódi vevőknél; a régi eszköz továbbra is átmegy mindannak, ami még rajta folyik
A lecsengés után	Figyelje a DMARC-összesítő jelentéseket, amíg a régi eszköz selectorai el nem tűnnek (az újrapróbálkozási sorok és a továbbítások napokig futnak — számítson egy hétre vagy tovább), majd vonja ki a rekordjait és fiókját	A régi selectorok legalább 7 napig hiányoznak a jelentésekből az eltávolítás előtt

A félkövér sor az, ahol a migrációkat megmentik vagy elveszítik: minden benne lévő ellenőrzést el lehet végezni napokkal az átváltás előtt, a valódi levelekre nulla kockázattal. A selector-kivonás mechanizmusa — beleértve azt, miért jobb egy üres p= értékkel újra közzétenni a törlésnél — a kulcscsere eljárásában van ismertetve; ez a táblázat az eszközváltás szekvenálásáról szól.

Hogyan javítsam a DKIM-et az átváltás után?

Futtassa az ingyenes vizsgálatot a defaults.exposed oldalon, mielőtt hozzányúl a DNS-hez. Beolvassa az élő rekordokat, és megmutatja, mit látnak a vevők ténylegesen — beleértve a zónához hozzáfűzött CNAME-célokat és a nem feloldódó selectorokat.
Sorolja fel az új eszköz által elvárt DKIM-rekordokat. Az adminisztrációs konzolból — a postafiók-szolgáltatóknál a Google Workspace és a Microsoft 365 beállítási útmutatók mutatják, hol; a hírlevél- és CRM-eszközök a domain-hitelesítés alatt listázzák a CNAME-jeiket (lásd: Mailchimp/Brevo/Klaviyo e-mailek megbuknak a DMARC-on).
Ellenőrizze minden rekord tárolt értékét a dig CNAME <név> +short segítségével, és hasonlítsa össze karakterről karakterre azzal, amit az eszköz kért. Saját domainjére végződő cél = zónához hozzáfűzve; adja meg újra, és ha a panel folyamatosan hozzáfűzi, adja hozzá a záró pontot (vagy vegye ki, ha a panel elutasítja a pontokat).
Ellenőrizze az autoritatív névszervereken. dig +short NS sajatdomain.hu, majd ismételje meg a CNAME-ellenőrzéseket @<azon névszerver> értékkel. Ha a migráció névszervert váltott, ellenőrizze mindkét készletet — a vevők esetleg még a régiket kérdezik, amíg a delegálás el nem terjed.
Futtassa újra az eszköz ellenőrzését, és küldjön tesztüzenetet. Az Authentication-Results fejlécnek dkim=pass értéket kell mutatnia, ahol a d= egyenlő a domainjével — az eszköz alapértelmezett domainján való átmenet nem igazodik a DMARC-hoz.
Hagyja közzétéve a régi eszköz selectorait, amíg a forgalom le nem csengett, majd vonja ki őket tudatosan. Ezután futtassa újra a vizsgálatot, és dolgozza végig mindazt, amit a DKIM javítása oldalon megjelöltek.

Gyakran ismételt kérdések

Szükségem van-e a DKIM CNAME-en a záró pontra vagy sem? Ez teljesen a paneltől függ. A pont azt jelenti: „abszolút név — ne fűzze hozzá a zónámat”; néhány panel megköveteliut, néhány hozzáadja Önért, néhány elutasítja. Az egyetlen számottevő teszt a dig CNAME <selector>._domainkey.sajatdomain.hu +short kimenete a mentés után: ha a cél saját domainjére végződik, a panel hozzáfűzte a zónát, és pontra (vagy eltérő beviteli formátumra) van szükség.

Törölhetem a régi eszköz DKIM-rekordjait az átváltás napján? Nem. A régi eszköz által aláírt levelek még az újrapróbálkozási sorokban és a továbbítási útvonalakon vannak, és az általuk mutatott kulcs törlése visszafelé hatva érvényteleníti ezeket az üzeneteket. Tartsa élőn a régi selectorokat, amíg azok eltűnnek a DMARC-összesítő jelentésekből — egy hét vagy több —, és ne zárja be a régi fiókot sem addig.

A DNS-panelem és az új eszköz is „ellenőrzött” mutat, de a vevők még mindig megbuknak a DKIM-en. Miért? Két általános eset: az eszköz egy gyorsítótárazott ellenőrzés ellen ellenőrzött, miközben az autoritatív névszerverek mást szolgáltatnak ki (kérdezze le őket közvetlenül a dig @<ns> segítségével), vagy a DKIM átmegy, de az eszköz alapértelmezett aláíró domainjén, nem az Önén, tehát a DMARC még mindig megbukik az igazítás miatt. A vizsgálat különbséget tesz a kettő között.

Mindkét eszköz DKIM-rekordjai együtt élhetnek-e az átfedési időszak alatt? Igen — és kell is, hogy így legyen. A DKIM-nek nincs egyrekord-szabálya: minden selector a saját DNS-neve, tehát mindkét eszköz rekordjai egymás mellett élnek, konfliktus nélkül, ami lehetővé teszi a régi selectorokat a lecsengésen át megtartó szabály ingyenes követését. (Az SPF az ellentéte — két v=spf1 rekord érvényteleníti, ezért szól az SPF migrációs útmutató az összevonásról.)

Küldje el a tulajdonosnak a jelentést

Ha ezt a migrációt egy ügyfél vagy munkaadója számára futtatja, zárja le bizonyítékkal. Amint az új eszköz aláír és igazodik, futtassa újra az ingyenes vizsgálatot, és küldje el az értékelt jelentést a vállalkozás tulajdonosának: keltezve, közérthető nyelvű bizonyíték arra, hogy az átváltás teljes hitelesítéssel hagyta el a domainjét. 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 — a „migráció elvégezve” állítást egy dokumentummá alakítja.

Ellenőrizze a DKIM-jét ingyen

Tekintse meg, hogy az új eszköz 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 → · Az SPF leállt a szolgáltató váltása után → · 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.