PCI DSS, bezpečnostní standard, který musí dodržovat každá firma přijímající platby kartou, neuvádí DMARC jako povinný kontrolní mechanismus. Od 31. března 2025 ale verze 4.0.1 tohoto standardu vyžaduje automatizovaná opatření proti phishingu a Rada pro bezpečnostní standardy PCI (PCI Security Standards Council) ve svých pokynech uvádí DMARC, SPF a DKIM jako schválené způsoby, jak požadavek na ochranu před phishingem splnit. Pokud přijímáte platby kartou, měli byste tedy DMARC považovat za očekávaný, i když ho standard nikdy neuvádí jako povinný.
Blogové články od dodavatelů běžně tvrdí, že PCI DSS "vyžaduje DMARC". Toto tvrzení není zcela přesné a při auditu PCI na tom rozdílu záleží. Tento článek vysvětluje, co říká požadavek 5.4.1, kam do něj DMARC zapadá a co musí udělat lidé, kteří spravují vaše DNS a compliance. Pokud přijímáte platby kartou přes web, tato práce spadá na váš IT nebo bezpečnostní tým, případně na agenturu, která spravuje vaši doménu.
Kliknutím na odkazy přejdete na konkrétní sekci.
Jmenovitě ne. PCI DSS verze 4.0.1, aktuální vydání standardu, ukládá organizacím povinnost zavést automatizované mechanismy proti phishingu. V samotném požadavku ale neuvádí žádnou konkrétní technologii. K pojmenování dochází až v pokynech, kde Rada pro bezpečnostní standardy PCI píše, že mechanismy proti spoofingu jako DMARC, SPF a DKIM "mohou pomoci zabránit útočníkům ve falšování domény dané organizace a vydávání se za její zaměstnance".
Pokyny PCI tedy DMARC doporučují; neuvádějí ho jako povinný kontrolní mechanismus. V praxi je tady rozdíl mezi "doporučeným" a "povinným" malý. SPF, DKIM a DMARC jsou standardní, zdokumentovaný způsob, jak zastavit falšování domény, takže auditor, který hledá automatizované mechanismy proti phishingu, je bude očekávat. Praktická rada je jednoduchá: zaveďte DMARC, protože auditor po něm bude pátrat. Netvrďte, že ho standard jmenovitě vyžaduje, protože to není pravda a auditor ten rozdíl pozná.
Příslušným pravidlem je požadavek 5.4.1: musí existovat procesy a automatizované mechanismy, které detekují phishingové útoky a chrání před nimi zaměstnance. Klíčové slovo je tady "automatizované". Samotné školení o bezpečnostním povědomí požadavek nesplňuje, protože standard chce běžící technický mechanismus, ne jen poučené zaměstnance.
Požadavek 5.4.1 byl zveřejněn jako požadavek s budoucí účinností, což znamenalo, že byl po dobu, kdy se na něj organizace připravovaly, volitelný. Toto přechodné období skončilo 31. března 2025. Od té doby je požadavek na ochranu před phishingem povinný: auditor ho kontroluje během posuzování PCI DSS a už ho nelze odkládat jako pouhý osvědčený postup.
Pokyny také doporučují uplatňovat mechanismy proti phishingu napříč celou organizací, ne jen na systémech, které ukládají nebo zpracovávají data o platebních kartách. DMARC to dělá automaticky: jediná DMARC zásada platí pro každou adresu na vaší doméně, takže ji nemusíte rozšiřovat systém po systému.
To je nasnadě, protože standard DMARC nejmenuje. Požadavek 5.4.1 se týká ochrany vašich lidí před phishingem, takže jeho část můžete splnit i jinými nástroji: zabezpečenou e-mailovou gateway, anti-phishingovým filtrem, kontrolou odkazů a příloh nebo automatizovaným školením o bezpečnostním povědomí. Většina firem, které přijímají platby kartou, už některé z nich provozuje a měli byste si je ponechat.
Tyto nástroje ale kontrolují poštu jen ve chvíli, kdy dorazí do vašich vlastních schránek. Nijak nezabrání útočníkovi, aby ve vaší adrese odesílatele (From) zfalšoval vaši doménu a phishingem zaútočil na vaše zákazníky, partnery nebo zaměstnance. Jediný praktický způsob, jak takovéto falšování domény zastavit, je autentizace e-mailů: SPF, DKIM a DMARC fungující společně. Skutečná náhrada neexistuje. Proto pokyny PCI jmenují všechny tři a proto auditor očekává, že je uvidí, i když je požadavek výslovně neuvádí.
Zveřejnit DMARC záznam není totéž co ho prosazovat a právě tady mnoho firem zaostává za tím, oč požadavku jde.
DMARC záznam s p=none běží v režimu pouze pro monitoring. Říká přijímajícím serverům, aby reportovaly poštu, která neprojde autentizací, a pak ji přesto doručily. Získáte přehled, což je užitečné, ale zfalšovaná zpráva, která se tváří jako z vaší domény, se do schránky stejně dostane. Nic se neblokuje. Jako mechanismus proti phishingu zastaví záznam p=none nula útoků.
Abyste zfalšovanou poštu zablokovali, potřebujete DMARC v režimu prosazování: p=quarantine posílá zprávy, které neprojdou, do spamu a p=reject je rovnou odmítne. Právě prosazování zabrání někomu, aby zfalšoval vaši doménu a phishingem zaútočil na vaše zákazníky nebo zaměstnance. PCI neuvádí povinnou úroveň zásady, takže tohle je naše čtení, ne řádek ve standardu. DMARC záznam, který nic neblokuje, se ale jako mechanismus proti phishingu před auditorem obhajuje těžko.
Právě tady je většina domén zranitelná. V průmyslové zprávě DMARCeye za Q1 2026 z domén, které DMARC zveřejňují, sedí 36,7 % na p=none, 36,8 % na p=quarantine a 26,5 % na p=reject. Více než třetina zveřejňuje DMARC záznam, který nic neblokuje, protože je nastavený jen na monitoring. Náš kompletní rozbor mezery v prosazování má úplná čísla o tom, kolik domén nikdy nepřejde z monitoringu dál.
Zadejte svou doménu a podívejte se, jaká je vaše aktuální DMARC zásada a jestli je nastavená na prosazování:
Nejprve určete, kdo má DMARC na starosti. Zveřejnění a zpřísnění DMARC záznamu je úkol pro správu DNS a autentizace e-mailů, ne pro marketing. Ve větší firmě spadá pod IT nebo bezpečnost. V malé firmě obvykle připadne tomu, kdo spravuje vaši doménu: vašemu IT dodavateli, vašemu webhostingu nebo agentuře, která vám provozuje e-mail a DNS. Pokud zodpovídáte za PCI compliance, ale DNS sami nespravujete, vaším úkolem je zadat práci správné osobě a před auditem potvrdit, že je hotová.
Technické kroky v pořadí:
SPF a DKIM pro každou službu, která posílá poštu pod vaší doménou. DMARC na obou závisí.p=none, abyste začali sbírat reporty, aniž by to ovlivnilo doručování.p=quarantine a poté na p=reject, jakmile reporty ukazují jen odesílatele, které poznáváte. Toto je nastavení, které naplňuje záměr ochrany před phishingem.Chyba, které je třeba se vyhnout, je skočit na p=reject dřív, než zmapujete své odesílatele. Když prosazování zapnete příliš brzy, začne se blokovat legitimní pošta, včetně potvrzení o platbě, na která vaši zákazníci čekají. Náš kompletní průvodce implementací DMARC krok za krokem provádí přechodem na prosazování.
PCI DSS není jediná síla, která firmy tlačí k prosazování DMARC. Od roku 2024 Google a Yahoo vyžadují, aby hromadní odesílatelé zveřejnili DMARC, a Microsoft od té doby nastavil stejné očekávání pro odesílatele velkých objemů do Outlooku a Hotmailu. Velcí poskytovatelé schránek i platební standard teď chtějí totéž: autentizujte svou poštu a zabraňte ostatním ve falšování vaší domény.
Pro firmu, která přijímá platby kartou a zároveň posílá marketingovou nebo transakční poštu, pokrývá obě povinnosti jeden projekt. Prosazování DMARC, které zavedete kvůli PCI, je stejný mechanismus, jaký poskytovatelé schránek očekávají. Náš průvodce požadavky Googlu a Yahoo na odesílatele tuto stránku popisuje podrobně.
PCI DSS v4.0.1 nepřidal DMARC na seznam povinných kontrolních mechanismů a měli byste být obezřetní vůči každému, kdo vám tvrdí, že ano. Co ale udělal, je, že učinil ochranu před phishingem povinnou a jako způsob, jak ji zajistit, odkázal na DMARC, SPF a DKIM. Nejvíc záleží na prosazování: DMARC záznam s p=none problém dokumentuje, zatímco p=quarantine nebo p=reject ho řeší.
DMARCeye čte DMARC reporty, které vaše doména dostává, a srozumitelně vám ukáže, kteří odesílatelé jsou legitimní a kdy je bezpečné přejít na prosazování, aby krok od monitoringu ke compliance nerozbil poštu, na které vaši zákazníci závisí.