Bezpečnost e-mailu: Jak zavést SPF, DKIM a DMARC

01Určete, před čím má autentizace chránit

Zobrazené jméno odesílatele, adresa a skutečný způsob odeslání jsou odlišné věci. Útočník může napsat jméno vašeho ředitele nebo zkusit použít firemní doménu v adrese From. Autentizace pomáhá přijímajícímu systému posoudit doménu, která je se zprávou spojená. Neprokazuje, že konkrétní člověk schválil fakturu, ani že je obsah zprávy pravdivý.

DMARC neodstraní podvody z podobně vypadajících domén. Když si někdo zaregistruje jinou adresu a správně ji autentizuje, může jeho zpráva technickou kontrolou projít. Stejně tak může projít zpráva odeslaná z napadeného skutečného účtu. Ověřování změn bankovních údajů a ochranu přihlášení proto zachovejte i po zavedení všech tří mechanismů.

Praktický cíl zapište přesně: omezit neoprávněné použití vlastní domény, objevit neznámé odesílací služby a udržet přehled o doručování legitimní pošty. Úspěšný DMARC není certifikát bezpečnosti celé firmy. Ochranu účtů řešte souběžně, například podle našeho průvodce zavedením MFA a passkeys.

02Sepište všechny systémy, které posílají vaším jménem

Začněte inventurou, nikoli přísnější politikou. Poštu často neposílá jen Microsoft 365 nebo Google Workspace. Odesílá také e-shop, CRM, fakturační nástroj, helpdesk, formulář na webu a marketingová platforma. Zapomenutá služba může fungovat pouze při měsíční uzávěrce. Týden bez chyb proto nemusí pokrývat běžný provoz.

U každé položky určete, kdo ji smí změnit a kdo rozhodne o vypnutí. Oddělte produkci od testovacího prostředí. Neznámou IP adresu z reportu nepovolujte jen proto, aby zmizela červená kontrolka. Nejprve ji spojte s konkrétní službou a jejím vlastníkem. Návrh jednotlivých proudů doplňuje článek o notifikacích a e-mailech v aplikaci.

03Rozlišujte obálku, viditelnou adresu a podpis

Adresa ve viditelné hlavičce From, technicky RFC5322.From, je to, co poštovní klient obvykle ukazuje jako odesílatele. SMTP obálka používá jinou adresu, MAIL FROM neboli RFC5321.MailFrom, spojenou mimo jiné s vracením nedoručené pošty. Domény mohou být oprávněně různé, například když newsletter posílá externí platforma.

SPF běžně ověřuje odesílající server vůči doméně z MAIL FROM, nikoli přímo vůči viditelné adrese. DKIM používá doménu uvedenou v položce d= svého podpisu. DMARC tyto ověřené identity vztáhne k doméně From. Tato shoda se nazývá alignment. Nestačí tedy zjistit, že nějaké SPF nebo nějaký podpis uspěl.

Při předání správy chtějte ukázku skutečné doručené zprávy s vysvětlením všech tří domén. Ověření pouze v administraci poskytovatele neprokáže, co odesílá vaše aplikace. Také Reply-To je samostatný údaj pro odpověď, nikoli identita, podle které DMARC ověřuje From. Rozdíl mezi adresami popisuje dokumentace Microsoftu.

04SPF určuje povolené zdroje, ne důvěryhodnost obsahu

SPF vyjadřuje, které servery smějí používat určitou doménu při odesílání. Příjemce porovnává připojenou IP adresu s publikovanými pravidly. Záznam patří k ověřované doméně; samotné přidání pravidla na hlavní firemní doménu nemusí napravit odesílání s jinou obálkovou adresou.

Podle RFC 7208 nesmí pro jednu doménu vzniknout více samostatných SPF záznamů vybraných při stejné kontrole. Další dodavatel proto obvykle znamená úpravu existujícího pravidla, nikoli přidání druhého konkurenčního SPF. Současně existuje limit deseti vyhodnocení určených typů pravidel s DNS dotazy, například include. Počítají se i vnořená pravidla; nejde jednoduše o počet řádků v administraci.

Překročení tohoto limitu vede k chybě, ne k úspěšnému ověření. Správce má prověřit celou závislost na dodavatelích, odstranit nepoužívaná oprávnění a vyhnout se zbytečně širokým rozsahům. Ani bezhlavé nahrazení odkazů pevnými IP adresami není trvalé řešení: poskytovatel je může změnit. Po změně kontrolujte skutečný výsledek a doručování, ne jen syntaktickou platnost.

05DKIM podepisuje zprávu za konkrétní doménu

