Podvržené e-maily z českých firemních domén

Souhrn

Pro vedení firmy: E-mail, který dorazí do schránky vaší účtárny nebo vašeho jednatele, může mít v poli „Od" adresu vaší vlastní firemní domény, a přitom ho neposlal nikdo z vaší firmy. Jestli takovou zprávu přijímající poštovní server propustí, rozhoduje veřejný DNS záznam, který si každá firma spravuje sama, ale většina ho nikdy nenastavila. CIAD tento záznam živě změřil u 299 českých firemních domén a zjistil, že jen 66 z 297 hodnotitelných domén (22,2 %) dává přijímajícím serverům jasnou instrukci: podvrženou poštu s vaší doménou v poli „Od" odmítni nebo pošli do spamu.

Co SPF, DKIM a DMARC vlastně dělají

SPF, DKIM a DMARC odpovídají na tři různé otázky a mají jednu společnou mez: žádná z nich nemá moc e-mail zastavit sama o sobě, dokud o to majitel domény výslovně nepožádá.

• SPF funguje jako veřejný seznam serverů, které smí odesílat poštu jménem vaší domény, podobně jako seznam hostů na recepci. Přijímající server se zeptá DNS „je IP adresa odesílatele na seznamu pro tuto doménu?" a podle odpovědi ví, jestli sedí.
• Ke každé odchozí zprávě se navíc přilepí DKIM, kryptografický podpis podobný voskové pečeti. Dokazuje, že zprávu opravdu vytvořil server, který drží soukromý klíč patřící k vaší doméně, a že cestou nebyla změněna.
• Když zpráva SPF ani DKIM kontrolou neprojde, rozhoduje DMARC. Řekne přijímajícímu serveru, co s takovou zprávou udělat, a kam poslat report o tom, kdo všechno se vaší doménou v daném období vydával.

Konkrétní riziko, které DMARC bez vynucující politiky nechává otevřené: kdokoli může poslat e-mail, jehož viditelná adresa odesílatele je vaše vlastní firemní doména, a přijímající poštovní server nedostal od vlastníka domény pokyn takovou zprávu odmítnout. To je přesně mechanismus za fakturačním podvodem (účtárna pošle platbu na jiný účet, protože zpráva vypadá jako od skutečného dodavatele) a za podvodem na jednatele, tzv. CEO fraud (zpráva vypadá, že ji poslal jednatel firmy, a žádá účtárnu o naléhavou platbu).

Přesné tvrzení zní: majitel domény nedal přijímajícím serverům instrukci podvrženou poštu odmítnout · ne že každá taková zpráva projde. Velcí poskytovatelé jako Gmail nebo Microsoft 365 aplikují vlastní heuristiky nezávisle na DMARC politice odesílající domény a část podvržené pošty zachytí i bez ní. DMARC politika je nástroj, který dává instrukci výslovně a spolehlivě, ale není to jediná obrana, kterou firma má.

Vzorek a jeho meze

Vzorek je konvenienční, ne náhodný: 299 českých komerčních domén z výzkumného korpusu, který CIAD dlouhodobě používá napříč paralelními bezpečnostními studiemi. Není sestavený náhodným výběrem a nepokrývá žádný konkrétní obor ani celou českou ekonomiku. Každé procento v tomto textu se proto vztahuje výhradně k těmto 299 zkoumaným doménám, nikdy k českým firmám obecně · tento rozdíl se v textu dodržuje důsledně.

Sken byl čistě pasivní, a to doslova: šlo výhradně o DNS dotazy (dig proti resolverům 1.1.1.1 a 8.8.8.8), žádný paket nešel přímo na webový server ani poštovní server žádné zkoumané domény. Žádné odeslání e-mailu, žádné SMTP spojení, žádná autentizace, žádné testování zranitelností.

Jednotlivé metriky mají různé základy, protože ne každá doména má DNS záznam, na který se dá metrika vůbec vztáhnout:

31 domén z SPF základu vypadlo, protože samotná doména nemá v DNS vůbec žádný záznam (apex NXDOMAIN) · to je jiná kategorie než doména, která existuje, ale SPF záznam nepublikuje, a míchat je dohromady by číslo zkreslilo. Nedostupná nebo neexistující doména se v žádné z tabulek níže nepočítá jako „chybí SPF/DMARC".

Hlavní zjištění: jen 66 z 297 domén vynucuje DMARC

Z 297 hodnotitelných domén (3. 8. 2026) má 66 (22,2 %) DMARC politiku nastavenou na quarantine nebo reject · politiku, která přijímajícímu serveru dává jasnou instrukci pro poštu, jež neprojde SPF nebo DKIM kontrolou a tvrdí, že je z dané domény. Zbylých 231 domén (77,8 %) takovou instrukci nedává: 158 nemá DMARC záznam vůbec, 73 má záznam s politikou p=none, která přijímajícímu serveru říká jen „sleduj a nic nedělej". Zjištění popisují technický stav veřejně dostupné infrastruktury k datu měření a nepředstavují právní posouzení jednotlivých subjektů.

