Přeskočit na obsah
Návody a zdroje

SPF, DKIM a DMARC podle specifikací RFC

SPF, DKIM a DMARC jsou tři standardy, podle kterých přijímající server pozná, že e-mail s vaší doménou v adrese odesílatele opravdu poslal někdo, koho jste k tomu oprávnili. Tento článek je popisuje podle specifikací IETF. Praktický postup nastavení DNS je v návodu SPF, DKIM a DMARC.

Tři různé domény v jednom e-mailu

Pro pochopení je potřeba rozlišit, kterou doménu který standard kontroluje:

  • Obálková adresa (RFC5321.MailFrom): adresa, kterou odesílající server uvede v příkazu MAIL FROM protokolu SMTP. Na ni se vracejí nedoručenky. Kontroluje ji SPF.
  • Podpisová doména DKIM: doména v tagu d= hlavičky DKIM-Signature.
  • Doména autora (RFC5322.From): doména v hlavičce From, kterou příjemce vidí. K ní se vztahuje DMARC.

SPF (RFC 7208)

SPF (Sender Policy Framework) je záznam typu TXT v DNS domény, který vyjmenovává servery oprávněné posílat poštu s touto doménou v obálkové adrese. RFC 7208 je standard IETF (Standards Track) a nahradil RFC 4408.

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

Důležitá pravidla specifikace:

  • Záznam začíná v=spf1. Pokud doména zveřejní víc než jeden záznam SPF, výsledkem vyhodnocení je permerror (oddíl 4.5).
  • Mechanismy se vyhodnocují zleva doprava. Kvalifikátor určuje výsledek: + pass (výchozí), - fail, ~ softfail, ? neutral (oddíl 4.6.2).
  • Mechanismy include, a, mx, ptr, exists a modifikátor redirect vyvolávají dotazy DNS. Jejich celkový počet je omezen na 10, při překročení je výsledkem permerror (oddíl 4.6.4). Mechanismy all, ip4 a ip6 do limitu nepočítají.
  • Takzvaných prázdných dotazů (void lookups), které nevrátí žádný záznam, by implementace měly povolit nejvýš dva (oddíl 4.6.4).

DKIM (RFC 6376, RFC 8301)

DKIM (DomainKeys Identified Mail) přidá do e-mailu kryptografický podpis v hlavičce DKIM-Signature. Přijímající server si podle tagů s= (selektor) a d= (doména) najde veřejný klíč v DNS a ověří, že podepsané hlavičky a tělo zprávy cestou nikdo nezměnil.

Kde je veřejný klíč DKIM
selektor._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
  • Klíče jsou podle RFC 6376 (oddíl 3.6.2.1) uložené v poddoméně _domainkey, před kterou stojí selektor. Doména tak může mít víc klíčů najednou, například pro různé odesílací služby.
  • RFC 8301 aktualizuje požadavky na algoritmy: podpisový algoritmus rsa-sha1 se k podepisování používat nesmí (MUST NOT) a podepisující musí používat klíče RSA dlouhé aspoň 1024 bitů (MUST) a měl by používat aspoň 2048 bitů (SHOULD).
  • Gmail ve svých pravidlech pro odesílatele uvádí, že pro doručení na osobní účty Gmail je potřeba klíč DKIM o délce 1024 bitů nebo delší, a doporučuje 2048 bitů.

DMARC (RFC 9989, dříve RFC 7489)

DMARC spojuje SPF a DKIM s doménou, kterou příjemce vidí v hlavičce From. Zpráva projde ověřením DMARC, když aspoň jeden z mechanismů SPF nebo DKIM projde a jeho doména je zarovnaná (aligned) s doménou autora (oddíl 4.1).

V květnu 2026 vyšlo RFC 9989, které je standardem IETF a nahrazuje původní informativní RFC 7489 z roku 2015 a experimentální RFC 9091. Agregované zprávy nově popisuje RFC 9990, zprávy o selhání RFC 9991.

Příklad záznamu DMARC
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
  • Umístění: záznam je typu TXT na názvu _dmarc před doménou (oddíl 4.5). Tag v=DMARC1 musí být první.
  • Politika p: none (žádná preference vlastníka domény), quarantine (zprávy, které neprojdou, jsou podezřelé), reject (selhání ověření je jasnou známkou, že použití domény není platné). Záznam bez tagu p se vyhodnotí, jako by obsahoval p=none.
  • Zarovnání: volné (relaxed, výchozí) znamená stejnou organizační doménu, například mail.example.com a example.com. Přísné (strict) vyžaduje shodnou doménu. Nastavuje se tagy adkim a aspf (oddíl 3.2.10 a 4.7).
  • Zprávy: tag rua určuje, kam posílat agregované zprávy. Bez něj je příjemci nesmí generovat (oddíl 4.7).
  • Změny proti RFC 7489 (příloha C): tag pct byl odstraněn a částečně ho nahrazuje tag t (testovací režim), odstraněny byly i tagy rf a ri. Nově přibyly tagy np (politika pro neexistující poddomény, převzatý 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 oddíle 7.4 upozorňuje, že politika p=reject může způsobit problémy u nepřímých cest pošty, jako jsou přeposílací adresy a e-mailové konference. Domény, které p=reject zveřejní, se nesmějí spoléhat jen na SPF a musí zprávy podepisovat DKIM (MUST). Domény, jejichž uživatelé mohou psát do e-mailových konferencí, by podle specifikace p=reject zveřejňovat neměly (SHOULD NOT). Pokud ho přesto chtějí zveřejnit, měly by nejdřív využít agregované zprávy, nejméně měsíc mít p=none, potom stejně dlouho p=quarantine a výsledky porovnat.

Pro hromadné odesílatele vyžadují Gmail i Yahoo záznam DMARC s politikou alespoň p=none, viz článek Požadavky Gmailu a Yahoo.

Časté otázky

Proč SPF selže s chybou permerror, i když je záznam správně?

Podle RFC 7208 vede k výsledku permerror mimo jiné to, že doména má víc než jeden záznam SPF (oddíl 4.5), nebo vyhodnocení potřebuje víc než 10 dotazů DNS přes mechanismy include, a, mx, ptr, exists a modifikátor redirect (oddíl 4.6.4).

Stačí SPF bez DKIM?

Pro DMARC stačí jeden zarovnaný mechanismus. RFC 9989 ale doporučuje používat oba (oddíl 4.5) a domény s p=reject musí podepisovat DKIM, protože při přeposílání SPF obvykle selže, kdežto podpis DKIM zůstává platný (oddíl 7.4). Gmail pro odesílatele nad 5 000 zpráv denně vyžaduje SPF i DKIM.

Jak dlouhý má být klíč DKIM?

Podle RFC 8301 nejméně 1024 bitů, doporučeno 2048 bitů. Stejné minimum a doporučení uvádí Gmail.

Co znamená tag pct v mém záznamu DMARC?

V RFC 7489 určoval podíl zpráv, na které se má politika použít. RFC 9989 ho odstranil; jeho roli v testování částečně přebírá tag t.

Související

Zdroje

Všechny články