DMARCbis dodaje nową obronę przed podszywaniem się pod subdomeny

DMARCbis, pierwsza pełna aktualizacja standardu DMARC od 2015 r., jest już oficjalna. Została opublikowana 19 maja 2026 r. jako trzy nowe dokumenty RFC (9989, 9990 oraz 9991), zastępując RFC 7489 i przenosząc DMARC na ścieżkę standardów IETF. Większość zmian nie wymaga natychmiastowego działania, ale jest jeden dodatek, którym warto się zająć: nowy tag o nazwie np=, który zamyka lukę umożliwiającą podszywanie się pod subdomeny, pozostawioną otwartą przez stary standard.

DMARC to standard, który mówi serwerom odbierającym, co zrobić z pocztą, która nie przejdzie kontroli uwierzytelniania. Jeśli już używasz go w trybie p=quarantine lub p=reject, zatwierdzenie DMARCbis nie psuje niczego, co masz opublikowane. Cichsze zmiany, w tym usunięcie tagu pct oraz odejście od Public Suffix List, opisujemy w naszym przystępnym przewodniku po tym, co DMARCbis oznacza dla Ciebie. Ten artykuł dotyczy jednego dodatku, którym warto zająć się już dziś.

Kliknij linki, aby przejść do konkretnej sekcji.

• Co DMARCbis uczynił oficjalnym
• Gdzie tag sp= zawodzi
• Co robi tag np=?
• Co jeszcze zmieniło się wraz z zatwierdzeniem DMARCbis?
• Co powinieneś teraz zrobić?
• Podsumowanie

Co DMARCbis uczynił oficjalnym

DMARCbis to nie jeden dokument. Został opublikowany jako trzy osobne dokumenty RFC, z których każdy odpowiada za jedną część standardu:

• RFC 9989 definiuje rdzeń protokołu: jak publikuje się polityki, jak ocenia się wyrównanie (alignment) i jak odbiorca przetwarza rekord DMARC.
• RFC 9990 definiuje format raportów zbiorczych, czyli codzienne podsumowania XML, które otrzymuje Twoja domena.
• RFC 9991 definiuje raportowanie błędów (raporty forensyczne dla pojedynczych wiadomości).

Razem te dokumenty RFC zastępują RFC 7489 - specyfikację z 2015 r., która definiowała DMARC do tej pory. Podnoszą też status standardu, i ten punkt warto opisać precyzyjnie. RFC 7489 było sklasyfikowane jako Informational, co oznacza, że dokumentowało DMARC, ale nie niosło ze sobą poparcia IETF dla ścieżki standardów. DMARCbis jest opublikowany jako Proposed Standard, czyli nazwany poziom dojrzałości, który IETF przypisuje zatwierdzonemu dokumentowi na ścieżce standardów. Mimo słowa "Proposed" jest to gotowy, oficjalny standard, a nie projekt czy praca w toku, i jest to pierwszy szczebel ścieżki standardów, którego wiele powszechnie używanych protokołów internetowych nigdy nie przekracza. W praktyce sygnalizuje to dojrzałość, a nie nowy obowiązek. Daje standardowi mocniejszą pozycję w procesach zakupowych i zgodności, gdzie dokument o statusie Informational budził pytania, ale nadal nie wymaga, abyś dotykał rekordu, który już działa.

Gdzie tag sp= zawodzi

DMARC pozwala ustawić jedną politykę dla głównej domeny (tag p=) i osobną politykę dla subdomen (tag sp=). Problem w tym, że sp= obejmuje tylko subdomeny, które istnieją w Twoim DNS. Nie mówi nic o subdomenach, które nigdy nie zostały utworzone.

To jest luka, którą wykorzystują atakujący. Oszust może wysyłać pocztę z accounting.yourbrand.com lub payroll.yourbrand.com - adresów, których nigdy nie utworzyłeś i które nie mają żadnych rekordów DNS. Ponieważ taka subdomena zwraca odpowiedź, którą świat DNS nazywa NXDOMAIN (brak takiej nazwy), niektórzy odbiorcy historycznie traktowali brak rekordu jako brak polityki i przepuszczali wiadomość.

Większość domen pozostawia to odsłonięte. W raporcie branżowym DMARCeye za Q1 2026 nawet wśród domen z pełnym egzekwowaniem (p=reject) 65,15% nie deklaruje żadnej polityki dla subdomen. Przy p=none wskaźnik ten wynosi 86,67%. Domena może być zabezpieczona na najwyższym poziomie, a mimo to zostawiać atakującym otwarte drzwi o jeden poziom niżej.

Pełny rozkład polityk dla subdomen, wraz z resztą zbioru danych za Q1 2026, znajdziesz w raporcie:

Co robi tag np=?

Tag np= ustawia politykę DMARC konkretnie dla nieistniejących subdomen, czyli każdej subdomeny, która nie zwraca żadnych rekordów DNS. To brakująca połowa sp=.

Gdy np= jest opublikowany, odbiorca oceniający pocztę z wymyślonej subdomeny postępuje według jasnej kolejności. Najpierw sprawdza politykę np=. Jeśli nie jest ona ustawiona, cofa się do sp=. Jeśli i ta jest nieobecna, cofa się do głównej polityki p=. Nowy tag usuwa niejednoznaczność, która wcześniej pozwalała poczcie z fałszowanych subdomen przedostać się dalej.

