DMARCbis: co zmienia, a czego nie

DMARCbis, kolejna wersja specyfikacji DMARC (de facto DMARC 2.0), przeszła IETF Last Call i czeka w kolejce RFC Editor. Publikacja jako Proposed Standard spodziewana jest w 2026 roku i zastąpi obecną specyfikację RFC 7489. Jeśli utrzymujesz rekord DMARC, większość zmian przejdzie bez echa. Jedna nie.

DMARCbis usuwa tag pct, czyli jedyny wbudowany w protokół mechanizm stopniowego wdrażania. Nasze własne dane pokazują, że tag ten był rzadko używany poprawnie, a najczęściej nie był używany wcale. Jego usunięcie formalizuje lukę, którą protokół już miał, i zaostrza pytanie, na które DMARC nadal nie odpowiada: jak przejść z monitorowania do egzekwowania polityki bez blokowania legalnej poczty?

Na jakim etapie jest DMARCbis

Obecna wersja robocza to draft-ietf-dmarc-dmarcbis-41, zaktualizowana 13 stycznia 2026. IETF Last Call zakończył się na wersji 36 pod koniec 2024 roku. Dokument jest teraz w kolejce RFC Editor, czyli na ostatnim etapie administracyjnym przed nadaniem numeru RFC i publikacją jako Proposed Standard.

Trzy praktyczne punkty na start.

1. Istniejące rekordy DMARC nadal działają. Tag wersji pozostaje jako v=DMARC1. Odbiorcy wdrażający DMARCbis będą akceptować rekordy sformatowane zgodnie z RFC 7489.
2. Większość zmian jest cicha. Zmiany nazw tagów i zastąpienie Public Suffix List mechanizmem opartym na DNS dzieją się wewnątrz implementacji po stronie odbiorcy. Właściciele domen nie muszą nic robić, żeby ich rekordy pozostały ważne.
3. Jedna zmiana wpływa na przejście z monitorowania do egzekwowania: usunięcie pct. W połączeniu z przeprojektowaną semantyką trybu testowego zmienia to sposób, w jaki powinno działać stopniowe wdrażanie. To zmiana warta zrozumienia, nawet jeśli nie czytasz reszty specyfikacji.

Zmiany w skrócie

Najważniejsze różnice między RFC 7489 (obecny DMARC) a DMARCbis:

• Tagi usunięte: pct (procentowe stosowanie polityki), rf (format raportów forensic), ri (interwał raportów).
• Tagi dodane: psd (oznaczenie public suffix domain, dla PSO włączających się do DMARC), np (polityka dla nieistniejących subdomen), t (binarny tryb testowy).
• Domena organizacyjna: Public Suffix List (PSL) znika. Zastępuje ją DNS Tree Walk, który wykorzystuje rekordy DMARC na kolejnych domenach nadrzędnych do wyznaczenia granicy.
• Wytyczne dotyczące list mailingowych: specyfikacja wyraźnie odradza teraz p=reject dla domen z aktywnym ruchem list mailingowych, aby ograniczyć szkody uboczne dla subskrybentów.
• Dokumenty tracące ważność: RFC 7489 (DMARC) i RFC 9091 (PSD DMARC).

Dalsza część tego wpisu koncentruje się na zmianach, które faktycznie wpływają na to, jak zespół obsługuje DMARC w środowisku produkcyjnym.

Tag pct znika

Tag pct był próbą DMARC, by umożliwić operatorom stopniowe zwiększanie egzekwowania. Ustawienie pct=10 w rekordzie p=quarantine miało mówić odbiorcom: stosuj politykę kwarantanny wobec 10% wiadomości, które nie przechodzą weryfikacji, a pozostałe 90% przepuszczaj. Pomysł polegał na tym, by zespoły mogły zobaczyć, co by się złamało pod pełnym egzekwowaniem, nie łamiąc tego faktycznie.

W praktyce to nie zadziałało. Uzasadnienie IETF dla usunięcia tagu wskazuje, że odbiorcy stosowali wartości pct niespójnie, a zachowanie przy wartościach innych niż 0 lub 100 było w całym ekosystemie odbiorców nieprzewidywalne. Stopniowe wdrażanie przez pct było loterią: procent, który publikowałeś, i procent faktycznie stosowany wobec twojej poczty rzadko były tą samą liczbą.

