Klíče DKIM a jejich rotace: selektory, velikosti, publikace

Klíč DKIM je dvojice klíčů: soukromá polovina zůstává na poštovním serveru a podepisuje každou odchozí zprávu, veřejná polovina leží v DNS pod jménem zvaným selektor a příjemci si ji stahují, aby podpis ověřili. Používej 2048bitový klíč RSA - 1024 je minimum, které standard ještě povoluje, ale už se nepovažuje za dostatečné, a 4096 způsobuje potíže s DNS bez praktického přínosu. Pokud tvůj server umí podepisovat oběma způsoby, přidej vedle něj klíč Ed25519. Rotuj tak, že zveřejníš nový selektor, přepneš podepisování na něj a starý veřejný klíč necháš v DNS aspoň týden, protože zprávy podepsané starým klíčem se ověřují i poté, co ho přestaneš používat. To je celý postup; zbytek článku jsou detaily, díky kterým to proběhne hladce.

Pozadí - proč DKIM existuje a jak souvisí s SPF a DMARC - najdeš v článku SPF, DKIM a DMARC vysvětleně. Tento článek předpokládá, že víš, k čemu DKIM slouží, a chceš s klíči zacházet správně.

Co obsahuje podpis#

Když tvůj server zprávu podepíše, přidá hlavičku podobnou této:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;  s=s2026a; t=1791446400; h=from:to:subject:date:message-id:mime-version;  bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=;  b=Ys9Bd7pLq2T...

Příjemce vezme s= a d=, sestaví jméno s2026a._domainkey.example.com, stáhne tamní záznam TXT a pomocí veřejného klíče ověří b=. Pokud se ověří a tělo stále odpovídá hashi bh=, podpis projde.

Dvě nastavení podepisovače stojí za kontrolu. Používej kanonizaci relaxed/relaxed: simple selhává na neškodných změnách bílých znaků, které provedou servery na cestě. A ujisti se, že From: je v h=, což standard vyžaduje; dobré podepisovače ho uvádějí dvakrát („oversigning“), aby útočník nemohl přidat druhou hlavičku From: bez porušení podpisu.

Pokud ti to server nabízí, vyhni se tagu l=. Omezuje podepsané tělo na počet bajtů, aby patičky přidané později podpis nerozbily - což ale také znamená, že kdokoli může k tvé podepsané zprávě připojit obsah a ona se stále ověří.

Selektory a proč jich máš několik#

Selektor je jen štítek, který umožňuje jedné doméně zveřejnit víc klíčů najednou. Každý odesílací systém dostane svůj:

s2026a._domainkey       IN TXT    "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."s2026e._domainkey       IN TXT    "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="pm._domainkey           IN TXT    "v=DKIM1; k=rsa; p=MIGfMA0GCSqG..."selector1._domainkey    IN CNAME  selector1-example-com._domainkey.provider.example.

První dva jsou klíče RSA a Ed25519tvého vlastního poštovního serveru. Třetí patří službě pro transakční e-maily. Čtvrtý je CNAME do zóny poskytovatele - někteří poskytovatelé (známým příkladem je Microsoft 365) chtějí, abys jejich selektory přesměroval pomocí CNAME, aby mohli klíče rotovat na své straně, aniž by tě žádali o zásah do DNS.

Selektory nic nestojí a nekonfliktují, takže je pojmenuj tak, abys za rok poznal, co jsou zač. Běžná schémata kódují datum (s2026a, 202610), systém (mail, app) nebo obojí. Nedávné verze Stalwartu generují selektory ze šablony, jejíž výchozí podoba vypadá jako v1-rsa-20261008 - verze, algoritmus, datum - což je dobré schéma k okopírování, pokud klíče generuješ sám.

Typy a velikosti klíčů#

RFC 8301 říká, že podepisovače musí používat klíče RSA o délce aspoň 1024 bitů a měly by používat aspoň 2048; ověřovatelé nesmí považovat klíče kratší než 1024 bitů za platné. RSA 1024 je v dosahu dobře financovaných útočníků a někteří velcí příjemci ho berou jako slabý. 2048 je rozumné minimum.

