Zökkenőmentes DKIM kulcscsere a biztos kézbesítésért

DKIM kulcsrotáció lépésről lépésre: miért nem halogatható

A DKIM (DomainKeys Identified Mail) aláírás ma már nem extra, hanem alapfeltétel, ha azt szeretnéd, hogy a leveleid ne a Promóciók között vagy rosszabb esetben a spam mappában landoljanak. A DKIM kulcsrotáció pedig nem “paranoia”, hanem karbantartás: ugyanúgy része a levelezési higiénének, mint a jelszavak frissítése vagy a tanúsítványok megújítása. Akkor is kell vele foglalkozni, ha eddig minden rendben ment – pont azért, hogy ez így is maradjon.

A jó hír: leállás nélkül is megoldható. A rossz hír: ha kapkodsz, vagy rossz sorrendben lépsz, napokra széteshet a kézbesíthetőség. Ebben a bejegyzésben úgy vezetlek végig a folyamaton, hogy közben végig kontroll alatt maradjon a forgalmad, és ne kelljen “imádkozni” a DNS miatt.

Mikor kell DKIM kulcsot rotálni, és mikor kötelező azonnal

A rotáció ideális esetben tervezett. Sok szervezet 6–12 havonta cserél DKIM kulcsot, főleg ott, ahol belső szabályzat vagy audit elvárja. De vannak helyzetek, amikor nem “ajánlott”, hanem azonnali teendő:

Ha a privát kulcs hozzáférése gyanús (kiszivárgás, jogosultsági káosz, mentések kétes helyen), ha levelezési rendszert migrálsz, ha szolgáltatót váltasz, vagy ha több rendszer (például CRM, hírlevélküldő, ügyfélszolgálat) ugyanazzal a selectorral és kulccsal dolgozik, és már nem átlátható, ki mit ír alá. Gyakori jel még az is, amikor DMARC riportokban megjelennek “furcsa” aláírások, vagy hirtelen romlik a deliverability, miközben SPF/DMARC papíron rendben van.

Előkészítés: mit nézz át, mielőtt kulcsot generálsz

A leállásmentes rotáció kulcsa az, hogy előbb térképet rajzolsz, és csak utána nyúlsz a rendszerhez. Először azonosítsd, mely rendszerek írnak alá DKIM-mel a domain nevében. Nem csak a “fő levelezés” számít, hanem minden külső küldő is: hírlevél, számlázó, ticketing, toborzási platform, akár egy weboldal űrlapja.

Ezután nézd meg a jelenlegi DKIM rekordot: milyen selector van használatban, milyen kulcshossz (1024 vagy 2048 bit), és milyen gyakran frissül a DNS zóna. A 2048 bites kulcs ma már alapelvárás sok helyen, de csak akkor válts, ha a DNS szolgáltatód és a rekord mérete stabilan kezeli (hosszabb TXT rekordoknál előjöhetnek tördelési hibák, rossz idézőjelezés, vagy több TXT rekordba eső darabolás).

Ha az infrastruktúrát az 1b.hu környezetében üzemelteted, érdemes a rotáció előtt a teljes küldési láncot átnézni: hol történik az aláírás, melyik MTA/SMTP végzi, és hol van a DNS ténylegesen kezelve. A legtöbb félresiklás nem kriptográfiai hiba, hanem adminisztrációs félreértés.

Új selector és új kulcs: miért fontos a név, és hogyan válassz jól

A DKIM rotációt legegyszerűbben úgy csinálod meg, hogy új selectort vezetsz be. A selector lényegében egy “kulcsazonosító” a DNS-ben. Ha eddig például s1 volt, akkor a rotációhoz készítesz s2-t, vagy dátumalapút, például dkim2026q1-et. A dátumalapú elnevezés hosszabb távon átláthatóbb, mert egy pillantással látod, melyik kulcs mikori.

Kulcsot úgy generálj, hogy a privát rész kizárólag a levelező rendszerben maradjon (ott is megfelelő jogosultsággal), a publikus rész pedig a DNS-be kerüljön. Ha több küldőrendszered van, ne ess abba a csapdába, hogy “jó lesz mindegyiknek ugyanaz a privát kulcs”. A DKIM egyik értelme pont az, hogy szétválaszthatóvá teszi a küldési forrásokat.

DNS publikálás: a leállásmentesség egyik fele

Itt jön a leállásmentes stratégia első pillére: előbb publikálsz, és csak utána váltasz. Az új selectorhoz tartozó rekord tipikusan így néz ki logikailag: selector._domainkey.domain.tld alatt egy TXT rekord, benne a DKIM publikus kulccsal és a paraméterekkel. A technikai részletek implementációtól függenek, de az elv ugyanaz: a DNS-ben már ott kell lennie az új kulcsnak, mielőtt egyetlen levél is azzal az aláírással kimegy.