DMARCbis zastępuje ten mechanizm tagiem t. t=y ustawia rekord w trybie testowym, co obniża efektywną politykę o jeden poziom: rekord p=reject z t=y jest traktowany jako p=quarantine. t=n (wartość domyślna) to pełne egzekwowanie. Nie ma procentu. Nie ma gradientu.

Powiedzmy to wprost: nowa specyfikacja nie zastępuje pct czymś, co rzeczywiście umożliwiłoby stopniowe wdrażanie. Usuwa wadliwy mechanizm i pozostawia problem stopniowego wdrażania operatorowi.

Od Public Suffix List do DNS Tree Walk

W RFC 7489, gdy odbiorca przetwarza pocztę z subdomeny takiej jak invoices.example.com, sięga do Public Suffix List, zewnętrznie utrzymywanego rejestru, aby ustalić, gdzie leży granica domeny organizacyjnej. Ta granica decyduje o tym, która polityka DMARC obowiązuje i jak oceniane jest wyrównanie (alignment).

DMARCbis zastępuje PSL mechanizmem DNS Tree Walk. Zamiast sięgać po zewnętrzną listę, odbiorca odpytuje bezpośrednio DNS: szuka rekordu DMARC dla domeny From, potem dla każdej domeny nadrzędnej, wspinając się w górę po jednej etykiecie na raz (invoices.example.com → example.com → com) i zatrzymując się na pierwszym poprawnym rekordzie DMARC. Nowy tag psd w tym rekordzie informuje odbiorcę, czy rekord należy do organizacji, czy do operatora public suffix, co kształtuje dalsze działanie odbiorcy.

Dla typowych domen z jednym rekordem organizacyjnym Tree Walk i PSL dają ten sam wynik. Zmienia się obsługa przypadków brzegowych. Trzy sytuacje warto sprawdzić u siebie:

• Publikujesz rekordy DMARC na subdomenach (typowe przy oddzielaniu poczty transakcyjnej od marketingowej lub izolowaniu zewnętrznych nadawców). W modelu Tree Walk rekord DMARC subdomeny zawsze wygrywa z polityką organizacji dla poczty z tej subdomeny. Jeśli któreś z tych rekordów subdomenowych zostały skonfigurowane lata temu i nikt ich nie rewidował, mogą po cichu nadpisywać twoją obecną politykę organizacyjną. Zaudytuj je.
• Operujesz public suffix (platforma hostingowa wydająca klientom domeny pod twoją strefą, rejestr ccTLD lub gTLD, BaaS lub CMS przydzielający subdomeny najemcom). Nowy tag psd=y został wpisany do DMARCbis właśnie dla takich przypadków. W RFC 7489 obsługiwano to osobnym RFC 9091; DMARCbis włącza to do głównej specyfikacji. Zastanów się, czy twoja strefa powinna publikować rekord psd=y.
• Masz nadawcę korzystającego z nietypowego TLD, ccTLD lub wieloelementowego public suffix (np. pod co.uk, github.io, s3.amazonaws.com). Wpis PSL dla takiego suffixa może, ale nie musi, idealnie odpowiadać zachowaniu Tree Walk. Sprawdź, czy twój rekord DMARC faktycznie rozwija się tak, jak oczekujesz, odpytując rekord na twojej domenie i na każdej kolejnej etykiecie nadrzędnej aż do public suffix.

Wszyscy pozostali: nic nie trzeba robić. Istniejący rekord DMARC działa pod Tree Walk tak samo, jak działał pod PSL.

Nowe wytyczne dotyczące list mailingowych

Zaktualizowana specyfikacja wyraźnie odradza publikowanie p=reject na domenach z aktywnym ruchem list mailingowych. Uzasadnienie to ten sam operacyjny ból, który operatorzy DMARC znają od lat: listy mailingowe modyfikują nagłówki w sposób łamiący wyrównanie DMARC, a polityka reject karze subskrybentów, którzy nie zrobili nic złego.

Jeśli twoja domena ma istotny udział w listach mailingowych (listy projektów open source, fora branżowe, newslettery stowarzyszeń), warto potraktować nowe wytyczne poważnie. Kompletny przewodnik po wdrożeniu DMARC omawia wzorce oparte na subdomenach i ARC, które większość zespołów stosuje, by pogodzić udział w listach z silną polityką organizacyjną.