Dla większości domen właściwą wartością jest np=reject. Subdomena, która nie istnieje, nie wysyła żadnej legalnej poczty, więc odrzucanie wszystkiego, co rzekomo z niej pochodzi, nic Cię nie kosztuje i zamyka drzwi przed całą klasą podszywania się. Rekord, który już brzmi v=DMARC1; p=reject;, staje się v=DMARC1; p=reject; np=reject; po dodaniu jednego elementu. Ta sama logika dotyczy istniejących subdomen poprzez sp=, a nasz przewodnik po tagu polityki dla subdomen sp= wyjaśnia, kiedy ustawić każdy z nich.

np= pomaga jednak dopiero wtedy, gdy odbiorca go uwzględnia. Jako zupełnie nowy tag, jego obsługa wciąż jest wprowadzana u dostawców skrzynek pocztowych, więc opublikowanie go teraz jest raczej polisą na przyszłość niż natychmiastowym rozwiązaniem.

Wpisz swoją domenę, aby zobaczyć rekord DMARC, który publikujesz dzisiaj, w tym ewentualny tag sp= lub np= już ustawiony:

Co jeszcze zmieniło się wraz z zatwierdzeniem DMARCbis?

Aktualizację uzupełniają dwie inne zmiany, choć żadna z nich nie wymaga dziś od Ciebie wiele.

Tag pct zniknął. Miał pozwalać stosować politykę do określonego procentu poczty naraz, ale odbiorcy implementowali go niespójnie. W zbiorze danych DMARCeye za Q1 2026 94,11% domen z p=quarantine i 93,51% domen z p=reject już go ignorowało i egzekwowało politykę z pełną siłą od pierwszego dnia. DMARCbis zastępuje go prostszą flagą t= (testing). Pełny opis tego, dlaczego stopniowe wdrażanie nigdy nie zadziałało, znajdziesz w naszym przewodniku po tym, co DMARCbis oznacza dla Ciebie.

DMARC przestał też opierać się na Public Suffix List, aby ustalić, gdzie leży granica domeny organizacji. Teraz przechodzi bezpośrednio przez DNS. Właściciele pojedynczych domen nie zauważą różnicy. Operatorzy dużych zbiorów subdomen powinni potwierdzić, że ich rekordy nadal rozwiązują się zgodnie z oczekiwaniami.

Co powinieneś teraz zrobić?

To, jak bardzo np= ma dla Ciebie znaczenie, zależy od tego, co prowadzisz.

Jeśli prowadzisz pojedynczą domenę lub małą firmę: dodanie np=reject to jednoliniowa zmiana bez żadnej wady, a zamyka ona drogę do podszywania się, która nie zależy od tego, czy pamiętasz każdą subdomenę, jaką kiedykolwiek utworzyłeś. Jeśli sam nie zarządzasz swoim DNS, to zadanie dla tego, kto to robi: zwykle Twojego rejestratora domeny (firmy, w której kupiłeś domenę, np. GoDaddy lub Namecheap), Twojego hostingu albo informatyka lub agencji, która konfigurowała Twoją pocztę. Wyślij im rekord, który chcesz opublikować, v=DMARC1; p=reject; np=reject;, i poproś, aby dodali go lub zaktualizowali na Twojej domenie.

Jeśli prowadzisz sklep e-commerce lub domeny marketingowe: fałszowane subdomeny to problem zaufania do marki w równym stopniu co problem bezpieczeństwa, bo przekonujący billing.yourbrand.com trafia do skrzynek klientów, wyglądając dokładnie jak Ty. Połącz np=reject z aktywnym monitoringiem, aby zobaczyć, które źródła wysyłają pod Twoją domeną, zanim cokolwiek zaostrzysz. Darmowy plan DMARCeye obejmuje jedną domenę z pełnym parsowaniem raportów, co wystarcza na start.

Jeśli jesteś agencją lub MSP: np=reject to szybki i łatwy do uzasadnienia sukces, który możesz wdrożyć na każdej zarządzanej domenie klienta. DMARCeye odseparowuje każde konto klienta osobno, więc Twój zespół może śledzić stan subdomen w całym portfolio z jednej konsoli, podczas gdy każdy klient widzi tylko własne dane.

Jeśli prowadzisz korporacyjną infrastrukturę pocztową: potraktuj np= jako element zarządzania subdomenami. Zinwentaryzuj, które jednostki biznesowe są właścicielami których subdomen, ustaw sp= dla tych, które legalnie wysyłają pocztę, i ustaw np=reject dla całej reszty, włączając tę zmianę do następnego przeglądu DMARC.

Podsumowanie

To, że DMARCbis staje się oficjalnym standardem, nie wymusza żadnej zmiany w rekordzie DMARC, który już działa. Formalizuje za to poprawkę luki, którą większość domen wciąż zostawia otwartą: sfałszowanej, nigdy nieutworzonej subdomeny. Tag np= to nowa dźwignia, a np=reject to bezpieczna wartość domyślna dla większości domen. Jedyny sposób, by wiedzieć, czy go potrzebujesz, to sprawdzić, co Twoja domena publikuje dzisiaj.

Właśnie do takiej widoczności jest stworzony DMARCeye. Odczytuje raporty DMARC, które otrzymuje Twoja domena, i pokazuje Ci prostym językiem, które źródła wysyłają pod Twoją nazwą i gdzie Twoja polityka zostawia Cię odsłoniętym.