Odesílající systém připojí kryptografický podpis. Příjemce získá veřejný klíč z DNS a ověří podepsané části zprávy. Soukromý klíč zůstává u systému, který podepisuje. DKIM tím spojuje zprávu s podepisující doménou a dovoluje rozpoznat změnu chráněného obsahu. Není to osobní elektronický podpis zaměstnance.

RFC 6376 odděluje podpis od šifrování. DKIM nezajišťuje utajení přílohy a neprověřuje, zda odkaz vede na bezpečný web. Potřebujete také vhodnou ochranu přenosu, účtů a obsahu. Při přeposílání může podpis přežít, pokud se podepsané části nezmění; vložená patička nebo změna předmětu ho naopak může porušit.

U externí služby ověřte podpis vlastní doménou, ne pouze doménou poskytovatele. Zapište selektor, vlastníka klíče a postup výměny. Při rotaci nejprve připravte nový klíč a ověřte nové podepisování. Starý veřejný klíč neodstraňujte dřív, než s dodavatelem zohledníte zprávy ještě čekající ve frontách. Změna musí mít důkaz úspěšného doručení.

06DMARC vyžaduje alespoň jednu úspěšnou shodnou identitu

Pravidlo podle specifikace DMARC je jednoduché: pro výsledek DMARC pass stačí úspěšné SPF se shodou domény, nebo platný DKIM podpis se shodou domény. Obojí je užitečné provozně a může být součástí požadavků poskytovatele, ale samotný výpočet DMARC nevyžaduje úspěch obou metod současně.

Při strict alignment se domény musí shodovat přesně. Relaxed alignment pracuje se stejnou organizační doménou. V modelovém příkladu From u example.org a platný podpis d=example.org odpovídají i strict režimu. U subdomén nepředpokládejte shodu jen podle podobného názvu. Správce má ověřit způsob určení organizační domény i politiku celé hierarchie.

07Politika je požadavek příjemci, nikoli příkaz pro celý internet

DMARC politika p=none žádá sledování bez zvláštního zásahu kvůli výsledku DMARC. Neznamená automatické doručení: spamový filtr může zprávu odmítnout z jiného důvodu. Politika p=quarantine žádá zacházení s neúspěšnou zprávou jako s podezřelou, například umístění do spamu. Politika p=reject žádá odmítnutí.

Konečné rozhodnutí zůstává na přijímajícím systému a jeho dalších informacích. Nezaměňujte proto DMARC fail s jistým odmítnutím ani pass s garantovaným doručením. Přehled pro vedení má oddělit výsledek autentizace od skutečného zacházení se zprávou. Právě rozdíl mezi nimi může upozornit na přeposílání nebo místní výjimku.

Zpřísnění posuzujte pro každou používanou doménu a její účel. Fakturační subdoména s řízeným odesíláním má jiný provoz než zaměstnanecké adresy používané v diskusních skupinách. Prověřte také dědění politik do subdomén. Změna na hlavní doméně může ovlivnit službu, o které autor změny nevěděl.

08Přeposílání a mailing listy prověřte před vynucováním

Při přeposlání se zpráva dostává k dalšímu příjemci z jiné IP adresy. Původní SPF pak může selhat. Úprava obálky přeposílajícím systémem může pomoci jeho vlastnímu SPF, ale nemusí vytvořit shodu s původní doménou From. Platný shodný DKIM může DMARC zachránit, pokud podpis cestou zůstane platný.

Diskusní skupina nebo bezpečnostní brána může obsah upravit a podpis porušit. Taková zpráva nemusí být podvod. ARC podle RFC 8617 umožňuje předávat ověřitelné informace o předchozích autentizačních výsledcích přes zprostředkovatele. Příjemce však musí vyhodnotit důvěryhodnost řetězce a jeho původců. Samotná přítomnost ARC není automatická propustka.

Do testů zahrňte skutečné cesty: externí přeposílání, sdílené aliasy, zákaznické brány a mailing listy, které zaměstnanci používají. Neřešte je plošným vypnutím kontroly ani univerzálním seznamem povolených domén. Pokud konkrétní cesta vyžaduje výjimku, potřebuje vlastníka, zdůvodnění a pravidelnou revizi. Ověření samotného přímého doručení tuto část nenahradí.

09Reporty používejte k rozhodování, ne jen k archivaci

Agregované reporty ukazují, odkud příjemce zaznamenal zprávy používající vaši doménu a jak dopadly kontroly. RFC 9990 popisuje například zdrojové IP adresy, počty zpráv, ověřené identity a uplatněnou politiku. Reporty nejsou úplný seznam všech odeslaných e-mailů ani potvrzení, že je zákazníci přečetli. Ne každý příjemce je poskytuje.

Vhodný přehled rozděluje známé oprávněné služby, oprávněné služby s chybou a neznámé zdroje. U chyby ukažte vlastníka a další krok. Vedle procenta úspěchu sledujte konkrétní proudy: malý počet odmítnutých resetů hesla může být závažnější než velký objem neúspěšných podvrhů.