Klíče 4096 bitů nejsou v praxi užitečnější. Samotný veřejný klíč má kolem 700 znaků base64, odpověď TXT může překročit tradiční limit 512 bajtů pro UDP v DNS a editory některých poskytovatelů DNS ho neuloží. Resolvery se mohou vrátit k TCP, ale přidáváš tím způsoby selhání kvůli bezpečnosti, kterou zatím nikdo nepotřebuje.

Ed25519 (RFC 8463) je moderní volba: krátké klíče, krátké podpisy, rychlost. Problém je podpora ověřování - ne každý velký příjemce podpisy Ed25519 ověřuje a podpis, kterému příjemce nerozumí, se ignoruje, nezamítá. Proto se v praxi používá dvojí podepisování: každou zprávu podepíšeš klíčem RSA i Ed25519. Příjemci, kteří Ed25519 umí, ho použijí; všichni ostatní použijí RSA. Stalwart to u nových domén dělá ve výchozím nastavení.

Publikace klíčů v DNS#

Formát záznamu:

v=DKIM1; k=rsa; p=<base64 public key>

v=DKIM1 je volitelné, ale zvykové, a pokud je přítomno, musí být první. k= je ve výchozím stavu rsa; klíče Ed25519 potřebují k=ed25519. p= nese klíč. Volitelné tagy: t=y označí doménu jako testující DKIM (příjemci by neúspěchy neměli posuzovat jinak než nepodepsanou poštu - odstraň ho, jakmile vše funguje) a t=s vyžaduje, aby d= přesně odpovídalo identitě, ne subdoméně.

Klíč RSA 2048 má kolem 400 znaků base64 a jeden řetězec TXT v DNS pojme nejvýše 255. Záznam se proto ukládá jako několik řetězců, které příjemci spojí:

