Kontrola záznamu DMARC

Analýza a struktura záznamů DMARC

Záznam DMARC (Domain-based Message Authentication, Reporting, and Conformance) je textový DNS záznam typu TXT, který držitelům domén umožňuje definovat, jak mají přijímající poštovní servery nakládat s e-maily, které neprojdou ověřením SPF (Sender Policy Framework) nebo DKIM (DomainKeys Identified Mail). Nástroj Kontrola záznamu DMARC slouží k podrobné analýze těchto záznamů, kontrole jejich syntaxe, ověření nastavení zarovnání identifikátorů, kontrole adres pro zasílání hlášení a identifikaci historických či neplatných prvků.

Základním stavebním kamenem každého záznamu DMARC je deklarace verze. Záznam musí striktně začínat hodnotou v=DMARC1, přičemž u tohoto parametru záleží na velikosti písmen (case-sensitive). Pokud tato hodnota není na úplném začátku, je celý záznam neplatný. Nástroj při analýze načte vložený řetězec, spojí případné části DNS TXT v uvozovkách a provede syntaktický rozbor jednotlivých značek (tagů) oddělených středníky.

Vstupní parametry a limity analýzy

Pro provedení kontroly je vyžadován jeden hlavní vstupní údaj:

• Hodnota DMARC TXT: Textový řetězec, který představuje publikovaný nebo připravovaný záznam DMARC. Tento řetězec musí začínat definicí verze v=DMARC1. Nástroj podporuje i zápisy, kde jsou jednotlivé části DNS TXT uzavřeny v uvozovkách – tyto segmenty před samotnou analýzou automaticky spojí.
• Limit délky: Vložený text musí mít délku pod 20 000 znaků. V případě překročení tohoto limitu nástroj analýzu neprovede.

Zpracování zadaných dat probíhá lokálně. Váš záznam DMARC zůstává v prohlížeči. Nástroj jej nikam nenahrává ani neukládá, data se nezapisují do úložiště prohlížeče a mimo váš počítač se neodesílají žádné požadavky související s analyzovaným obsahem.

Výstupy kontroly a interpretace výsledků

Po spuštění analýzy se zobrazí podrobný přehled rozdělený do několika logických částí:

Souhrn DMARC

Tato sekce poskytuje rychlý přehled o klíčových parametrech politiky domény:

• p (Domain policy): Hlavní zásada uplatňovaná pro hlavní doménu.
• sp (Subdomain policy): Zásada definovaná pro subdomény.
• np (Non-existent subdomains): Zásada pro neexistující subdomény.
• DKIM / SPF: Nastavení striktnosti zarovnání identifikátorů pro mechanismy SPF a DKIM.
• rua / ruf: Počet detekovaných adres určených pro zasílání agregovaných a forenzních hlášení.
• pct (RFC 7489): Procentuální hodnota uplatnění politiky, která se v současnosti považuje za historickou.

rua / ruf

Zde jsou vypsány konkrétní cílové e-mailové adresy pro zasílání reportů:

• rua: Adresy určené pro příjem agregovaných reportů.
• ruf: Adresy určené pro příjem forenzních (výběrových) zpráv o selhání.

Analyzované výrazy

Tabulka obsahující kompletní seznam všech nalezených značek v záznamu. Každý řádek obsahuje:

• Výraz: Název značky (např. p, sp, rua, pct, adkim, aspf).
• Hodnota nebo kvalifikátor: Konkrétní nastavení přiřazené k dané značce.
• Druh: Klasifikace značky podle aktuálnosti standardu:
  • RFC 9989 (aktivní značky odpovídající aktuální specifikaci).
  • RFC 7489 (historické značky).
  • Neznámé (neznámé značky).
  • ✕ DMARC (neplatné značky).

Pravidla vyhodnocování a chování politik

Při interpretaci záznamu DMARC uplatňují přijímající poštovní servery specifická pravidla a mechanismy dědičnosti:

1. Výchozí politika: Pokud v záznamu zcela chybí značka p, politika domény se automaticky nastavuje na hodnotu none.
2. Dědičnost subdomén: Pokud pro subdomény není explicitně definována zásada pomocí značky sp nebo np, uplatňuje se mechanismus postupného návratu (fallback). Subdomény přebírají politiku v pořadí od nejkonkrétnější po obecnou: chybějící np se nahrazuje hodnotou sp, a pokud chybí i sp, použije se hlavní politika p.
3. Režim monitorování: Politika p=none slouží pouze ke sledování a vyžádání reportů. Přijímající servery v tomto režimu neprovádějí s nevyhovujícími e-maily žádné restriktivní akce (jako je karanténa nebo odmítnutí).
4. Testovací režim: Značka t=y slouží k testování. Během jejího aktivního uplatnění dochází ke snížení přísnosti politik: požadavek na reject se snižuje na quarantine a požadavek na quarantine se snižuje na none.
5. Zasílání hlášení: Pokud v záznamu není uvedena žádná platná e-mailová adresa u značky rua, agregované reporty se nebudou generovat a odesílat. Značka fo (možnosti hlášení o selhání) je přijímajícími servery zcela ignorována, pokud není definována platná adresa pro hlášení o selhání v parametru ruf.
6. Historické parametry: Značka pct (procentuální omezení platnosti politiky) je podle aktuálních standardů historická. Její vliv se omezuje pouze na starší poštovní servery, které se stále řídí dřívější specifikací RFC 7489. Současné systémy se řídí novější specifikací RFC 9989, ve které jsou parametry jako pct označeny za historické a mohou být ignorovány. Stejně tak přípona !size u adres pro zasílání reportů je zastaralá a moderní přijímače k ní nepřihlížejí.