Určete příjemce reportů, přístupy a dobu uchování. Individuální failure reporty mohou obsahovat hlavičky nebo i obsah zprávy, jak upozorňuje RFC 9991. Nezapínejte jejich rozesílání externí službě automaticky. Nejdříve posuďte potřebnost, rozsah údajů a ochranu příjemce. Pro běžný přehled začněte agregovanými výsledky. Jejich cílovou adresu určuje tag rua. Ověřte, že reporty skutečně přicházejí a nástroj je zpracovává. U cíle mimo vlastní doménu prověřte i potřebné oprávnění k přijímání reportů.

10Zavádějte podle provozních důkazů a aktuálního standardu

Připravte inventuru, odpovědnosti a plán návratu. Ověřte SPF, DKIM a shodu na reálných zprávách. Potom sledujte reporty v monitorovacím režimu a opravte legitimní proudy s chybou. Délku pozorování odvoďte od skutečných cyklů, včetně uzávěrek a sezónních kampaní. Neexistuje univerzální počet dnů, po kterém je každá doména připravená.

V květnu 2026 vyšel RFC 9989, který nahrazuje původní specifikaci DMARC. Odstranil starý parametr pct a mění zjišťování organizační domény pomocí DNS. Starší návod s postupem „zapněte reject pro deset procent“ proto nepovažujte za obecně spolehlivý bezpečnostní mechanismus. Nové testovací možnosti řešte podle podpory konkrétních systémů.

Nový standard výslovně varuje před p=reject na doménách pro běžnou komunikaci, zejména při účasti uživatelů v mailing listech. Rozhodnutí o vynucování má vycházet z doložených dopadů a charakteru domény. Přísnější politika není automaticky vhodný konečný stav pro každý typ pošty. Poskytovatelé mohou nadále používat odlišné implementace, takže kontrolujte skutečné výsledky.

Při schválené změně určete dostupného správce a hranici pro zastavení. Uchovejte předchozí hodnoty, počítejte s DNS cache a sledujte chyby u přijímajících systémů i ve vlastní aplikaci. Návrat záznamu nevrátí již odmítnuté zprávy. Obnovení důležitých podání proto musí mít vlastní bezpečný postup.

11Oddělte pravidla poskytovatele od výsledku DMARC

Google, Yahoo a Microsoft mají vlastní požadavky na odesílatele. Jejich pravidla pro hromadné či vysokoobjemové odesílání zahrnují SPF, DKIM a DMARC. Podmínky se vztahují ke konkrétním přijímajícím službám a definicím objemu, nikoli automaticky ke každé schránce na internetu.

Například technický DMARC pass přes DKIM sám o sobě nedokazuje splnění všech požadavků poskytovatele na SPF. Stejně tak monitorovací DMARC politika může splnit minimální podmínku dané služby, ale sama nežádá blokování podvrhů. Správce musí vyhodnotit obě otázky zvlášť: zda zpráva prošla DMARC a zda splňuje pravidla cílového příjemce.

Autentizace také nenahrazuje souhlas příjemců, hygienu databáze, srozumitelné odhlášení a vhodný obsah. U marketingu kontrolujte pravidla odhlášení přímo u poskytovatele. Opravený DNS záznam nevyřeší kampaň, kterou lidé opakovaně označují jako nevyžádanou. Požadavky ověřujte při změně odesílací služby a významném růstu objemu.

12Převezměte řešení a přidělte mu vlastníka

Předání nesmí skončit obrázkem zelených kontrol. Chtějte doložené výsledky hlavních odesílacích cest, seznam výjimek a provozní kontakt. Uložte konfiguraci a její zdůvodnění do dokumentace, která zůstane firmě při změně dodavatele. Přístup k DNS a službám musí odpovídat odpovědnosti za změny.

• U každého proudu je známá služba, doména a odpovědný člověk.
• Přímé i důležité nepřímé doručení má ověřený výsledek.
• Reporty někdo vyhodnocuje a předává konkrétní chyby vlastníkovi.
• Nový dodavatel nesmí začít odesílat bez kontroly autentizace.
• Odchod služby zahrnuje odebrání nepotřebných oprávnění a klíčů.
• Změna politiky má plán návratu a sledování odmítnutých zpráv.

Kontrolu opakujte při nové kampanové platformě, migraci pošty, změně aplikace i předání správy. Pravidelný provozní dohled lze spojit s měsíční péčí o web, pokud z něj odcházejí důležité zprávy. Smyslem je udržet dokumentaci v souladu se skutečným odesíláním, nikoli jednou ročně potvrdit existenci tří záznamů.

13Časté otázky k SPF, DKIM a DMARC