Sečteno podle toho, jestli politika dává vynucující instrukci, nebo ne:

Nejostřejší dílčí nález: p=none bez reportování

Politika p=none sama o sobě je legitimní první krok monitorovacího nasazení, který ukáže majiteli domény, kdo všechno jeho jménem posílá poštu, než přitvrdí na quarantine nebo reject. Rozhoduje ale to, jestli má doména zapnuté i reportování (rua= adresa v DMARC záznamu), protože bez reportů majitel domény nevidí, co by mu vynucující politika zablokovala, a nemá tak podklad pro další krok.

Vztaženo k celému vzorku 297 hodnotitelných domén: 31 domén s reportováním tvoří 10,4 % všech hodnotitelných domén, 42 domén bez reportování tvoří 14,1 % všech hodnotitelných domén. Skupina bez reportování nemá žádný přehled o tom, co by přísnější politika zablokovala, a tedy ani datový podklad pro krok k quarantine nebo reject · z hlediska cesty k vynucení jde o stejně slabou pozici, jako kdyby tyto domény DMARC záznam neměly vůbec.

SPF: kdo smí odesílat poštu za doménu

U 205 domén s SPF záznamem záleží i na tom, jak tvrdě je pravidlo formulované · kvalifikátor na konci záznamu:

~all říká přijímajícímu serveru „server mimo seznam je podezřelý, ale neodmítej ho kvůli tomu automaticky" · slabší instrukce než -all, prakticky srovnatelná svým dopadem s tím, co dělá DMARC politika p=none. Žádná ze 266 hodnotitelných domén neměla víc než jeden SPF záznam současně (chyba, které se říká permanentní chyba podle RFC 7208), takže tahle metrika je jednoznačná.

DKIM: proč tu není jedno procento „chybí DKIM"

DKIM se od SPF a DMARC liší v jedné podstatné věci: selektor, pod kterým je DKIM klíč publikovaný v DNS, si volí odesílající server a může to být libovolný řetězec. Sken vyzkoušel 25 nejběžnějších selektorů na doménu, u domén se známým poskytovatelem (Google Workspace, Microsoft 365, Zoho) i podle jejich zdokumentované konvence · ale nenalezení žádného z 25 vyzkoušených selektorů neznamená, že DKIM neexistuje, jen že neexistuje pod žádným z vyzkoušených jmen. Skutečné potvrzení nepřítomnosti by vyžadovalo zachytit hlavičku DKIM-Signature ze skutečné odchozí zprávy, což pasivní DNS sken neumí. Proto se DKIM v této studii nepublikuje jako jedno procento, ale jako čtyři kategorie:

Jediná dvojice kategorií, u které má smysl počítat podíl, jsou první dvě: domény se známým poskytovatelem, kde selektorová konvence je zdokumentovaná a nález je tedy spolehlivý.

Co se z tohoto čísla nesmí tvrdit: 22,4 % je podíl v rámci 156 určitelných domén, ne podíl z celého vzorku 299. 143 domén (47,8 % z 299) je technicky neurčitelných · 66 z nich nemá MX vůbec, tedy poštu na dané doméně nepřijímá, u 2 dalších skončil MX dotaz chybou (proto je v tabulce výše řádek 68, zatímco základ pro MX je 297 domén), a 75 běží na poskytovateli, jehož selektorovou konvenci sken nezná. Tvrzení typu „X % českých firemních domén nemá DKIM" by z tohoto skenu bylo nepravdivé, protože by tiše zahrnulo domény, u kterých je odpověď skutečně „nevíme", ne „ne". Sken navíc obsahoval kontrolu na falešně pozitivní nálezy (náhodný nesmyslný selektor vrátil NXDOMAIN, ne zásah přes wildcard DNS), takže 121 nalezených případů je spolehlivých.

Kontext k oběma neurčitelným kategoriím: z celého vzorku 297 domén hodnotitelných pro MX má 231 (77,8 %) nastavený MX záznam a přijímá poštu, 66 (22,2 %) MX záznam nemá vůbec. Mezi těmi 231 doménami s MX rozpoznal sken poskytovatele u 128 z nich:

Vedlejší zjištění, které do DKIM kapitoly patří jako kontrola konzistence: jednou z podmínek pro BIMI (zobrazení firemního loga přímo ve schránce příjemce) je vynucující DMARC politika. Sken ho zaznamenal u 5 z 296 hodnotitelných domén (1,7 %) · nízké číslo, které je v souladu s tím, že vynucující DMARC politiku má jen 66 domén z celého vzorku.

