Preskočiť na obsah
Návody a zdroje

SPF, DKIM a DMARC podľa špecifikácií RFC

SPF, DKIM a DMARC sú tri štandardy, podľa ktorých prijímajúci server spozná, že e-mail s vašou doménou v adrese odosielateľa naozaj poslal niekto, koho ste na to oprávnili. Článok ich opisuje podľa špecifikácií IETF. Praktický postup nastavenia DNS je v návode SPF, DKIM a DMARC.

Tri rôzne domény v jednom e-maile

Na pochopenie treba rozlíšiť, ktorú doménu ktorý štandard kontroluje:

  • Obálková adresa (RFC5321.MailFrom): adresa, ktorú odosielajúci server uvedie v príkaze MAIL FROM protokolu SMTP. Na ňu sa vracajú nedoručenky. Kontroluje ju SPF.
  • Podpisová doména DKIM: doména v tagu d= hlavičky DKIM-Signature.
  • Doména autora (RFC5322.From): doména v hlavičke From, ktorú príjemca vidí. Na ňu sa vzťahuje DMARC.

SPF (RFC 7208)

SPF (Sender Policy Framework) je záznam typu TXT v DNS domény, ktorý vymenúva servery oprávnené posielať poštu s touto doménou v obálkovej adrese. RFC 7208 je štandard IETF (Standards Track) a nahradil RFC 4408.

Príklad záznamu SPF
example.com.  TXT  "v=spf1 include:_spf.example.net ip4:192.0.2.10 -all"

Dôležité pravidlá špecifikácie:

  • Záznam začína v=spf1. Ak doména zverejní viac ako jeden záznam SPF, výsledkom vyhodnotenia je permerror (oddiel 4.5).
  • Mechanizmy sa vyhodnocujú zľava doprava. Kvalifikátor určuje výsledok: + pass (predvolený), - fail, ~ softfail, ? neutral (oddiel 4.6.2).
  • Mechanizmy include, a, mx, ptr, exists a modifikátor redirect vyvolávajú dopyty DNS. Ich celkový počet je obmedzený na 10, pri prekročení je výsledkom permerror (oddiel 4.6.4). Mechanizmy all, ip4 a ip6 sa do limitu nerátajú.
  • Takzvaných prázdnych dopytov (void lookups), ktoré nevrátia žiadny záznam, by implementácie mali povoliť najviac dva (oddiel 4.6.4).

DKIM (RFC 6376, RFC 8301)

DKIM (DomainKeys Identified Mail) pridá do e-mailu kryptografický podpis v hlavičke DKIM-Signature. Prijímajúci server si podľa tagov s= (selektor) a d= (doména) nájde verejný kľúč v DNS a overí, že podpísané hlavičky a telo správy cestou nikto nezmenil.

Kde je verejný kľúč DKIM
selektor._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
  • Kľúče sú podľa RFC 6376 (oddiel 3.6.2.1) uložené v subdoméne _domainkey, pred ktorou stojí selektor. Doména tak môže mať viac kľúčov naraz, napríklad pre rôzne odosielacie služby.
  • RFC 8301 aktualizuje požiadavky na algoritmy: podpisový algoritmus rsa-sha1 sa na podpisovanie používať nesmie (MUST NOT) a podpisujúci musí používať kľúče RSA dlhé aspoň 1024 bitov (MUST) a mal by používať aspoň 2048 bitov (SHOULD).
  • Gmail vo svojich pravidlách pre odosielateľov uvádza, že na doručenie na osobné účty Gmail je potrebný kľúč DKIM s dĺžkou 1024 bitov alebo dlhší, a odporúča 2048 bitov.

DMARC (RFC 9989, predtým RFC 7489)

DMARC spája SPF a DKIM s doménou, ktorú príjemca vidí v hlavičke From. Správa prejde overením DMARC, keď aspoň jeden z mechanizmov SPF alebo DKIM prejde a jeho doména je zarovnaná (aligned) s doménou autora (oddiel 4.1).

