SPF, DKIM a DMARC: proč firemní e-maily padají do spamu

Odpověď hned: SPF, DKIM a DMARC jsou tři záznamy v DNS vaší domény. SPF vyjmenovává servery, ze kterých smí odcházet pošta s vaší adresou. DKIM přidává ke každé zprávě digitální podpis ověřitelný veřejným klíčem v DNS. DMARC říká příjemci, co udělat se zprávou, která ani jednou kontrolou neprošla — a posílá vám denní přehledy o tom, kdo vaším jménem doopravdy posílá. Bez nich pošta padá do spamu a doménu může kdokoli použít na podvodné faktury. Zapsání záznamů je práce na desítky minut; nejvíc času zabere zjistit, které všechny služby ve firmě posílají vaším jménem.

Typický dotaz zní: „Posíláme fakturu stálému zákazníkovi a přišla mu do spamu. Přitom neděláme žádný newsletter.” Většinou za tím nestojí obsah zprávy, ale to, že přijímající server nemá jak ověřit, že zpráva odešla od vás.

Důvod je v konstrukci e-mailu. Adresa odesílatele, kterou vidíte v poštovním klientovi (5322.From), je jen text v hlavičce — napsat do ní cokoli je stejně snadné jako napsat cokoli na obálku dopisu. Vedle ní existuje druhá adresa, kterou si při doručení předávají servery (5321.MailFrom, obálkový odesílatel), a ta se od té viditelné může legálně lišit.

SPF, DKIM a DMARC: srovnání tří DNS záznamů

Klíčové je to poslední. SPF ani DKIM samy o sobě nevyžadují, aby doména, kterou ověřily, byla ta, kterou příjemce vidí. Útočník si může zaregistrovat vlastní doménu, mít pro ni bezvadný SPF i DKIM — a do viditelné adresy napsat vaši firmu. Teprve DMARC obě roviny sváže.

Co je SPF záznam a jak vypadá

SPF (Sender Policy Framework) je jeden TXT záznam u vaší domény, který vyjmenovává, odkud smí odcházet vaše pošta. Firmě používající pouze Google Workspace stačí podle dokumentace Googlu hodnota v=spf1 include:_spf.google.com ~all. Do záznamu ale podle téže dokumentace patří „domény (nebo IP adresy) všech serverů, které odesílají e-mail pro vaši organizaci”.

A tady bývá první praktický problém. Poštu jménem domény posílá víc systémů, než si majitel vybaví: fakturační a účetní software, e-shop s potvrzením objednávky, nástroj na newsletter, helpdesk, rezervační formulář, CRM a monitoring hlásící výpadky. Každý jde jinou infrastrukturou, a pokud v SPF chybí, jeho zprávy nemají oprávnění. Sestavit úplný seznam je nejnáročnější část celého nastavení a nejde ji vynechat — ovlivňuje i DKIM a DMARC.

Co je DKIM a kde se zapíná v Microsoft 365 a Google Workspace

DKIM (DomainKeys Identified Mail) funguje jinak: odesílající server přidá do zprávy podpis vytvořený privátním klíčem a příjemce ho ověří veřejným klíčem z vaší domény. Podpis se váže na zprávu, ne na IP adresu, a vydrží proto i některé cesty s přeposláním.

Microsoft 365. Pošta z výchozí domény *.onmicrosoft.com se podle dokumentace Microsoftu podepisuje automaticky. U vlastní domény je potřeba DKIM zapnout ručně — v portálu Microsoft Defender na https://security.microsoft.com, cesta Email & collaboration → Policies & rules → Threat policies → Email authentication settings, záložka DKIM. Do DNS přijdou dva záznamy typu CNAME s názvy selector1._domainkey a selector2._domainkey (dva kvůli výměně klíče bez výpadku). Velikost klíče je 1024 bitů jako výchozí, volitelně 2048.

Google Workspace. DKIM se zapíná v administrátorské konzoli v cestě Apps → Google Workspace → Gmail. Klíč se do DNS zapisuje jako TXT záznam, ve výchozím nastavení pod názvem google._domainkey, s délkou 2048 bitů nebo 1024. Poslední krok je kliknout na Start authentication; stav se pak změní na „Authenticating email with DKIM”. Bez toho kliknutí se podepisovat nezačne, i když je záznam v DNS správně.

Obojí ale řeší jen poštu odcházející z té konkrétní služby. Fakturační systém, e-shop nebo newsletter mají vlastní nastavení DKIM a je potřeba je projít zvlášť.

Co je DMARC a co znamená p=none, quarantine a reject