s2026a._domainkey IN TXT ( "v=DKIM1; k=rsa; "    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx3...first part..."    "...second part...IDAQAB" )

Většina webových editorů DNS dlouhé hodnoty rozdělí automaticky. Některé chtějí, abys vložil řetězce v uvozovkách sám; pár jich tiše ořízne. Po zveřejnění si záznam stáhni a porovnej:

$ dig +short TXT s2026a._domainkey.example.com"v=DKIM1; k=rsa; " "p=MIIBIjANBgkq...first..." "...second...IDAQAB"

Několik řetězců v uvozovkách v odpovědi je v pořádku. Klíč kratší, než jaký ti dal server, nebo s mezerami či uvozovkami uvnitř base64 v pořádku není.

Pokud klíče generuješ ručně a nenecháš to na poštovním serveru, práci udělá openssl:

# RSA 2048: private key, then the public key as DKIM wants it$ openssl genrsa -out s2026a.private 2048$ openssl rsa -in s2026a.private -pubout -outform der | openssl base64 -A# Ed25519: DKIM wants the raw 32-byte public key, not the DER wrapper$ openssl genpkey -algorithm ed25519 -out s2026e.private$ openssl pkey -in s2026e.private -pubout -outform der | tail -c 32 | openssl base64 -A

Rotace klíčů bez rozbití pošty#

Proč rotovat vůbec: soukromý klíč, který unikne, umožní komukoli podepisovat jako tvá doména, dokud si toho nevšimneš; staré klíče bývají slabé; a zaměstnanci, kteří měli kdysi přístup k serveru, odcházejí. Často citované doporučení z praxe (M3AAWG) je rotovat aspoň každého půl roku. Mnoho organizací to dělá ročně; jednou za rok spolehlivě je lepší než čtvrtletně jen na papíře.

Bezpečný postup:

1. Vygeneruj nový klíč pod novým selektorem. Nikdy nepoužívej jméno selektoru znovu pro jiný klíč - příjemci a resolvery ukládají starý záznam do cache po dobu jeho TTL a podpisy novým klíčem by proti uloženému starému selhávaly.
2. Zveřejni nový veřejný klíč a ověř ho zvenčí pomocí dig. Počkej aspoň po dobu TTL záznamu, aby ho viděl každý resolver.
3. Přepni podepisování na nový klíč. Od této chvíle nese nová pošta v s= nový selektor.
4. Starý veřejný klíč nech zveřejněný aspoň sedm dní. Pošta podepsaná starým klíčem může ležet ve frontách, být opakovaně doručována, přeposlána nebo pozdě ověřena příjemcem, který ji znovu skenuje.
5. Zruš starý klíč. Buď záznam smaž, nebo ho zveřejni s prázdným klíčem (v=DKIM1; p=), což RFC 6376 definuje jako zrušený. Prázdné p= je pro každého, kdo bude později ladit, o něco informativnější.
6. Zlikviduj starý soukromý klíč, jakmile si jsi jistý, že jím nic dál nepodepisuje.

Častá chyba je dělat kroky 3 a 5 najednou - přepnout podepisování a zároveň smazat starý záznam - čímž selže každá zpráva, která je právě na cestě. Druhá chyba je udělat krok 3 dřív, než se krok 2 stihl ustálit, což rozbije první hodinu pošty.

Automatická rotace ve Stalwartu

Nedávné verze Stalwartu umí tento životní cyklus spravovat samy: každá doména má nastavení správy DKIM, které je buď ruční, nebo automatické. Automatický režim rotuje klíče podle plánu (výchozích 90 dní), záznam DNS nahrazeného klíče nechává zveřejněný 7 dní po přepnutí a materiál klíče smaže o dalších 30 dní později. Vyžaduje automatickou správu DNS - přístup k API tvého poskytovatele DNS - protože záznamy musí sám zveřejňovat a později odstraňovat. Bez toho zůstává rotace ruční: ve webové administraci vygeneruj nový podpis, zveřejni jeho záznam, přepni a starý později odstraň podle postupu výše. Na detailech verzí tu záleží, proto se podívej do dokumentace k vydání, které provozuješ.

Nouzová rotace po úniku#

Výše uvedený plán je pro běžnou rotaci. Pokud mohl soukromý klíč uniknout - kompromitace serveru, záloha ponechaná ve veřejném bucketu, bývalý administrátor, který si ponechal kopii - pořadí se mění, protože nebezpečí je teď starý klíč.

1. Vygeneruj a zveřejni nový klíč pod novým selektorem, přesně jako dříve, a přepni na něj podepisování, jakmile se záznam přeloží z veřejného resolveru. Nečekej celé TTL; minuty jsou důležitější než pár neúspěšných podpisů.
2. Starý klíč okamžitě zruš prázdným p=. Část legitimní pošty, která je ještě na cestě, selže v DKIM. To je cena a je malá: SPF u ní obvykle stále projde a DMARC potřebuje jen jedno zarovnané ověření.
3. Sleduj souhrnné reporty DMARC v následujících týdnech. Zprávy podepsané starým selektorem z IP adres, které nepoznáváš, jsou důkazem, že byl klíč použit.
4. Zjisti, jak unikl, než stejně uniknou další klíč. Rotace nepomůže, pokud nový soukromý klíč leží na stejném odhaleném místě.

Každý, kdo spravuje doménu, by měl vědět, kde leží její soukromé klíče DKIM a kdo je může číst. Pokud je odpověď „v archivu zálohy, který si může stáhnout několik lidí“, zacházej s tím archivem stejně pečlivě jako se samotným klíčem.

Klíče držené jinými odesílateli#

Tvůj vlastní poštovní server málokdy podepisuje za tvou doménu jako jediný. Platforma pro newslettery, helpdesk, fakturační nástroj i služba pro transakční e-maily podepisují každá klíčem, který drží, pod selektorem, jejž jsi pro ně zveřejnil. Několik poznámek k nim:

• Sám je rotovat nemůžeš, pokud to poskytovatel nenabízí. Mnozí poskytovatelé rotují na své straně přes uspořádání s CNAME popsané výše, což je dobrý důvod dát přednost metodě CNAME, když je nabídnuta.
• Odstraň selektory služeb, které přestaneš používat. Klíč, jehož soukromá polovina patří dodavateli, kterému už neplatíš, může dál podepisovat platnou poštu za tvou doménu. Až smlouva skončí, záznam smaž.
• Veď inventář. Krátký seznam selektor, systém, vlastník a datum zveřejnění ušetří odpoledne „archeologie“ s dig. Pomáhají s ním reporty DMARC: každý prošlý podpis DKIM v nich uvádí svůj selektor.
• Hlídej poskytovatele, kteří podepisují vlastní doménou. Pokud služba podepisuje s d=provider.example místo tvé domény, její podpis projde, ale není zarovnaný, a DMARC u té pošty bude záviset jen na SPF. Většina služeb umí podepisovat tvou doménou, jakmile zveřejníš jejich záznam.

Když DKIM selže#

Hlavička Authentication-Results na přijaté zprávě pojmenuje selhání:

• `dkim=fail (body hash did not verify)` - tělo se po podpisu změnilo. Patička konferenčního seznamu, bezpečnostní brána přepisující odkazy, antivirus připojující upozornění, nebo kanonizace těla simple narazila na změnu bílých znaků.
• `dkim=fail (signature verification failed)` - změnily se hlavičky, nebo zveřejněný klíč neodpovídá soukromému. Po rotaci to obvykle znamená, že byl zveřejněn špatný záznam.
• `dkim=neutral` nebo `permerror (no key)` - příjemce nenašel klíč u selektoru. Zkontroluj jméno, zda v něm není zdvojená doména, a ověř, že selektor v s= odpovídá tomu, co jsi zveřejnil.
• `dkim=permerror (key syntax)` - záznam je poškozený: chybí p=, v base64 jsou zatoulané uvozovky nebo je klíč oříznutý.
• `dkim=pass`, ale `dmarc=fail` - podpis prošel pro doménu, která není zarovnaná s From:, často pro doménu poskytovatele. Zarovnání vysvětluje článek reporty DMARC a nasazení politiky.

To, že konferenční seznamy podpisy rozbíjejí, je očekávané a není to tvoje starost; hlavičky ARC (Authenticated Received Chain) existují proto, aby seznamy mohly ručit za původní výsledek.

DKIM na RE:NODE Mail Serveru#

Řada Mail Server provozuje Stalwart a jeho webová administrace generuje klíče DKIM pro každou doménu, kterou přidáš, a zobrazuje záznamy ke zveřejnění. Zveřejníš je tam, kde je hostované tvé DNS - na naší straně editor zón není - spolu s MX, SPF a DMARC. Klíče žijí v datovém úložišti serveru, takže sloty záloh ve tvém tarifu (jeden až čtyři podle úrovně) pokrývají spolu se schránkami i je. Pokud odesíláš přes relay nastavený ve webové administraci, Stalwart stejně nejdřív podepíše tvými klíči. Nastavení poštovního serveru Stalwart pokrývá přidání domény a čtení seznamu záznamů.

FAQ#

Jakou velikost klíče DKIM mám použít?

RSA 2048. Je univerzálně podporované a do DNS se vejde běžným rozdělením na řetězce. Pokud tvůj server umí dvojí podepisování, přidej vedle něj Ed25519. U nových klíčů se vyhni 1024 a vyhni se i 4096, které způsobuje problémy s DNS bez praktického přínosu.

Můžu mít víc než jeden záznam DKIM?

Ano, jeden na selektor, kolik chceš. Každý odesílací systém by měl mít svůj. Nemůžeš mít dva různé klíče pod stejným jménem selektoru.

Jak dlouho mám po rotaci držet starý klíč?

Aspoň sedm dní poté, co jím přestaneš podepisovat, déle, pokud posíláš poštu, která se může nějakou dobu opakovaně doručovat nebo přeposílat. Pak ho zruš prázdným p= nebo smaž.

Musím klíče rotovat, když nic neuniklo?

Nebudeš vědět, jestli něco uniklo. Rotace každých šest až dvanáct měsíců omezuje, jak dlouho zůstane potichu odcizený klíč použitelný, a udržuje postup povědomý pro den, kdy ho budeš potřebovat ve spěchu.

Proč se můj podpis Ed25519 u Gmailu nezobrazuje?

Protože ne každý příjemce Ed25519 ještě ověřuje. Nerozpoznaný podpis se ignoruje, nezamítá. Proto podepisuješ i RSA - výsledek nese podpis RSA.