Chybová hlášení a upozornění nástroje

Bhem syntaktické analýzy může nástroj vygenerovat následující chybová hlášení a upozornění na nedostatky v konfiguraci:

• Nejprve vložte záznam DMARC. (pokud je spuštěna kontrola s prázdným vstupem).
• Tento záznam je neobvykle velký. Udržujte jej pod 20 000 znaky. (při překročení limitu délky).
• Záznam musí začínat v=DMARC1. (pokud chybí správný úvodní identifikátor verze).
• Výraz ‹position›: v=DMARC1 musí být první výraz. (pokud je deklarace verze umístěna na jiné než první pozici).
• ×2: ‹tag› (‹position›) (při duplicitním výskytu stejné značky v záznamu).
• name=value ✕ (‹position›) (pokud je struktura značky poškozená a neodpovídá formátu klíč=hodnota oddělenému středníkem).
• ‹tag›=∅ (‹position›) (pokud značka nemá přiřazenou žádnou hodnotu).
• ‹tag›=‹detail› ✕ (‹position›) (v případě, že hodnota značky neodpovídá povoleným parametrům).
• URI ✕: ‹tag› (‹position›) (pokud adresa pro zasílání reportů nemá správný formát).
• Neznámé: ‹tag› (‹position›) (pokud záznam obsahuje značku, která není definována v žádném standardu DMARC).
• RFC 7489 → RFC 9989: ‹tag› (‹position›) (upozornění na použití značky, která je v aktuálním standardu RFC 9989 považována za historickou).
• p → none (upozornění, že chybí značka p a politika se proto nastavuje na výchozí none).
• p=none (upozornění, že politika none pouze monitoruje provoz a nežádá o karanténu ani odmítání zpráv).
• t=y: reject → quarantine; quarantine → none (upozornění na aktivní testovací režim snižující úroveň restrikcí).
• rua=∅ (upozornění, že chybí platná adresa rua a agregované reporty nebudou odesílány).
• fo → ∅ (ruf=∅) (upozornění, že nastavení fo bude ignorováno, protože chybí adresa ruf).
• pct=‹detail›% (RFC 7489) (upozornění na přítomnost historického parametru procentuálního omezení).
• Části DNS TXT v uvozovkách byly před analýzou spojeny. (informační zpráva o úpravě formátu vstupu).
• !size → ∅ (RFC 9989) (upozornění na přítomnost zastaralé specifikace velikosti u reportovací adresy, kterou moderní servery ignorují).

Často kladené otázky (FAQ)

Poznámky k syntaxi a zásadám: p / sp / np?

Pokud v záznamu chybí hlavní značka politiky p, uplatní se výchozí hodnota p=none. Pokud je aktivní testovací režim t=y, dochází ke snížení uplatňovaných politik (z reject na quarantine a z quarantine na none). Pro subdomény platí hierarchie dědičnosti: pokud chybí specifická politika pro neexistující subdomény np, použije se politika pro subdomény sp, a pokud chybí i ta, použije se hlavní politika domény p.

RFC 9989: pct / rf / ri?

Podle aktuálního standardu RFC 9989 jsou parametry jako pct (procentuální uplatnění), rf (formát hlášení o selhání) a ri (interval odesílání agregovaných zpráv) klasifikovány jako historické (RFC 7489). Moderní přijímací systémy je mohou ignorovat. Naopak parametry jako np (politika pro neexistující subdomény), psd (domény veřejného sektoru) a t (testovací režim) jsou podle RFC 9989 aktivní.

Dokazuje bezchybný výsledek, že moje nastavení DMARC funguje?

Ne. Tato stránka kontroluje pouze vložený text. Nedotazuje se DNS, nerozvíjí záznamy poskytovatelů, netestuje IP adresu odesílatele ani nepotvrzuje, co vrátí přijímající poštovní server. Pro kompletní ověření doručení pošty musíte provést reálné testy odesláním zpráv na cílové servery.