Co s tím: jak si ověřit vlastní doménu

Jak si to ověřit u vlastního webu: pošlete svému IT nebo hostingovému poskytovateli žádost o kontrolu SPF, DKIM a DMARC záznamu, nebo si nechte technicky zdatným kolegou spustit tyto dva dotazy (kdokoli, kdo spravuje DNS vaší domény, je zvládne za pár vteřin):

• dig txt vasedomena.cz +short · hledejte řádek začínající v=spf1. Pokud tam není, SPF chybí.
• dig txt _dmarc.vasedomena.cz +short · hledejte řádek začínající v=DMARC1 a v něm hodnotu p=.

Co jednotlivé hodnoty p= znamenají:

• p=none · přijímající server nedělá nic navíc, jen (pokud je nastavené rua=) pošle report o tom, co by neprošlo.
• p=quarantine · přijímající server pošle podezřelou zprávu do spamu nebo karantény.
• p=reject · přijímající server podezřelou zprávu vůbec nedoručí.

Doporučený postup je zpřísňovat po krocích, od nejmírnějšího nastavení k nejtvrdšímu:

1. Nemám DMARC vůbec. Přidejte záznam s p=none a vyplněnou adresou pro rua=. Tohle samo o sobě nic neblokuje, jen začne posílat data o tom, kdo vaším jménem posílá poštu · včetně legitimních nástrojů (fakturační systém, marketingová platforma), na které je potřeba myslet, než se přitvrdí.
2. Mám p=none a pár týdnů reportů. Až reporty ukážou, že žádná legitimní pošta neprochází mimo SPF/DKIM, přejděte na p=quarantine.
3. Mám p=quarantine stabilně bez ztráty vlastní pošty. Přejděte na p=reject · to je politika, kterou v datech mělo jen 31 z 297 zkoumaných domén.

Metodika

Detail dostatečný k tomu, aby ho kdokoli zopakoval na stejném vzorku:

• Zdroj vzorku: 299 českých komerčních domén z výzkumného korpusu, který CIAD používá napříč paralelními bezpečnostními studiemi.
• Datum skenu: 3. 8. 2026, jeden živý běh, žádná archivní data.
• Metoda: výhradně DNS dotazy přes dig proti dvěma nezávislým resolverům (1.1.1.1 a 8.8.8.8), žádné spojení přímo s webovým nebo poštovním serverem zkoumané domény.
• SPF: TXT dotaz na apex domény, hledání záznamu v=spf1, kontrola na víc než jeden současný SPF záznam (permanentní chyba podle RFC 7208).
• DMARC: TXT dotaz na _dmarc.<doména>, kontrola na víc než jeden současný DMARC záznam (podle RFC 7489 se v takovém případě zpracování zastavuje).
• DKIM: test 25 nejběžnějších selektorů na doménu, u domén se známým poskytovatelem podle poskytovatelovy zdokumentované konvence (Google Workspace, Microsoft 365, Zoho). Nalezené případy potvrzeny na sekundárním resolveru (118 z 121 shodně, 3 jen na primárním). Negativní kontrola: náhodný nesmyslný selektor vrátil NXDOMAIN, ne zásah přes wildcard DNS.
• MX a poskytovatel: MX dotaz na apex domény, poskytovatel odvozen z cílové domény MX záznamu tam, kde je konvence jednoznačná.
• BIMI: TXT dotaz na default._bimi.<doména>.
• Základ pro výpočet podílu: 297 pro MX a DMARC (299 mínus 2 chyby DNS dotazu), 266 pro SPF (299 mínus 31 domén bez záznamu v DNS vůbec a 2 chyby dotazu), 299 pro DKIM kategorie, 156 pro určitelnou DKIM podmnožinu (nalezeno + nenalezeno u známého poskytovatele), 296 pro BIMI. Doména, u které dotaz skončil chybou, se nikdy nepočítá jako „záznam chybí".
• Práh pro zveřejnění segmentu: žádná kategorie s méně než 10 doménami se nepublikuje jako samostatný řádek u kombinovaných rozpadů · menší kategorie jsou sloučené do „ostatní".
• Rozsah skenu: výhradně DNS dotazy popsané výše. Žádné odeslání e-mailu, žádné SMTP spojení, žádná autentizace, žádné testování zranitelností, žádný zásah do funkčnosti domény.
• Publikovaná data: pouze agregáty · žádná doména, žádné jméno firmy. Podrobná data z jednotlivého skenu nejsou veřejná.

Data ke stažení

Agregovaná data ke stažení pod licencí CC BY 4.0 · JSON i CSV, bez doménových jmen a bez jmen firem. Kdokoli může data ověřit, přepočítat nebo citovat s odkazem na tuto stránku.

Stáhnout JSON · Stáhnout CSV