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?
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.
v=DMARC1. Odbiorcy wdrażający DMARCbis będą akceptować rekordy sformatowane zgodnie z RFC 7489.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.Najważniejsze różnice między RFC 7489 (obecny DMARC) a DMARCbis:
pct (procentowe stosowanie polityki), rf (format raportów forensic), ri (interwał raportów).psd (oznaczenie public suffix domain, dla PSO włączających się do DMARC), np (polityka dla nieistniejących subdomen), t (binarny tryb testowy).p=reject dla domen z aktywnym ruchem list mailingowych, aby ograniczyć szkody uboczne dla subskrybentów.Dalsza część tego wpisu koncentruje się na zmianach, które faktycznie wpływają na to, jak zespół obsługuje DMARC w środowisku produkcyjnym.
pct znikaTag 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.
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:
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.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.
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ą.
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:
p=none, nie zapewniając żadnej ochrony przed spoofingiem, mimo że są na tyle zaangażowane, by uruchomić narzędzie monitorujące.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.
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.
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.p=reject na takich domenach warto potraktować poważnie. Typowym wzorcem jest wydzielenie subdomeny.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.
Nie wiesz, jak skonfigurowany jest DMARC dla Twojej domeny? Uruchom bezpłatne sprawdzenie poniżej:
Przeczytaj także: Wdrażanie nadawców zewnętrznych: 30-dniowy plan DMARC
Przeczytaj także: 94% firm pomija wbudowany mechanizm bezpieczeństwa DMARC
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.