DMARCbis: co se mění a co to znamená pro váš DMARC záznam

DMARCbis, další verze specifikace DMARC (v podstatě DMARC 2.0), prošel fází IETF Last Call a čeká ve frontě u RFC Editora. Vydání v podobě Proposed Standard se očekává v roce 2026 a nahradí stávající specifikaci RFC 7489. Pokud provozujete DMARC záznam, většina změn proběhne v tichosti. Jedna ne.

DMARCbis odstraňuje tag pct, který byl jediným mechanismem DMARC pro postupné zavádění přímo v protokolu. Naše interní data ukazují, že se tento tag používal jen zřídka správně a skoro vůbec. Jeho odstraněním se formálně uzavírá mezera, kterou protokol měl už dříve, a zároveň se vyostřuje otázka, na kterou DMARC stále neumí odpovědět: jak přejít z monitorování do vynucování, aniž byste rozbili legitimní poštu?

Kde DMARCbis momentálně stojí

Aktuální draft je draft-ietf-dmarc-dmarcbis-41, naposledy aktualizovaný 13. ledna 2026. Review v rámci IETF Last Call skončilo na verzi 36 koncem roku 2024. Dokument je nyní ve frontě u RFC Editora, což je poslední administrativní krok předtím, než Proposed Standard dostane přidělené číslo RFC a je publikován.

Tři praktické body na úvod.

1. Stávající DMARC záznamy fungují dál. Version tag zůstává v=DMARC1. Příjemci, kteří implementují DMARCbis, budou akceptovat záznamy formátované podle RFC 7489.
2. Většina změn proběhne v tichosti. Přejmenování tagů a nahrazení Public Suffix Listu mechanismem založeným na DNS se odehrává uvnitř implementací na straně příjemců. Vlastníci domén nemusí nic dělat, aby jejich záznamy zůstaly platné.
3. Jedna změna se týká přechodu z monitorování do vynucování: odstranění tagu pct. V kombinaci s přepracovanou sémantikou testovacího režimu to mění způsob, jakým má postupné zavádění fungovat. Právě této změně stojí za to porozumět, i kdybyste zbytek specifikace nečetli.

Změny na první pohled

Hlavní rozdíly mezi RFC 7489 (současný DMARC) a DMARCbis:

• Odstraněné tagy: pct (procentuální aplikace zásad), rf (formát forenzních reportů), ri (interval reportů).
• Přidané tagy: psd (příznak public suffix domény pro PSO zapojené do DMARC), np (zásada pro neexistující subdomény), t (binární testovací režim).
• Organizační doména: Public Suffix List (PSL) končí. Nahrazuje ho DNS Tree Walk, který využívá DMARC záznamy na postupně vyšších nadřazených doménách k určení hranice.
• Doporučení k mailing listům: specifikace nyní výslovně nedoporučuje p=reject pro domény s aktivním provozem na mailing listech, aby se omezily kolaterální dopady na odběratele.
• Stává se obsoletním: RFC 7489 (DMARC) a RFC 9091 (PSD DMARC).

Zbytek článku se soustředí na změny, které reálně ovlivní, jak tým provozuje DMARC v produkci.

Tag pct končí

Tag pct byl pokus DMARC umožnit operátorům postupně zvyšovat míru vynucování. Nastavení pct=10 na záznamu p=quarantine mělo příjemcům říkat: aplikuj karanténu na 10 % chybujících zpráv, zbylých 90 % propusť. Myšlenka byla taková, aby týmy zjistily, co by se při plném vynucování rozbilo, aniž by to reálně rozbily.

V praxi to nefungovalo. Samotné zdůvodnění IETF pro odstranění tagu uvádí, že příjemci aplikovali hodnoty pct nekonzistentně a že chování při hodnotách jiných než 0 nebo 100 bylo napříč ekosystémem příjemců nespolehlivé. Postupné zavádění přes pct byla loterie: procento, které jste publikovali, a procento, které se na vaši poštu skutečně aplikovalo, se málokdy shodovala.