V máji 2026 vyšlo RFC 9989, ktoré je štandardom IETF a nahrádza pôvodné informatívne RFC 7489 z roku 2015 a experimentálne RFC 9091. Agregované správy po novom opisuje RFC 9990, správy o zlyhaní RFC 9991.

Príklad záznamu DMARC
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
  • Umiestnenie: záznam je typu TXT na názve _dmarc pred doménou (oddiel 4.5). Tag v=DMARC1 musí byť prvý.
  • Politika p: none (vlastník domény nevyjadruje preferenciu), quarantine (správy, ktoré neprejdú, sú podozrivé), reject (zlyhanie overenia je jasným znakom, že použitie domény nie je platné). Záznam bez tagu p sa vyhodnotí, ako keby obsahoval p=none.
  • Zarovnanie: voľné (relaxed, predvolené) znamená rovnakú organizačnú doménu, napríklad mail.example.com a example.com. Prísne (strict) vyžaduje zhodnú doménu. Nastavuje sa tagmi adkim a aspf (oddiely 3.2.10 a 4.7).
  • Správy: tag rua určuje, kam posielať agregované správy. Bez neho ich príjemcovia nesmú generovať (oddiel 4.7).
  • Zmeny oproti RFC 7489 (príloha C): tag pct bol odstránený a čiastočne ho nahrádza tag t (testovací režim), odstránené boli aj tagy rf a ri. Pribudli nové tagy np (politika pre neexistujúce subdomény, prevzatý z RFC 9091) a psd. Organizačnú doménu už neurčuje Public Suffix List, ale postup DNS Tree Walk.

Postup k p=reject

RFC 9989 v oddiele 7.4 upozorňuje, že politika p=reject môže spôsobiť problémy pri nepriamych cestách pošty, ako sú preposielacie adresy a e-mailové konferencie. Domény, ktoré p=reject zverejnia, sa nesmú spoliehať len na SPF a musia správy podpisovať DKIM (MUST). Domény, ktorých používatelia môžu písať do e-mailových konferencií, by podľa špecifikácie p=reject zverejňovať nemali (SHOULD NOT). Ak ho napriek tomu chcú zverejniť, mali by najprv využiť agregované správy, najmenej mesiac mať p=none, potom rovnako dlho p=quarantine a výsledky porovnať.

Od hromadných odosielateľov vyžadujú Gmail aj Yahoo záznam DMARC s politikou aspoň p=none, pozri článok Požiadavky Gmailu a Yahoo.

Časté otázky

Prečo SPF zlyhá s chybou permerror, aj keď je záznam správne?

Podľa RFC 7208 vedie k výsledku permerror okrem iného to, že doména má viac ako jeden záznam SPF (oddiel 4.5), alebo vyhodnotenie potrebuje viac ako 10 dopytov DNS cez mechanizmy include, a, mx, ptr, exists a modifikátor redirect (oddiel 4.6.4).

Stačí SPF bez DKIM?

Pre DMARC stačí jeden zarovnaný mechanizmus. RFC 9989 však odporúča používať oba (oddiel 4.5) a domény s p=reject musia podpisovať DKIM, pretože pri preposielaní SPF zvyčajne zlyhá, kým podpis DKIM zostáva platný (oddiel 7.4). Gmail od odosielateľov nad 5 000 správ denne vyžaduje SPF aj DKIM.

Aký dlhý má byť kľúč DKIM?

Podľa RFC 8301 najmenej 1024 bitov, odporúčaných je 2048 bitov. Rovnaké minimum a odporúčanie uvádza Gmail.

Čo znamená tag pct v mojom zázname DMARC?

V RFC 7489 určoval podiel správ, na ktoré sa má politika použiť. RFC 9989 ho odstránil; jeho úlohu pri testovaní čiastočne preberá tag t.

Súvisiace

Zdroje

Všetky články