A TTL (élettartam) itt számít. Ha nagyon magas TTL-lel dolgozol, akkor a változások lassabban “terjednek” a rekurzív DNS cache-ek miatt. Rotáció előtt praktikus a TTL-t átmenetileg lejjebb venni, hogy a váltás rugalmasabb legyen. Ezt nem kötelező, de sok fejfájást spórolhat.

Váltás a levelező rendszerben: mikor nyúlj hozzá, és mit figyelj

Miután az új DKIM rekord biztosan él a DNS-ben, jöhet a váltás az aláíró oldalon. Ez lehet Postfix + OpenDKIM, Exim, Microsoft 365/Exchange (közvetett módon), vagy bármilyen gateway/hírlevél szolgáltató. A lényeg, hogy az aláírás már az új selectorral készüljön.

A leállásmentesség második pillére az, hogy a régi kulcsot nem törlöd azonnal. A váltás pillanatától kezdve az új levelek már az új selectorral mennek ki, de a korábban kiküldött levelek még hetekig ott lehetnek levelező listákban, forwardokban, vagy későbbi ellenőrzésekben. Ha a régi publikus kulcsot túl hamar kiveszed a DNS-ből, ezek a levelek utólag DKIM-failt mutathatnak, ami rontja a reputációt és a bizalmat.

Ellenőrzés: honnan tudod biztosan, hogy jól sikerült

A rotáció után az első 24–48 óra kritikus. Nem azért, mert “bármi történhet”, hanem mert ilyenkor derül ki, van-e olyan küldőrendszered, amit kihagytál a térképből, vagy valahol még a régi selector maradt beállítva.

Ellenőrzésnél nézd a kimenő levelek fejlécét: szerepel-e benne a DKIM-Signature, és azon belül az új selector. Nézd meg a beérkező oldali eredményt is (Authentication-Results), hogy a DKIM pass-e. Ha DMARC-ot használsz, a riportokból gyorsan látod, hogy az új selectorral aláírt forgalom milyen arányban megy át, és van-e hirtelen elutasítás vagy karantén.

Ha az 1b.hu-n futó levelezési infrastruktúrát használsz, érdemes a rotációt úgy időzíteni, hogy legyen rálátás a logokra és a DNS zónára is, mert a hibák nagy része egyetlen karakter: rosszul tördelődő TXT rekord, hiányzó idézőjel, vagy elgépelés a selector nevében.

Régi kulcs kivezetése: mikor törölhetsz biztonsággal

A leggyakoribb hiba: “már megy az új, szedjük ki a régit”. Lehet, hogy technikailag megy, de reputációban visszaüthet. Biztonságosabb megközelítés, ha a régi kulcsot legalább 1–2 hétig a DNS-ben hagyod, nagyobb szervezeteknél akár 30 napig is. Ez idő alatt figyeled, hogy minden küldő átállt-e, és nem érkezik-e még régi selectorral aláírt forgalom.

Amikor már biztos vagy benne, hogy minden rendszer az új kulccsal dolgozik, akkor jöhet a régi rekord eltávolítása. Ha dátumalapú selectorokat használsz, később is könnyebb visszakeresni, mikor mi volt éles.

Tipikus buktatók: ami papíron jó, de mégsem az

A DKIM rotáció nem csak kulcscsere, hanem rendszerfegyelem. Buktató lehet, ha több aldomainről küldesz, de csak a fő domain DNS-ét frissíted. Vagy ha van olyan külső szolgáltatód, ami a te domaineddel küld, de a saját DKIM-jét szeretné használni, és ehhez külön rekordokat vár. Az is gyakori, hogy a DMARC igazítás (alignment) azért bukik, mert a From domain és az aláíró domain nincs összhangban.

A legrosszabb, amikor egyszerre nyúlsz az SPF-hez, DMARC-hoz és DKIM-hez. Rotációnál egyszerre egy nagy változó legyen, különben nehéz megmondani, mi rontotta el a kézbesítést.

Összegzés: így marad stabil a kézbesítés rotáció közben is

A leállásmentes DKIM kulcsrotáció lényege két mondatban: előbb tedd ki az új publikus kulcsot DNS-be, csak utána válts az aláírásra, és a régi kulcsot hagyd még bent egy ideig. Ha ezt a sorrendet tartod, a levelek folyamatosan hitelesek maradnak, a fogadó oldalak nem kapnak “meglepetést”, és a reputáció sem ingadozik.

Ha szeretnéd, a következő körben megírom ugyanezt kifejezetten a te tipikus felállásodra (külön levelezés + weboldal űrlap + hírlevélküldő), úgy, hogy a selector-stratégia és a rotációs naptár is kézre álljon az 1b.hu-s üzemeltetésedhez.