DMARCbis mechanismus nahrazuje tagem t. t=y přepne záznam do testovacího režimu, který efektivní zásadu sníží o jeden stupeň: záznam p=reject s t=y se chová jako p=quarantine. t=n (výchozí hodnota) znamená plné vynucování. Žádné procento. Žádný plynulý přechod.

Řekněme to přímo: nová specifikace nenahrazuje pct něčím, na čem by postupné zavádění skutečně fungovalo. Odstraňuje nefunkční mechanismus a problém postupného zavádění ponechává na operátorovi.

Od Public Suffix Listu k DNS Tree Walk

Podle RFC 7489 příjemce při zpracování pošty ze subdomény jako invoices.example.com konzultuje Public Suffix List, externě udržovaný registr, aby zjistil, kde leží hranice organizační domény. Tato hranice určuje, která DMARC zásada se uplatní a jak se vyhodnocuje alignment.

DMARCbis nahrazuje PSL mechanismem DNS Tree Walk. Místo konzultace externího seznamu se příjemce dotazuje přímo DNS: hledá DMARC záznam na From doméně, potom na každé nadřazené doméně, postupně o jeden label výš (invoices.example.com → example.com → com), a zastaví se u prvního platného DMARC záznamu, který najde. Nový tag psd na tom záznamu příjemci řekne, jestli záznam patří organizaci, nebo provozovateli veřejného sufixu, což určuje, co příjemce udělá dál.

U typických domén s jediným organizačním záznamem dojde Tree Walk i PSL ke stejnému výsledku. Mění se hraniční případy. Tři situace stojí za to zkontrolovat u sebe:

• Publikujete DMARC záznamy na subdoménách (běžné při oddělení transakční pošty od marketingu nebo izolaci externích odesílatelů). Při Tree Walk má DMARC záznam subdomény vždy přednost před organizační zásadou pro poštu z této subdomény. Pokud byly některé z těchto subdoménových záznamů nastaveny před lety a od té doby je nikdo neřešil, mohou potichu přepisovat vaši aktuální organizační zásadu. Prověřte je.
• Provozujete public suffix (hostingová platforma, která vydává zákaznicky brandované domény ve vaší zóně, ccTLD nebo gTLD registr, BaaS nebo CMS přidělující subdomény nájemcům). Nový tag psd=y je do DMARCbis zabudován přesně pro tento případ. Podle RFC 7489 se to řešilo přes samostatné RFC 9091; DMARCbis to integruje do hlavní specifikace. Zvažte, jestli by vaše zóna měla publikovat záznam psd=y.
• Máte odesílatele využívajícího neobvyklý TLD, ccTLD nebo víceúrovňový public suffix (např. něco pod co.uk, github.io, s3.amazonaws.com). Záznam v PSL pro takový sufix nemusí odpovídat chování Tree Walk úplně přesně. Ověřte, že se váš DMARC záznam skutečně vyhodnocuje tak, jak očekáváte, tím, že si dohledáte záznam na své doméně a na každém nadřazeném labelu až po veřejný sufix.

Pro všechny ostatní: nic dělat nemusíte. Váš stávající DMARC záznam bude pod Tree Walk fungovat stejně jako dřív pod PSL.

Nové doporučení k mailing listům

Revidovaná specifikace doplňuje výslovné doporučení nepublikovat p=reject na doménách, které mají aktivní provoz na mailing listech. Důvod je stejné operační trápení, s nímž se provozovatelé DMARC potýkají už roky: mailing listy přepisují hlavičky způsobem, který narušuje DMARC alignment, a zásada reject trestá odběratele, kteří neudělali nic špatně.

Pokud má vaše doména podstatnou účast v mailing listech (seznamy open-source projektů, oborová fóra, newslettery asociací), nové doporučení stojí za to brát vážně. Kompletní průvodce implementací DMARC popisuje vzorce se subdoménami a ARC, které většina týmů používá, aby udržela účast v listech slučitelnou se silnou organizační zásadou.

