Jak si přečíst DMARC zásadu firmy za deset sekund (a co vám neřekne)

Jeden dotaz na DNS vám řekne, co si určitá firma přála, aby světové poštovní servery dělaly s padělanými zprávami poslanými v jejím jménu. Záznam je veřejný a příkaz je jediný řádek: dig +short TXT _dmarc.example.com. Odpověď je krátký řetězec nastavení a v něm je jedna instrukce — p=none, p=quarantine nebo p=reject — která vyjadřuje preference vlastníka domény, když zpráva s touto doménou selže při ověření identity.

Aktuální specifikace RFC 9989, zveřejněná v květnu 2026 jako dokument IETF Standards Track, nahradila starší RFC 7489. Tři hodnoty definuje téměř stroze:

• p=none — „Vlastník domény nevyjadřuje žádnou preference."
• p=quarantine — „Vlastník domény považuje takové zprávy za podezřelé. Zpráva může být platná, ale selhání ověření vytváří významný problém."
• p=reject — „Vlastník domény považuje všechna taková selhání za jasný důkaz, že použití názvu domény není platné."

Přečtěte si tato slova znovu, protože jsou slabší, než většina vysvětlení DMARC připouští. Zásada je preference zveřejněná odesílatelem, kterou mohou příjemci vzít v úvahu. Není to instrukce, kterou je příjemce povinen provést. RFC 9989 to říká jednou větou: „Konečné zpracování jakékoli zprávy je vždy záležitostí místní politiky a ponechává se na усмотрении příjemce pošty." Táž část textu dodává obě strany důsledku — příjemci „MOHOU zvolit odmítnutí nebo karanténu zprávy, i když projde kontrolou DMARC," a „NEMĚLI BY odmítat zprávy pouze kvůli zveřejněné zásadě ‚reject'," aby se tak zabránilo zničení legitimních zpráv poslaných způsoby, které DMARC nemůže popsat, a poštovních list.

Co tedy vlastně p=none přiznává? Méně, než se jí obvykle vytýká. Podle vlastního vyjádření specifikace to je režim monitorování: vlastník domény shromažďuje souhrnné zprávy a „nevyjadřuje preferenci pro zpracování zpráv, které selžou při ověření DMARC," zatímco příjemce, který zavádí DMARC, „stále může" ověřit použití domény. Co to neudělá, je vypnutí čehokoliv na straně příjemce. Filtrování spamu vašeho poskytovatele, hodnocení reputace, kontrola adres URL a analýza příloh je samostatný stroj, který běží bez ohledu na to, co odesílatel zveřejnil. Padělená zpráva přicházející do domény p=none není vašim záznamem povýšena do schránky; je jednoduše předána příjemci bez vyslovené preference a příjemce se rozhoduje.

Druhá polovina nedorozumění působí opačně. DMARC nečte nebezpečnou část phishingového e-mailu. Jeho vlastní specifikace uvádí, co je záměrně vyloučeno z rozsahu, a „analýza obsahu" je na tomto seznamu, těmito slovy. Také uvádí, že DMARC „neřeší používání vizuálně podobných názvů domén nebo zneužití lidsky čitelného názvu RFC5322.From v poznámce" — dva triky, které nese většina falešných e-mailů na brand. A na hodnotu prokázané identity: „samotný průkaz DMARC nezaručuje, že doručení do schránky příjemce by bylo bezpečné nebo žádoucí." Řádně ověřená zpráva z jednorázové domény prochází DMARC čistě. DMARC odpovídá na otázku, kdo byl oprávněn používat doménu v hlavičce From:. Nic víc.

Tady se pravidla pro hromadné odesílatele z roku 2024 rutinně nesprávně interpretují, včetně první verze tohoto článku. Pokyny odesílatele od Google vyžadují od odesílatelů 5 000 nebo více zpráv za den na účty Gmail „Nastavit ověření e-mailu DMARC pro vaši doménu odesílání" a pak v jednom dechu říkají: „Vaša zásada vynucování DMARC může být nastavena na none." Vlastní Yahoo Sender Hub, který musí být čten zvlášť, nikoli předpokládán, že kopíruje Google, uvádí požadavek jako „Publikujte platnou DMARC zásadu s alespoň p=none - DMARC musí projít" a vůbec nezveřejňuje žádný číselný práh objemu. Obě sady požadavků nabyla účinnosti v únoru 2024. Žádná z nich nenutí nikoho opustit p=none. Co obě vlastně nutí, je ověření, které se shoduje: Google vyžaduje, aby „doména v hlavičce From: odesílatele odpovídala buď doméně SPF, nebo doméně DKIM," a Yahoo říká, že volnější soulad je přijatelný. Soulad, ne přísnost, je brána.

Což nechává skutečný důvod, proč domény zůstávají v monitoringu, a ten je spíše operační než zbabělý. Přechod na quarantine nebo reject znamená nejdříve najít všechny služby, které posílají poštu v jeho jménu — mzdy, ticketing, marketing, support desk, který někdo nedokumentoval — a ověřit každou tak, aby se shodovala. Samotný standard uznává nebezpečí, která tuto skutečnost zpomalují: třetí strany nejsou DMARC zavedeny ani vyloučeny, přeposílání a poštovní listy mohou prolomit soulad bez viny odesílatele a specifikace nasměrovává příjemce na RFC 7960 pro přesně ty režimy selhání. Organizace, která zveřejňuje p=none a čte své zprávy, provádí práci v pořadí, které specifikace popisuje. Ta, která zveřejňuje p=none a ignoruje zprávy, ne. Z vnějšku záznam sám nemůže říci, která z těchto dvou možností se právě díváte.

K pohledu nepotřebujete terminál. Bezplatné vyhledávací nástroje — dmarcian's domain checker, MXToolbox's DMARC check — načtou záznam a vytisknou vám zásadu. Zkuste to na vaší bance, poskytovateli mezd, letecké společnosti, kterou létáte. Jen si odpověď přečtěte jako: vyjádření záměru vlastníka domény, jeden vstup mezi mnoha do rozhodnutí, které váš poštovní poskytovatel činí sám, o jednom konkrétním druhu padělku. To je opravdu užitečná věc, kterou si můžete přečíst za deset sekund. Není to verdikt o tom, zda je další zpráva tvrdící, že je od té značky, bezpečná.

Oprava, 20. října 2026. Předchozí verze tohoto článku popsala p=none jako doručování padělků do schránky a p=reject jako jediné nastavení, které zablokuje padělanou zprávu, řekla, že pravidla hromadných odesílatelů od Google a Yahoo z roku 2024 nutila odesílatele pryč od p=none, a citovala údaj přibližně jedné ze tří domén na vynucování. Popisy zásad byly opraveny oproti RFC 9989; Google a Yahoo vlastně akceptují p=none, citováno výše z jejich vlastní dokumentace; a údaj o vynucování byl odstraněn, protože základní zpráva nezveřejňuje svůj vzorek nebo jmenovatel. Článek nyní také uvádí, co DMARC nekontroluje.