DMARC je TXT záznam na názvu _dmarc.vasedomena.cz. V Microsoftu 365 pro vlastní doménu neexistuje rozhraní, které by ho vytvořilo — zapisuje se u registrátora nebo u služby hostující DNS.

Název:   _dmarc
Typ:     TXT
Hodnota: v=DMARC1; p=none; rua=mailto:dmarc@vasedomena.cz

Zásadní je hodnota p, tedy politika. Má tři stupně a smysl je procházet je postupně:

• p=none — příjemci neříkáte, co má udělat. Zpráva se doručí podle běžných pravidel a vy jen sbíráte data. Stupeň určený k testování a ladění.
• p=quarantine — zpráva, která neprošla, se má přijmout, ale označit. V praxi obvykle složka Nevyžádaná pošta nebo karanténa.
• p=reject — zpráva, která neprošla, se má odmítnout, typicky rovnou při SMTP komunikaci. Tohle je cíl: teprve tady přestane cizí odesílatel psát vaším jménem.

Microsoft doporučuje postupný náběh none → quarantine → reject a začínat u domény nebo subdomény s malým objemem pošty. Důvod je praktický — mezi zprávami, které neprojdou, se v prvních týdnech skoro vždy najde nějaký váš vlastní legitimní systém, na který si nikdo nevzpomněl. Zapnout p=reject dřív, než ho najdete, znamená zablokovat si vlastní faktury. Pro pořádek: v květnu 2026 nahradilo RFC 9989 dosavadní RFC 7489 a zrušilo parametr pct=.

Co jsou DMARC reporty (rua) a co z nich firma vyčte

Parametr rua=mailto: určuje, kam se posílají agregovaná hlášení. Pokud ho neuvedete, přijímající servery je podle standardu generovat nesmí a vy zůstanete slepí. Proto má smysl zapnout p=none, i když zatím nic blokovat nechcete: hlášení chodí i na této politice.

Chodí typicky jednou denně od každého poskytovatele jako komprimovaná XML příloha. Podle dokumentace Microsoftu z nich zjistíte IP adresy serverů a služeb, které posílají poštu s vaší doménou (včetně těch, o kterých nevíte), jestli u nich ověření prošlo, a co s takovou zprávou příjemce udělal.

Nejcennější je rozdíl mezi „ověření prošlo” a „zarovnání prošlo”. Běžný nález: externí služba má SPF v pořádku, protože posílá ze své vlastní domény, ale ve viditelné adrese je vaše doména — takže DMARC neprojde. Řešením je buď nechat službu podepisovat DKIM vaší doménou, nebo u ní přenastavit obálkového odesílatele na vaši subdoménu.

Požadavky Googlu a Yahoo na odesílatele platné od února 2024

Od 1. února 2024 platí u Googlu a Yahoo pravidla, která z ověřování odesílatele udělala vstupenku do schránky. Jsou ve dvou úrovních.

Pro všechny odesílatele Google vyžaduje nastavit SPF nebo DKIM, mít platný přímý i zpětný DNS záznam (PTR) pro odesílající IP adresu, používat pro přenos TLS, dodržet formát zprávy podle RFC 5322 a udržet míru stížností na spam hlášenou v Postmaster Tools pod 0,3 %. Yahoo formuluje minimum stejně („Implement SPF or DKIM at a minimum”) včetně hranice 0,3 %.

Pro hromadné odesílatele — Google jimi rozumí ty, kdo pošlou zhruba 5 000 a více zpráv na osobní gmailové účty za 24 hodin — platí navíc: nastavit SPF i DKIM, publikovat DMARC záznam (politika může být klidně p=none), zajistit zarovnání domény ve viditelné adrese s doménou ověřenou přes SPF nebo DKIM a u marketingových a odběrových zpráv nabídnout odhlášení na jedno kliknutí. Yahoo požaduje totéž, u DKIM navíc klíč alespoň 1024 bitů a odhlášení vyřízené do dvou dnů.

Malá firma tuhle hranici obvykle nepřekročí a formálně jí stačí SPF nebo DKIM. Minimum ji ale jen pustí přes bránu; před zneužitím chrání až všechny tři.

Nejčastější chyby v SPF, DKIM a DMARC

Dva SPF záznamy místo jednoho. Nejčastější nález vůbec — někdo přidal nový systém tak, že vedle stávajícího TXT záznamu založil druhý začínající v=spf1. Podle RFC 7208, kapitoly 4.5, musí kontrola skončit výsledkem permerror. Nejde o „skoro dobře”, ale o neplatné SPF; správně má být jediný záznam se všemi službami.