Co DMARCbis neřeší

Revize specifikace uznává, že postupné zavádění nikdy nefungovalo. Neopravuje ho. Odstraňuje ho.

Pro organizace přecházející z monitorování do vynucování tím dostává formální podobu strukturální mezera, kterou naše vlastní data ukazují už měsíce. Napříč snapshotem z Q1 2026 aktivně monitorovaných domén na platformě DMARCeye:

• 39,9 % domén s platnou DMARC zásadou zůstává natrvalo na p=none, což nenabízí žádnou ochranu proti spoofingu, přestože jsou tyto domény dostatečně aktivní na to, aby provozovaly monitorovací nástroj.
• Z domén, které vynucují, 93,8 % aplikuje zásadu na 100 % provozu bez jakéhokoli postupného zavádění. Pouze 6,2 % používá pct<100.

Dva výsledky, jedna příčina. DMARC neposkytuje žádnou fungující střední cestu mezi monitorováním a vynucováním. Mechanismus, který měl tuto mezeru překlenout (tag pct), byl loterie, a po DMARCbis je pryč. Nový binární testovací příznak nenahrazuje to, co mělo postupné zavádění dělat.

Příprava bez paniky

Pro většinu vlastníků domén není DMARCbis důvod k poplachu. Stávající záznamy fungují beze změny a příjemci nebudou své chování při vyhodnocování alignmentu měnit ze dne na den. Několik praktických poznámek stojí za to mít v hlavě, jak se adopce bude šířit.

• Pokud aktuálně používáte pct pro postupné zavádění: vaše záznamy zůstávají syntakticky platné, ale příjemce odpovídající DMARCbis bude pct<100 efektivně zpracovávat jako pct=100. Pokud jste na procentech stavěli, naplánujte přechod teď. Nejbližší náhrada v rámci specifikace je t=y pro testovací režim, ten ale zásadu snižuje o jeden stupeň, místo aby ji aplikoval pravděpodobnostně.
• Pokud máte složitou strukturu subdomén: projděte si DMARC záznamy pohledem modelu Tree Walk. Praktický výsledek je obvykle stejný jako pod PSL, hraniční případy ale existují.
• Pokud provozujete aktivní provoz na mailing listech: nové doporučení proti p=reject pro tyto domény stojí za to brát vážně. Obvyklé řešení je vyčlenění samostatné subdomény.
• Pokud jste na p=none a jste tam už delší dobu: DMARCbis vaši pozici nemění. Strukturální problém není ve specifikaci. Je v absenci bezpečného přechodu, který DMARCbis formalizuje, ale neřeší.

Náš průvodce čtením DMARC agregovaných reportů i Kompletní průvodce implementací DMARC platí pod DMARCbis beze změny. Po přijetí specifikace se mění to, co můžete nastavit ve svém záznamu, ne jak čtete, co vám chodí zpátky.

Co po vás přechod vlastně chce

Nic naléhavého. DMARC je po DMARCbis pořád DMARC a záznam, který dnes publikujete, bude akceptován i v den, kdy nová specifikace dostane razítko RFC. Přechod po vás chce posun v přístupu: berte přechod z monitorování do vynucování jako problém, s jehož řešením vám protokol nepomůže, a podle toho plánujte.

Nástroje, které sledují vaše agregované reporty, označí neznámé odesílatele ještě před vynucováním a řeknou vám srozumitelně, co by se pod přísnější zásadou rozbilo, s rostoucí přísností protokolu nabývají na hodnotě. DMARCeye je postavený přesně na této roli a naše bezplatné online nástroje (DMARC konfigurátor, checkery SPF, DKIM a BIMI) pokryjí konfigurační stránku do deseti minut.

Vyzkoušejte DMARCeye zdarma ještě dnes a podívejte se, co vaše DMARC reporty pro vaši doménu skutečně říkají, než se specifikace posune.