DKIM fail — diagnostika a řešení

Co znamená DKIM fail

DKIM fail nastane, když přijímající server nedokáže ověřit digitální podpis e-mailu. Podpis buď neodpovídá veřejnému klíči v DNS, zpráva byla cestou pozměněna, nebo veřejný klíč v DNS chybí či je poškozený.

Výsledek DKIM kontroly se zapisuje do hlavičky Authentication-Results přijatého e-mailu:

Authentication-Results: mx.google.com;
    dkim=fail (body hash did not verify) header.d=firma.cz header.s=mail2024

Samotný DKIM fail ještě nemusí znamenat nedoručení e-mailu. Záleží na DMARC politice domény:

• Pokud DKIM selže, ale SPF projde a je v alignmentu, DMARC může stále vyhodnotit e-mail jako pass.
• Pokud selžou DKIM i SPF (nebo žádný z nich není alignovaný), DMARC fail je nevyhnutelný — a s politikou p=quarantine nebo p=reject se e-mail nedoručí.

DKIM fail je proto vždy signálem, který vyžaduje diagnostiku, i když DMARC aktuálně prochází.

Jak DKIM ověření probíhá

Pro pochopení příčin selhání je potřeba vědět, co přijímající server kontroluje:

1. Najde v hlavičce DKIM-Signature doménu (d=) a selektor (s=).
2. Dotáže se DNS na TXT záznam {selektor}._domainkey.{doména} a získá veřejný klíč.
3. Vypočítá hash z podepsaných hlaviček a těla zprávy podle pravidel kanonizace (c= tag).
4. Porovná vypočítaný hash s hodnotou v podpisu — pokud se shodují, DKIM projde.

Selhání může nastat v kterémkoli z těchto kroků. Podle chybové hlášky v Authentication-Results poznáte, kde přesně.

Nejčastější příčiny DKIM failu

Chybějící DNS záznam (no key for signature)

Přijímající server se dotáže na {selektor}._domainkey.{doména} a DNS vrátí NXDOMAIN — záznam neexistuje.

Příčiny:

• Selektor nebyl přidán do DNS (typicky po migraci DNS nebo změně poskytovatele)
• Překlep v názvu záznamu — selector1._domainkey vs. selektor1._domainkey
• Záznam byl omylem smazán
• DNS propagace ještě neproběhla (po čerstvé změně)

Ověřte existenci záznamu DKIM analyzérem nebo příkazem:

dig mail2024._domainkey.firma.cz TXT +short

Pokud příkaz nevrátí žádný výstup, záznam v DNS neexistuje.

Modifikace těla zprávy (body hash did not verify)

Nejčastější příčina DKIM failu. Chybová hláška body hash did not verify znamená, že hash těla zprávy vypočítaný příjemcem neodpovídá hodnotě bh= v DKIM podpisu. Zpráva byla po podepsání pozměněna.

Co typicky mění tělo e-mailu:

• Odchozí brány a filtry — antispam, antivirus, DLP (Data Loss Prevention) systémy, které zpracovávají odchozí poštu po DKIM podepsání
• E-mailové podpisy a disclaimery — servery přidávající právní doložky nebo podpisy do těla zprávy po podepsání
• Mailing listy — přidávají patičky, hlavičky nebo mění formátování
• Přeposílání — některé servery přeformátují zprávu při forwardu
• Kódování — změna character setu nebo transfer encoding (např. z quoted-printable na base64)

Řešení: identifikujte, který systém zprávu modifikuje, a buď přesuňte DKIM podepisování za tento systém (aby se podepisovala finální podoba zprávy), nebo zabezpečte, aby systém nepozměňoval podepsané části.

Nesprávná kanonizace

Tag c= v DKIM podpisu určuje, jak přísně se porovnává obsah. Formát je hlavičky/tělo:

Pokud vidíte v DKIM-Signature hodnotu c=simple/simple a DKIM selhává, zkuste přepnout na c=relaxed/relaxed. Toto nastavení toleruje drobné úpravy, které provádějí poštovní servery při přenosu — redukci mezer, odstranění prázdných řádků na konci těla a převod názvů hlaviček na malá písmena.

Nastavení kanonizace se mění v konfiguraci podepisujícího serveru (OpenDKIM, Postfix, Exchange). U hostovaných služeb (Google Workspace, Microsoft 365) je typicky nastaveno na relaxed/relaxed a nelze změnit.

Neúplný nebo zkrácený klíč v DNS

RSA klíče o délce 2048 bitů překračují limit 255 bajtů jednoho DNS řetězce definovaný v RFC 1035. Hodnota musí být rozdělena do více řetězců:

mail2024._domainkey.firma.cz TXT ("v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQE..."
    "...FAAOCAQ8AMIIBCgKCAQEA...")

Některé DNS panely dělení zvládají automaticky, jiné ne. Pokud klíč vložíte jako jeden řetězec bez rozdělení, DNS ho může zkrátit — výsledkem je neplatný veřejný klíč a dkim=fail.

Kontrola: porovnejte délku klíče v DNS s délkou klíče vygenerovaného poskytovatelem. Pokud se liší, záznam je neúplný.

Nesoulad privátního a veřejného klíče

Veřejný klíč v DNS neodpovídá privátnímu klíči, kterým server podepisuje. Stane se to typicky při:

• Rotaci klíčů — server už podepisuje novým klíčem, ale v DNS je stále starý veřejný klíč (nebo naopak)
• Chybné konfiguraci — na serveru je nakonfigurovaný jiný klíč, než ke kterému patří veřejný klíč v DNS
• Kopírování konfigurace — při migraci na nový server se zkopíroval starý privátní klíč, ale v DNS je klíč z nové instalace

Řešení: vygenerujte nový klíčový pár, publikujte veřejný klíč v DNS pod novým selektorem a nakonfigurujte server na podepisování novým privátním klíčem.

Odvolaný klíč

Prázdná hodnota p= (bez klíče) v DNS záznamu signalizuje záměrně odvolaný selektor:

mail2024._domainkey.firma.cz TXT "v=DKIM1; p="

Toto je standardní postup při rotaci klíčů (RFC 6376, sekce 3.6.1). Pokud ale server stále podepisuje odvolaným selektorem, každý e-mail dostane dkim=fail.

Řešení: buď aktualizujte server na nový selektor, nebo obnovte veřejný klíč v DNS.

Expirace podpisu

Tag x= v DKIM podpisu nastavuje dobu platnosti. Po jejím uplynutí ověřovatel podpis odmítne, i když je jinak platný. K expiraci dochází typicky u zpráv zdržených ve frontě (graylisting — dočasné odmítnutí e-mailu s výzvou k opětovnému doručení) nebo při dočasných chybách příjemce.

Většina konfigurací x= nepoužívá. Pokud ho máte nastavený a vidíte DKIM fail u zpráv doručených se zpožděním, zvažte prodloužení doby platnosti nebo odstranění tagu x=.

Slabý nebo nepodporovaný algoritmus

RFC 8301 vyžaduje od odesílatelů minimálně 1024bitové RSA klíče a doporučuje (SHOULD) minimálně 2048 bitů. Podpis musí používat algoritmus rsa-sha256. Starší konfigurace mohou používat:

• 1024bitové RSA klíče — většina ověřovatelů je stále přijímá, ale považují se za nedostatečné; doporučeno je přejít na 2048 bitů
• rsa-sha1 — zastaralý hashovací algoritmus; RFC 8301 zakazuje (MUST NOT) jeho použití jak pro podepisování, tak pro ověřování

Řešení: přegenerujte klíč na minimálně 2048 bitů a používejte rsa-sha256 nebo ed25519-sha256.

Jak zjistit příčinu DKIM failu

Hlavička Authentication-Results

Nejrychlejší diagnostika konkrétního e-mailu. V přijatém e-mailu najděte hlavičku Authentication-Results — obsahuje výsledek DKIM kontroly i důvod selhání:

DMARC reporty

Agregované DMARC reporty poskytují souhrnný přehled o DKIM výsledcích za celou doménu — ne jen za jednotlivé e-maily. V reportech hledejte záznamy s dkim=fail:

1. Identifikujte IP adresu — patří vašemu serveru nebo známé odesílací službě?
2. Zkontrolujte selektor — odpovídá nakonfigurovanému selektoru?
3. Ověřte doménu — shoduje se d= s doménou v hlavičce From?

Pokud máte DMARC reporty směřované do SPF Monitoru, nemusíte ručně parsovat XML — vizualizace vám ukáže problematické odesílatele na jednom místě.

Diagnostika přes analyzér

DKIM analyzér SPF Monitoru zkontroluje DNS záznam pro zadaný selektor a doménu:

• Existenci záznamu v DNS
• Syntaxi a validitu veřejného klíče
• Typ a délku klíče
• Stav klíče (platný / odvolaný)

Pro kompletní kontrolu odešlete testovací e-mail a zkontrolujte hlavičky — analyzér ověří DNS, ale nevidí, zda server skutečně podepisuje a zda zpráva cestou neprochází systémem, který ji modifikuje.

Řešení podle typu selhání

Prevence DKIM failů

• Používejte kanonizaci relaxed/relaxed — toleruje běžné úpravy při přenosu a minimalizuje falešně pozitivní selhání.
• Podepisujte až po všech úpravách — DKIM podepisování musí být posledním krokem před odesláním. Pokud máte antispam, disclaimery nebo jiné filtry, řaďte je před DKIM.
• Monitorujte DKIM výsledky — pravidelně kontrolujte DMARC reporty. Selhání DKIM se může objevit náhle — po aktualizaci serveru, změně DNS, nebo úpravě filtrovacích pravidel.
• Rotujte klíče bezpečně — při rotaci nejdříve publikujte nový klíč v DNS, přepněte server na nový selektor, a teprve po ověření funkčnosti odvolejte starý klíč. Nikdy neodvolávejte klíč dříve, než je nový plně funkční.
• Používejte minimálně 2048bitové RSA klíče — RFC 8301 to doporučuje (SHOULD). Povinné minimum je 1024 bitů, ale 2048 bitů je dnešní standard. Klíče ed25519 nabízejí lepší výkon, ale podpora u ověřovatelů je zatím omezená.
• Ověřujte po každé změně — po migraci DNS, změně mailového serveru nebo přidání nové odesílací služby vždy ověřte DKIM záznam a odešlete testovací e-mail.

Kompletní analýza vaší domény odhalí problémy v SPF, DKIM i DMARC konfiguraci na jednom místě.