Překročení limitu deseti DNS dotazů. RFC 7208 v kapitole 4.6.4 stanoví, že vyhodnocení SPF smí použít nejvýš deset prvků vyžadujících DNS dotaz. Počítají se include, a, mx, ptr, exists a modifikátor redirect; all, ip4 a ip6 nikoli. Při překročení je výsledek opět permerror. Google totéž zjednodušuje na „SPF záznam může mít až deset položek include:”. Firma, která postupně přidala Microsoft 365, e-shop, fakturaci a dva marketingové nástroje, se přes limit dostane bez varování.

Zapomenuté služby posílající vaším jménem. Najdou se až v DMARC hlášeních — hlavní důvod, proč se p=none nepřeskakuje.

DKIM jen v poštovní službě. Microsoft 365 podepíše svoji poštu, ale faktury z účetního systému už ne. Po přechodu na p=reject přestanou docházet právě ty.

Špatné pořadí a nechráněné domény. Google upozorňuje, že publikovat DMARC dřív než funkční SPF nebo DKIM znamená potíže s doručováním. A pro doménu, na které nic neběží, doporučuje Microsoft záznam v=DMARC1; p=reject; — odtud nemá chodit žádná pošta.

Zneužití domény k podvodným fakturám

Doména bez DMARC (nebo s DMARC ponechaným natrvalo na p=none) je použitelná jako zpáteční adresa cizího podvodu; odborně se tomu říká business e-mail compromise, BEC. Příjemce dostane zprávu, která v klientovi vypadá jako od vás — vaše doména ve jméně odesílatele, váš podpis, navazující text. Obsahem bývá oznámení o změně bankovního účtu u faktury, na kterou se čeká. Protivník nemusí prolomit nic z vaší infrastruktury; stačí mu, že za doménu nikdo neručí. Škoda nevzniká vám, ale vašemu zákazníkovi nebo dodavateli.

DMARC na p=reject tuhle variantu odřízne: přijímající server zprávu odmítne. Neřeší to podvody z podobně vypadající, ale jiné domény, ani případ, kdy útočník získá přístup do skutečné schránky — na to jsou jiná opatření, hlavně vícefaktorové přihlášení. Co dělat, když už k průniku dojde, rozebíráme v článku o prvních 24 hodinách po ransomwaru.

Jak si nastavení zkontrolujete sami

Na kontrolu stačí příkazová řádka. Na Linuxu a macOS:

dig +short TXT vasedomena.cz
dig +short TXT _dmarc.vasedomena.cz
dig +short CNAME selector1._domainkey.vasedomena.cz
dig +short TXT google._domainkey.vasedomena.cz

Na Windows totéž přes nslookup -type=TXT _dmarc.vasedomena.cz. Hledejte právě jeden řádek začínající v=spf1 (dva a víc znamená neplatné SPF), řádek v=DMARC1 u názvu _dmarc a v něm rua=mailto:, a odpověď u DKIM selektoru — třetí příkaz platí pro Microsoft 365, čtvrtý pro Google Workspace. Prázdná odpověď znamená nedokončený DKIM.

Užitečná je i kontrola doručené zprávy: v hlavičce Authentication-Results uvidíte výsledky spf=, dkim= a dmarc=. Stav dmarc=fail, přestože SPF i DKIM prošly samostatně, ukazuje na chybné zarovnání domén, ne na klíče.

Ověřování odesílatele stojí čas na nastavení a pak už jen běží; jak taková položka vychází v rozpočtu, rozebíráme v přehledu nákladů na správu IT pro malou firmu. Obsah schránek ale nechrání — Microsoft 365 vaše e-maily nezálohuje.

ITHOPE, Brno. Zkontrolujeme stav SPF, DKIM a DMARC na vaší doméně, dohledáme systémy posílající vaším jménem, sjednotíme SPF do jednoho platného záznamu pod limitem deseti dotazů, zapneme DKIM u poštovní služby i u externích nástrojů a provedeme doménu náběhem DMARC od p=none po p=reject včetně čtení hlášení. Navazuje na správu IT a zálohování a další služby v sekci IT pro firmy.

Zdroje

• Email sender guidelines — Google Workspace Admin Help — požadavky od 1. 2. 2024
• Sender Best Practices — Yahoo Senders — požadavky Yahoo na odesílatele
• RFC 7208 — Sender Policy Framework (SPF) — kapitoly 4.5 a 4.6.4
• RFC 9989 — DMARC — standard z května 2026, nahrazuje RFC 7489
• Set up DKIM — Microsoft Learn
• Set up DMARC — Microsoft Learn
• Set up DKIM — Google Workspace Knowledge Center
• Set up SPF — Google Workspace Knowledge Center