Phishing jménem domain.cz: co odhalila analýza podvrženého e-mailu

Rozbor dvou phishingových e-mailů, z nichž jeden podvrhl adresu support@domain.cz: co ukázaly hlavičky, co chybělo v DNS domény a jak nastavit SPF, DKIM a DMARC u vlastní domény.
10.11.2026 ve 13:09 přišel na adresu support@agencjezatrudnienia.pl e-mail od Noreply <support@domain.cz>. Psalo se v něm, že neprošla automatická platba, služby pro doménu agencjezatrudnienia.pl jsou pozastavené a obnovit je lze ručně přes tlačítko „Zobrazit fakturu“. Tlačítko ale nevedlo k žádnému registrátorovi. Mířilo do složky wp-content na cizím webu northwoodpark.co.uk. O 45 minut později dorazil druhý e-mail se stejným textem, jen z jiné adresy a s jiným odkazem.
Schránka běží na poštovním serveru, který provozujeme. Antispam oba e-maily doručil. Podívali jsme se proto na hlavičky, na DNS domény domain.cz i do registru CZ.NIC. Doménu drží ACTIVE 24, s.r.o. Firma potvrdila, že e-mail neodeslala, a hlavičky to potvrzují. Doména ale neměla v DNS záznamy DMARC ani SPF, podle kterých přijímající servery poznají podvrh spolehlivěji než podle obsahu zprávy. ACTIVE 24 o tom ví od 10.11. a do zveřejnění tohoto rozboru se na tom nic nezměnilo.
Šablona, která se tváří jako jiný hosting
Předmět obou zpráv napodoboval název jiného českého hostingu. Čtyři písmena v něm ale nebyla latinka: а, Н, і a с byla cyrilská. Člověk rozdíl nevidí, počítač ano, a filtr, který hledá konkrétní název, takový předmět snadno přehlédne. Loga útočníci ani nehostovali, vložili je jako odkazy na náhledy z Google Obrázků. Jedno patřilo napodobovanému hostingu, druhé britskému hostingu Krystal. Odhad: šablona nejspíš zbyla z kampaně proti zákazníkům jiného poskytovatele.
Útočník o příjemci nepotřeboval nic vědět. Doménu, které se „pozastavení“ týkalo, vzal z adresy, na kterou psal, a jako datum vypršení dosadil den odeslání. S jednou šablonou a seznamem adres tak každá zpráva působí jako upozornění na konkrétní službu konkrétního zákazníka.
Dva e-maily, dvě různé cesty
| 1. e-mail | 2. e-mail | |
|---|---|---|
| Doručeno | 10.11.2026, 13:09 | 10.11.2026, 13:54 |
From |
support@domain.cz |
support-klarnarefund@telesys-japan.com |
Return-Path |
sf21@www1071.sakura.ne.jp |
stejný jako From |
| Odesílající server | www1071.sakura.ne.jp, IP 219.94.129.81, Japonsko |
Alibaba Cloud DirectMail, IP 8.219.25.24, Singapur |
| SPF / DKIM / DMARC | none / none / none |
pass / pass / pass (politika none) |
| Skóre Rspamd | 4,93 z 15 | 2,41 z 15 |
| Odkaz vedl na | northwoodpark.co.uk |
sandboxwp.sfadev.com |
První e-mail je klasický podvrh. Do pole From útočník napsal support@domain.cz, ale zprávu odeslal ze sdíleného webhostingu japonské firmy Sakura Internet. Podle hlaviček Received ji do poštovního systému serveru předal místní uživatelský účet sf21. Odhad: jde o zneužitý hostingový účet nebo podstrčený skript, ověřené to ale nemáme. O tom, kdo útočník je a odkud pochází, tento údaj neříká nic.
Druhý e-mail žádnou adresu nepodvrhl. Přišel z domény telesys-japan.com přes službu Alibaba Cloud a prošel SPF, DKIM i DMARC. Nevíme, jestli doménu ovládá útočník, nebo jde o zneužitý účet. Na výsledku to nic nemění: DMARC potvrzuje, že zpráva opravdu pochází z domény ve From. Neříká, že je ta doména důvěryhodná. RFC 7489 to v oddílu 6.7 píše výslovně. Rspamd dal druhému e-mailu za úspěšné ověření minusové body, takže skončil s nižším skóre než podvrh. Část adresy klarnarefund navíc odkazuje na další typ podvodu. Odhad: útočníci stejnou infrastrukturu používají pro víc kampaní.
Proč první e-mail prošel filtrem
Výsledek spf=none u prvního e-mailu se týká obálkové domény www1071.sakura.ne.jp, ne domain.cz. SPF totiž kontroluje jen obálku a na viditelné pole From se vůbec nedívá. Obě adresy dává dohromady až DMARC. Ten chce, aby SPF nebo DKIM prošly pro stejnou doménu, jaká je ve From. Tomu se říká alignment. Rspamd zapsal DMARC_NA pro domain.cz: doména žádnou politiku nezveřejnila, takže přijímající server od vlastníka nedostal žádný pokyn, co s podvrhem dělat.
Body přidala pravidla FORGED_W_BAD_POLICY (3,00), URI_COUNT_ODD (1,00), AUTH_NA (1,00) a R_MIXED_CHARSET (0,25) za míchané písmo v předmětu. Pravidla FROM_NEQ_ENVFROM a FORGED_SENDER, která hlásí rozdíl mezi From a obálkou, měla váhu nula. Ten rozdíl mají i běžné newslettery a fakturační systémy. Jedno pravidlo skóre dokonce snížilo: MIME_FROM_MX_GOOD (−0,10) za to, že doména ve From má funkční poštovní server perimeter.active24.cz. Celkem to dalo 4,93 bodu. Číslo 15 ve výpisu je práh pro odmítnutí, ve výchozím nastavení Rspamd označí zprávu jako spam od 6 bodů. Filtr tedy podvod zaznamenal, jen mu chyběl signál, který by zprávu dostal přes hranici. Ten mohla dodat DMARC politika vlastníka domény.
Odkazy vedly na cizí weby s WordPressem
Oba odkazy mířily na weby s WordPressem, které s hostingem ani s doménami nesouvisejí. sandboxwp.sfadev.com je podle názvu vývojová instalace. VirusTotal tento druhý odkaz při kontrole 11.11. označil jako škodlivý. Odhad: oba weby jsou napadené a útočníkům slouží jako jednorázový hosting. Jejich majitelé s kampaní nejspíš nemají nic společného.
První odkaz jsme nechali projít izolovaným skenerem urlscan.io. Sken skončil na obyčejné stránce Google. Druhý odkaz urlscan.io skenovat odmítl. Přesměrování na Google je u phishingových sad běžný trik: automatický sken poznají podle IP adresy datacentra nebo podle prohlížeče, pošlou ho pryč a podvodný formulář ukážou jen skutečnému návštěvníkovi. Co by uviděl příjemce, proto zdokumentované nemáme a netvrdíme, že stránka sbírala karty nebo hesla. Celé odkazy v článku záměrně neuvádíme.
Proč zrovna domain.cz
Napodobovaný hosting má na hlavní doméně DMARC s politikou p=reject. Na variantě názvu bez pomlčky, kterou nejspíš drží právě proti zneužití, má navíc v=spf1 -all a sp=reject pro subdomény. Podvrhnout jeho adresu by u serverů, které DMARC kontrolují, neprošlo. To je přesně nastavení, které by měla mít každá doména se jménem, jež se dá zneužít, a provozovateli za ně patří uznání. Odhad: útočníci proto do pole From nedali adresu napodobované značky, ale sáhli po nechráněné doméně se jménem, které v e-mailu o fakturách za domény zní věrohodně.
Co bylo v DNS domény domain.cz
DNS jsme kontrolovali 11.11.2026 ve 22:33 a znovu ve 23:15 SEČ přes veřejné resolvery Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9) a ODVR CZ.NIC (193.17.47.1) a také přímo na autoritativních serverech alfa.ns.active24.cz a beta.ns.active24.cz. Všude se vrátily stejné záznamy. Nezávislý test EasyDMARC ve 22:47 dopadl stejně: DMARC chybí, SPF chybí, DKIM nenalezen, hodnocení 0 z 10. Oba výstupy zveřejňujeme: report EasyDMARC (PDF, 11.11.2026, 22:47) a výpis DNS dotazů (TXT, 11.11.2026, 23:15).
| Záznam | Výsledek | Co to znamená |
|---|---|---|
| Držitel (CZ.NIC) | SB:GLOBE-SGLO000001, ACTIVE 24, Praha 8; registrátor REG-ACTIVE24 |
Doménu drží ACTIVE 24 |
| MX | perimeter.active24.cz, mx2.active24.com |
Doména přijímá poštu |
| SPF | Jediný TXT záznam je MS=ms99892746, žádný v=spf1 |
Není určeno, které servery smějí za doménu odesílat |
| DMARC | _dmarc vede přes CNAME na www.domain.cz, kde je jen A záznam, žádný TXT |
Žádná politika |
| DKIM | 9 běžných selektorů skončí na stejném CNAME | Neprokazuje, že DKIM chybí |
| DNSSEC | Zóna je podepsaná | Odpovědi zóny lze kryptograficky ověřit |
Jméno _dmarc nemá v zóně vlastní záznam. Zóna ale obsahuje zástupný (wildcard) záznam, který na www.domain.cz pošle jakékoli jméno, třeba i náhodné nextrey-test-x7q.domain.cz. Dotaz na DMARC tak nedostane odpověď „neexistuje“, ale odkaz na webový server, kde žádný TXT záznam není. Pro přijímající server je to totéž, jako kdyby DMARC chyběl. Oprava je přitom snadná: podle RFC 4592 má explicitní TXT záznam na _dmarc.domain.cz přednost před wildcardem.
Na stejný CNAME skončilo i devět selektorů DKIM, které jsme zkusili (default, selector1, google a další). Klíč DKIM ale leží pod jménem selektor._domainkey.domena a selektor zná jen ten, kdo zprávy podepisuje. Kdyby byl některý selektor zapsaný explicitně, přebil by wildcard. Netvrdíme proto, že domain.cz DKIM nemá. Na prvním e-mailu to stejně nic nemění, podvrh podepsaný nebyl.
SOA záznam zóny uvádí sériové číslo 2018061402 a primární server ns.globe.cz. Odhad: pokud provozovatel sériové číslo vede v obvyklém formátu RRRRMMDDnn, zóna se naposledy měnila 14.6.2018. Formát ale povinný není a některé DNS systémy čísla generují jinak. Identifikátor držitele SB:GLOBE-… spolu s ns.globe.cz naznačuje starší, převzatou doménu. Že se na ni při zavádění DMARC zapomnělo, je jen naše domněnka.
Hlavní domény ACTIVE 24 chráněné jsou
Stejné dotazy jsme položili i pro active24.cz a active24.com:
_dmarc.active24.cz "v=DMARC1; p=quarantine; sp=quarantine; pct=100; rua=mailto:dmarc-report@active24.cz; ..."
active24.cz "v=spf1 mx ip4:81.95.96.0/20 ... include:spf.protection.outlook.com ... -all"
_dmarc.active24.com "v=DMARC1; p=reject; rua=mailto:dmarc-report@active24.cz;"
active24.com "v=spf1 -all"
Doména active24.com má přesně takové nastavení, jaké patří doméně, ze které se poštu posílat nemá: SPF nepovoluje žádný server a DMARC žádá odmítnutí. Firma tedy ví, jak na to, a na hlavních doménách to dělá. domain.cz mezi ně nepatří, přestože se svým jménem do podvodů s „fakturou za doménu“ hodí jako málokterá.
Příjmu pošty to nijak nepřekáží. MX záznamy řídí doručování příchozích zpráv, kdežto SPF a DMARC se týkají jen pošty odeslané jménem domény. Pokud z domain.cz žádná legitimní pošta neodchází, dva TXT záznamy podle vzoru active24.com by příjem neovlivnily. Pokud odchází, je potřeba nejdřív zjistit odkud. Který případ platí, nevíme.
Jak reagovala ACTIVE 24
První e-mail jsme podpoře ACTIVE 24 přeposlali ještě 10.11.. V noci na 11.11. přišla odpověď zákaznického specialisty v plném znění:
Dobrý den, zmíněný email nebyl odeslán naší společností, jedná se o phishingový email jenž nebyl odeslán z naší infrastruktury. V případě dalších otázek, či požadavků, nás neváhejte kontaktovat.
To je pravda a hlavičky to potvrzují. Nic nenaznačuje, že by se někdo dostal do systémů ACTIVE 24 nebo že by unikla data jejích zákazníků. Odpověď se ale nevyjádřila k tomu, kvůli čemu jsme psali: že doménu lze takto zneužít.
Dopoledne 11.11. jsme proto napsali znovu a položili čtyři konkrétní otázky:
- Proč na
domain.cznení publikovaný DMARC? - Pokud doména poštu neodesílá, proč její zneužití neomezují restriktivní záznamy SPF a DMARC?
- Plánuje ACTIVE 24 konfiguraci napravit?
- Může podnět předat odpovědnému pracovníkovi nebo bezpečnostnímu týmu?
Ke 23:15 téhož dne odpověď nepřišla a DNS domény domain.cz zůstalo beze změny. Upozornění na problém tedy firma má od 10.11., a ani po více než dni se v nastavení domény nic nepohnulo. Jakmile odpověď dostaneme nebo se konfigurace změní, doplníme to sem.
Co by DMARC u těchto e-mailů změnil
První e-mail by kontrolou DMARC neprošel: SPF se domain.cz vůbec netýkalo a podpis DKIM chyběl. S politikou p=reject by ho server, který politiku dodržuje, mohl odmítnout bez ohledu na antispamové skóre. Rspamd to umí, pokud je tak nastavený. Gmail od 1.2.2024 vyžaduje DMARC od každého, kdo mu denně posílá přes 5 000 zpráv, takže u velkých odesílatelů je to dnes samozřejmost.
Druhý e-mail ukazuje, kde DMARC končí. Proti doméně, kterou útočník ovládá nebo jejíž účet zneužil, nepomůže, protože ověřením projde. Stejně tak nepomůže proti podobně vypadajícím doménám typu dornain.cz nebo proti zobrazovanému jménu „ACTIVE 24 fakturace“ s úplně jinou adresou. Útočník ale musí sáhnout po doméně bez historie a bez reputace, kterou lze nahlásit a zablokovat, a v poli From už nemá jméno, které příjemce zná. Napodobovaný hosting tohle zařídil. U domain.cz dostal útočník důvěryhodné jméno zadarmo.
Jak zkontrolovat vlastní doménu
Základní kontrola zabere v terminálu pár minut:
dig +short TXT _dmarc.vasedomena.cz # má vrátit "v=DMARC1; ..."
dig +short TXT vasedomena.cz | grep spf1 # právě jeden záznam "v=spf1 ... -all"
dig +short MX vasedomena.cz # kdo přijímá poštu
dig +short TXT selektor._domainkey.vasedomena.cz # selektor najdete v hlavičce DKIM-Signature (s=)
Když _dmarc místo TXT vrátí CNAME, má zóna nejspíš wildcard jako domain.cz a DMARC ve skutečnosti chybí.
Pak přijde pracnější část, tedy zjistit, kdo všechno jménem domény posílá poštu:
- Sepište všechny služby, které posílají e-maily za vaši doménu: schránky, fakturaci, CRM, kontaktní formulář, newsletter i transakční e-maily z aplikace. Na co zapomenete, to se později ozve v podobě odmítnutých faktur.
- Dejte je do jednoho SPF záznamu zakončeného
-all. SPF smí při vyhodnocení spustit nejvýš 10 DNS dotazů (RFC 7208, 4.6.4) a každýincludese počítá i s dotazy, které vyvolá on sám. - U každé služby zapněte DKIM pod vlastní doménou. Podpis doménou poskytovatele alignment nesplní.
- Začněte s
v=DMARC1; p=none; rua=mailto:...a pár týdnů čtěte agregované reporty. Až v nich zůstanou jen podvrhy, přejděte nap=quarantinea potom nap=reject. Politiku pro subdomény určuje parametrsp=. - Nezapomeňte na varianty názvu a domény, které nepoužíváte. Podvodníkovi poslouží stejně dobře jako ta hlavní.
| Doména | SPF | DMARC | MX |
|---|---|---|---|
| Odesílá i přijímá poštu | v=spf1 include:... -all |
p=none, po reportech quarantine a reject |
Běžné MX |
| Přijímá, ale nic neodesílá | v=spf1 -all |
v=DMARC1; p=reject; sp=reject |
Běžné MX |
| Nepřijímá ani neodesílá | v=spf1 -all |
v=DMARC1; p=reject; sp=reject |
Null MX 0 . (RFC 7505) |
Null MX patří jen na domény, které poštu opravdu nepřijímají, na doménu s funkčními schránkami ho nedávejte. Širší kontrolu toho, co je o systému veřejně dohledatelné, popisuje audit bezpečnosti aplikace.
Proč o tom píšeme
Oba e-maily přišly do schránky, kterou spravujeme, a oba prošly filtrem. Poskytovatel domén a hostingu je pro takový podvod ideální maska, protože jeho zákazníci faktury za domény opravdu dostávají. Jeho vlastní domény, i ty okrajové, by proto měly být chráněné stejně jako active24.com. U domain.cz by stačily dva TXT záznamy a na jejich doplnění měla firma od našeho upozornění víc než den. Podle nás by doména s takovým jménem u firmy, která domény prodává, bez nich zůstat neměla.
Článek zachycuje stav k 11.11.2026, 23:15 SEČ. Pokud ACTIVE 24 na doplňující dotazy odpoví nebo nastavení domény změní, článek aktualizujeme.
Časté otázky
Byla ACTIVE 24 napadena?
Nic tomu nenasvědčuje. První zpráva přišla ze serveru Sakura Internet a ACTIVE 24 potvrdila, že ji neposlala. Útočník jen napsal cizí adresu do pole From, a tomu samotný protokol SMTP nijak nebrání.
Zastaví DMARC s p=reject každý podvržený e-mail?
Ne. Příjemce smí politiku ignorovat a DMARC neřeší podobné domény, podvržená zobrazovaná jména ani domény, které útočník ovládá. Druhý e-mail z tohoto případu ověřením DMARC prošel. U příjemců, kteří politiku dodržují, ale DMARC znemožní přímé zneužití konkrétní domény, což je pro phishing ta nejlevnější cesta.
Jak poznám, odkud e-mail skutečně přišel?
Zobrazte si zdrojový text zprávy. Rozhodující jsou Return-Path, nejspodnější hlavičky Received, které přidal váš server, a Authentication-Results od vašeho přijímajícího serveru. Pole From vyplňuje odesílatel.
Zdroje
- Report EasyDMARC pro domain.cz (PDF). Vygenerováno 11.11.2026 ve 22:47 SEČ: DMARC chybí, SPF chybí, DKIM nenalezen.
- Výpis DNS dotazů pro domain.cz (TXT). 11.11.2026 ve 23:15 SEČ, čtyři veřejné resolvery a autoritativní servery, včetně srovnání s
active24.czaactive24.com. - RFC 7489: DMARC. Alignment s polem
From, politikynone,quarantineareject. Oddíl 6.7: DMARC neříká, zda je zpráva „dobrá“, a příjemce nemusí politiku dodržet. - RFC 7208: SPF. SPF ověřuje obálkovou doménu. Oddíl 4.6.4: limit 10 DNS dotazů.
- RFC 6376: DKIM. Oddíl 3.6.2.1: klíč leží pod
selektor._domainkeya bez selektoru ho nelze najít. - RFC 4592: Wildcards in DNS. Explicitně existující jméno má přednost před zástupným záznamem.
- RFC 7505: Null MX. Záznam
0 .pro domény, které poštu nepřijímají. - NÚKIB: Ransomware, doporučení pro mitigaci, prevenci a reakci (PDF). Počet podvržených e-mailů lze snížit kontrolou SPF, DKIM a DMARC na straně poštovního serveru.
- Rspamd: Actions and scores. Výchozí prahy: označení jako spam od 6 bodů, odmítnutí od 15.
- Google: Email sender guidelines. Od 1.2.2024 je DMARC povinný pro odesílatele, kteří do Gmailu posílají přes 5 000 zpráv denně.
- CZ.NIC: WHOIS. Držitel a registrátor domény
domain.cz.