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?
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.
v=DMARC1. Příjemci, kteří implementují DMARCbis, budou akceptovat záznamy formátované podle RFC 7489.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.Hlavní rozdíly mezi RFC 7489 (současný DMARC) a DMARCbis:
pct (procentuální aplikace zásad), rf (formát forenzních reportů), ri (interval reportů).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).p=reject pro domény s aktivním provozem na mailing listech, aby se omezily kolaterální dopady na odběratele.Zbytek článku se soustředí na změny, které reálně ovlivní, jak tým provozuje DMARC v produkci.
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.
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:
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.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.
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.
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:
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.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.
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.
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ě.p=reject pro tyto domény stojí za to brát vážně. Obvyklé řešení je vyčlenění samostatné subdomény.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.
Nevíte, jak máte pro svou doménu nastavený DMARC? Spusťte bezplatnou kontrolu níže:
Přečtěte si také: Vstup na palubu odesílatele třetí strany: 30denní plán DMARC
Přečtěte si také: 94 % firem přeskakuje vestavěný bezpečnostní mechanismus DMARC
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.