Czego DMARCbis nie naprawia

Rewizja specyfikacji uznaje, że stopniowe wdrażanie nigdy nie działało. Nie naprawia stopniowego wdrażania. Usuwa je.

Dla organizacji przechodzących z monitorowania do egzekwowania formalizuje to strukturalną lukę, którą nasze własne dane pokazują od miesięcy. W migawce z I kwartału 2026 roku, obejmującej aktywnie monitorowane domeny na platformie DMARCeye:

• 39,9% domen z ważną polityką DMARC pozostaje na stałe w p=none, nie zapewniając żadnej ochrony przed spoofingiem, mimo że są na tyle zaangażowane, by uruchomić narzędzie monitorujące.
• Spośród domen, które egzekwują politykę, 93,8% stosuje ją do 100% ruchu bez żadnego stopniowego wdrażania. Tylko 6,2% używa pct<100.

Dwa skutki, jedna przyczyna. DMARC nie oferuje działającego środka pośredniego między monitorowaniem a egzekwowaniem. Mechanizm, który miał zasypać tę lukę (tag pct), był loterią, a po DMARCbis go nie ma. Nowa binarna flaga trybu testowego nie zastępuje tego, co miało robić stopniowe wdrażanie.

Przygotowanie bez paniki

Dla większości właścicieli domen DMARCbis nie jest alarmem. Istniejące rekordy działają bez zmian, a odbiorcy nie zmienią swojego zachowania w zakresie wyrównania z dnia na dzień. Kilka praktycznych uwag warto mieć na uwadze w miarę rozprzestrzeniania się adopcji.

• Jeśli obecnie używasz pct do stopniowego wdrażania: twoje rekordy pozostają składniowo poprawne, ale odbiorca zgodny z DMARCbis potraktuje pct<100 jak pct=100. Jeśli polegałeś na tym procencie, zaplanuj przejście już teraz. Najbliższy zamiennik w specyfikacji to t=y dla trybu testowego, ale obniża on politykę o jeden poziom zamiast stosować ją probabilistycznie.
• Jeśli masz złożoną strukturę subdomen: przejrzyj swoje rekordy DMARC w modelu Tree Walk. W praktyce wynik jest zwykle taki sam jak pod PSL, ale przypadki brzegowe istnieją.
• Jeśli obsługujesz aktywny ruch list mailingowych: nowe wytyczne przeciwko p=reject na takich domenach warto potraktować poważnie. Typowym wzorcem jest wydzielenie subdomeny.
• Jeśli jesteś w p=none i siedzisz tam od dłuższego czasu: DMARCbis nie zmienia twojej sytuacji. Problem strukturalny nie leży w specyfikacji. Leży w braku bezpiecznego przejścia, które DMARCbis formalizuje, ale nie rozwiązuje.

Nasz przewodnik po czytaniu raportów zbiorczych DMARC i Kompletny przewodnik po wdrożeniu DMARC pozostają aktualne pod DMARCbis bez zmian. Po wejściu nowej specyfikacji zmienia się to, co możesz ustawić w rekordzie, a nie to, jak czytasz, co wraca.

Czego właściwie wymaga to przejście

Nic pilnego. DMARC po DMARCbis dalej jest DMARC, a rekord, który publikujesz dzisiaj, będzie nadal akceptowany w dniu, w którym nowa specyfikacja dostanie pieczęć RFC. To, czego wymaga przejście, to zmiana postawy: potraktuj przejście z monitorowania do egzekwowania jako problem, którego protokół ci nie rozwiąże, i zaplanuj wszystko odpowiednio.

Narzędzia, które obserwują twoje raporty zbiorcze, oznaczają nieznanych nadawców jeszcze przed egzekwowaniem i mówią ci prostym językiem, co by się złamało pod bardziej restrykcyjną polityką, zyskują na wartości wraz z tym, jak protokół staje się surowszy. DMARCeye powstał dokładnie wokół tej roli, a nasze darmowe narzędzia online (konfigurator DMARC oraz testery SPF, DKIM i BIMI) pokrywają stronę konfiguracyjną w mniej niż dziesięć minut.

Wypróbuj DMARCeye za darmo już dziś i sprawdź, co tak naprawdę mówią raporty DMARC twojej domeny, zanim specyfikacja się zmieni.