Standardy DMARC RFC 9989, 9990 i 9991 zastępują RFC 7489

Po latach pracy w ramach grupy roboczej IETF ds. DMARC opublikowano długo oczekiwaną aktualizację standardu DMARC. Trzy nowe dokumenty – RFC 9989, RFC 9990 i RFC 9991 – oficjalnie zastępują pierwotny dokument RFC 7489 z 2015 roku. Chociaż nie jest to oficjalny termin, dokumenty te były w społeczności znane pod wspólną nazwą „DMARCbis” i zostały opublikowane jako zaktualizowana specyfikacja DMARC o tym samym numerze wersji.

Nowe specyfikacje opublikowano w maju 2026 roku, co spowodowało przeniesienie DMARC z dotychczasowego statusu „informacyjnego” do statusu „proponowanego standardu” w ramach ścieżki normalizacyjnej IETF. Jest to znaczący krok naprzód, ponieważ zapewnia DMARC silniejszą i bardziej formalną pozycję w systemie standardów internetowych.

Zakres poszczególnych dokumentów RFC

Specyfikacja DMARC została podzielona na trzy odrębne dokumenty zamiast jednego obszernego pliku. RFC 9989 zawiera podstawowy protokół, w tym ocenę zasad, reguły dostosowania oraz przetwarzanie rekordów. RFC 9990 określa format raportów zbiorczych (RUA). RFC 9991 dotyczy raportów o niepowodzeniach, często nazywanych raportami analitycznymi.

Twój obecny rekord DMARC nadal działa

Jedną z najważniejszych kwestii dla właścicieli domen jest to, że nie jest to zmiana powodująca niekompatybilność wsteczną. Identyfikator protokołu pozostaje bez zmian, więc rekordy nadal zaczynają się od v=DMARC1. Nie ma potrzeby, aby z dnia na dzień przebudowywać konfigurację ani ponownie publikować wszystkich rekordów.

Jeśli chcesz odświeżyć sobie wiedzę na temat struktury rekordów, w naszym przewodniku po tagach DMARC szczegółowo omówiono każde pole.

Najważniejsze zmiany techniczne

Warto zwrócić uwagę na kilka aktualizacji, a niektóre z nich warto dokładnie zrozumieć, zanim zaczniesz edytować swój wpis.

Lista sufiksów publicznych zastąpiona przez algorytm DNS Tree Walk

Odbiorcy nie polegają już na zewnętrznej liście sufiksów publicznych (Public Suffix List) w celu ustalenia domeny organizacyjnej. Zamiast tego przechodzą w górę hierarchii DNS i szukają rekordów _dmarc na każdym poziomie. W praktyce odbiorca zaczyna od danej domeny i wysyła zapytania do coraz wyższych etykiet, maksymalnie do ośmiu wyszukiwań, aż znajdzie opublikowany rekord DMARC. Eliminuje to zależność od podmiotów zewnętrznych i zwiększa dokładność w przypadku złożonych struktur domenowych.

Warto zwrócić uwagę na pewną praktyczną konsekwencję. Ponieważ algorytm Tree Walk interpretuje domenę organizacyjną inaczej niż stara metoda oparta na liście sufiksów publicznych (Public Suffix List), odbiorca korzystający z RFC 9989 może w niektórych przypadkach uzyskać inną domenę organizacyjną niż odbiorca nadal stosujący RFC 7489. Jeśli korzystasz ze złożonej hierarchii subdomen lub domen delegowanych, najbezpieczniejszym rozwiązaniem jest opublikowanie wyraźnego rekordu DMARC w każdej domenie i subdomenie, z której faktycznie wysyłasz wiadomości e-mail. Eliminuje to wszelkie niejasności dotyczące tego, która polityka ma zastosowanie, niezależnie od wersji używanej przez danego odbiorcę.

Nowe tagi: np, psd i t

W dokumencie RFC 9989 wprowadzono trzy nowe tagi. Poniżej opisano, do czego służy każdy z nich i w jakich sytuacjach warto z nich korzystać.

np (brak zasad dotyczących subdomen)

Tag „sp” już teraz pozwala ustawić zasady dla subdomen, ale „np” idzie o krok dalej, wyodrębniając zasady dla subdomen, które w ogóle nie istnieją – czyli takich, dla których DNS zwraca kod NXDOMAIN. Eliminuje to poważną lukę związaną z fałszowaniem subdomen, ponieważ atakujący często podszywają się pod wiadomości pochodzące z subdomen, które nigdy nie zostały zarejestrowane. Na przykład wpis v=DMARC1; p=none; np=reject; nie stosowałby żadnych zasad do domeny głównej i jej autentycznych subdomen, ale nadal odrzucałby wiadomości e-mail pochodzące z subdomen nieistniejących. Jeśli Twoja domena ma już ustawione p=reject lub sp=reject, surowa polityka jest automatycznie dziedziczona, więc np=reject nic nie wnosi i nie są potrzebne żadne zmiany. Jeśli stosujesz łagodniejszą politykę, ale chcesz uzyskać ukierunkowaną ochronę przed tym konkretnym atakiem, dodanie np=reject jest bardzo opłacalne.

t (tryb testowy)

Jest to tag, który najczęściej bywa błędnie interpretowany. Ustawienie t=y nie wyłącza Twojej polityki. Zamiast tego nakazuje odbiorcom zastosowanie polityki o jeden stopień mniej restrykcyjnej niż ta, którą opublikowałeś: polityka odrzucenia jest traktowana jak kwarantanna, polityka kwarantanny jak brak polityki, a brak polityki pozostaje bez zmian. Jest to znacznie bardziej precyzyjne niż stare zachowanie pct, które w praktyce zastępuje. Ważne zastrzeżenie: nie każdy odbiorca obsługuje jeszcze standard RFC 9989, więc niektórzy po prostu zignorują t=y. W okresie przejściowym bezpieczniejszym podejściem jest jednoczesne stosowanie zarówno pct, jak i t, aby zarówno starsze, jak i nowsze odbiorniki rozumiały Twoje intencje. Rekord etapowy może wyglądać następująco: v=DMARC1; p=reject; pct=50; t=y;. Więcej informacji na temat tej zmiany można znaleźć w naszej wcześniejszej notatce wyjaśniającej, dlaczego parametr t zastępuje pct.

psd (domena z publicznym rozszerzeniem)

Ten tag pomaga odbiorcom określić domenę organizacyjną podczas przeszukiwania drzewa DNS. Większość zwykłych właścicieli domen powinna po prostu go pominąć. Ma on znaczenie tylko w dwóch sytuacjach: gdy organizacja chce celowo wyznaczyć granicę domeny organizacyjnej na poziomie subdomeny (należy tam ustawić psd=n) lub gdy operator zarządza domeną z publicznym sufiksem, taką jak .bank lub .gov (należy ustawić psd=y). Należy pamiętać, że odbiorcy nadal korzystający ze standardu RFC 7489 całkowicie zignorują ten tag, więc nie zastępuje on prawidłowego projektowania rekordów.

Usunięto trzy tagi: pct, rf i ri

W dokumencie RFC 9989 wycofano trzy tagi. Żadne z tych usunięć nie spowoduje uszkodzenia istniejących rekordów, ale warto zrozumieć, do czego służył każdy z tych tagów i jak należy postąpić w tej sytuacji. Zobacz poświęconą temu zagadnieniu sekcję poniżej.

Bardziej przejrzyste wytyczne dotyczące list mailingowych i przekazywania wiadomości

Pośrednie przepływy poczty nadal powodują rozbieżności w zgodności z protokołami SPF i DKIM, co otwarcie potwierdza nowa specyfikacja. Odradza ona stosowanie agresywnych zasad typu „p=reject” w sytuacjach, gdzie często występuje ruch związany z listami mailingowymi, co odzwierciedla rzeczywiste zachowanie poczty elektronicznej w praktyce.

Bardziej precyzyjnie zdefiniowana zgodność

W nowym tekście wyjaśniono, co oznacza „pełne uczestnictwo w standardzie DMARC” zarówno dla nadawców, jak i odbiorców, co powinno ograniczyć niejednolite wdrożenia, które od lat stanowią problem.

Zniesiono ograniczenie rozmiaru identyfikatora URI w raportach

Niewielka zmiana, którą łatwo przeoczyć: w RFC 9989 usunięto możliwość określenia maksymalnego rozmiaru raportu w adresie URI raportu. Rekordy, w których stosowano sufiks rozmiaru, np. rua=mailto:[email protected]!10m, straciły znaczenie, a odbiorcy powinni teraz ignorować wszelkie ograniczenia rozmiaru dołączone do adresu rua lub ruf. Jeśli Twoje adresy URI raportów zawierają tę składnię, możesz bez obaw usunąć część dotyczącą ograniczenia rozmiaru.

Zrozumienie usuniętych tagów

Jeśli w Twoim obecnym zapisie użyto skrótów „pct”, „rf” lub „ri”, poniżej znajdziesz dokładne wyjaśnienie, co oznacza każdy z nich i co powinieneś teraz zrobić.

pct (procent)

Ten tag został zaprojektowany, aby umożliwić stopniowe wdrażanie polityki poprzez stosowanie jej do wybranego odsetka wiadomości. W praktyce był on wdrażany w sposób niejednolity przez różne odbiorniki, co prowadziło do nieprzewidywalnych rezultatów, dlatego został zastąpiony przez bardziej przejrzysty tag „t”. Jeśli nadal korzystasz z tagu „pct”, nie polegaj na nim wyłącznie w przyszłości. W okresie przejściowym rozsądnym rozwiązaniem jest jednoczesne stosowanie tagów „pct” i „t=y”, tak aby zarówno starsze odbiorniki, jak i odbiorniki zgodne z RFC 9989 zrozumiały, że stopniowo przechodzisz do pełnego wdrożenia tej polityki.

rf (format raportu)

Ten tag określał format raportów o błędach, ale jedyną prawidłową wartością było „afrf”, co w praktyce sprawiało, że tag ten był zbędny. Można go bezpiecznie usunąć ze wszystkich rekordów, w których się pojawia.

ri (interwał raportowania)

Ten tag określał żądany odstęp czasu między raportami zbiorczymi, wyrażony w sekundach. Większość odbiorców ignorowała go i po prostu domyślnie generowała raporty dzienne, a norma RFC 9989 formalizuje to obecnie, wymagając od odbiorców wysyłania raportów zbiorczych co najmniej raz dziennie. Pozostawienie tego tagu nie powoduje żadnych szkód, ale staje się on coraz mniej istotny i nie należy na nim polegać.

Jak zaktualizować rekord DMARC zgodnie z RFC 9989?

Opublikowanie dokumentu RFC 9989 nie powoduje żadnych zakłóceń w dotychczasowym działaniu. Twój rekord nadal znajduje się w tym samym miejscu – jest to rekord DNS typu TXT pod adresem _dmarc.twojadomena.com, a znacznik wersji nadal ma wartość v=DMARC1.

Po co więc w ogóle wprowadzać aktualizację? Ponieważ RFC 9989 odzwierciedla rzeczywiste działanie poczty elektronicznej po dziesięciu latach praktycznego wdrażania, a niektóre z zawartych w nim zmian warto uwzględnić w swoich zapisach już teraz, zamiast odkrywać je dopiero później.

Oto, co powinni zrobić właściciele domen

Właściciele domen mogą skorzystać z poniższej listy kontrolnej, aby dynamicznie aktualizować swoje wpisy:

Usuń tagi „rf” i „ri”. Oba są przestarzałe i można je bezpiecznie usunąć.
Replace pct with t: use t=y for testing (in place of any pct<100), or drop the tag for full enforcement (t=n is the default)
Jeśli chcesz zablokować fałszywe żądania pochodzące z nieistniejących subdomen bez zmiany głównej polityki, rozważ dodanie opcji „np=reject”.
Usuń sufiks określający limit rozmiaru URI raportu, jeśli Twoje rekordy typu rua lub ruf zawierają taki sufiks.
Nie należy uwzględniać pliku PSD, chyba że celowo trzeba zadeklarować granicę domeny organizacyjnej lub zarządzasz domeną z sufiksem publicznym.
Opublikuj wyraźne rekordy DMARC dla każdej domeny i subdomeny, z której wysyłasz wiadomości e-mail, aby uniknąć niejasności związanych z przeszukiwaniem drzewa DNS między odbiorcami zgodnymi z RFC 9989 i RFC 7489.

Aby uzyskać bardziej szczegółowe informacje na temat zmian oraz sposobu przygotowania dokumentacji, zapoznaj się z naszym kompletnym przewodnikiem wyjaśniającym system DMARCbis.

Zmodernizowany wpis zgodny z RFC 9989 wygląda następująco:

v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=s; aspf=s

Zwróć uwagę na to, czego tu brakuje: nie ma wartości „pct”. Aby wprowadzić to rozwiązanie w sposób bezpieczny, dodaj t=y, poczekaj, aż zgromadzą się raporty zbiorcze, a następnie usuń tę wartość, gdy będziesz gotowy do pełnego wdrożenia.

Zauważysz również, że w tym wpisie brakuje dwóch prawidłowych tagów zgodnych z RFC 9989 – „t” i „psd” – i jest to zamierzone, ponieważ oba mają charakter sytuacyjny, a nie standardowy.

Tag „t” oznacza tymczasowy tryb testowy: dodaje się go tylko na etapie stopniowego wprowadzania nowych zasad, ponieważ nakazuje on odbiorcom stosowanie zasad o o jeden poziom niższym niż opublikowane. Z kolei tag „psd” to flaga, która deklaruje domenę jako sufiks publiczny. Operatorzy sufiksów publicznych muszą ustawić wartość „psd=y”, ale dla zwykłego właściciela domeny wartość domyślna (u) jest całkowicie odpowiednia i należy po prostu pominąć ten tag.

Upewnij się, że Twoja platforma DMARC jest gotowa

Nie każde narzędzie dostępne na rynku dostosowało się jeszcze do nowych standardów, a ta luka ma znaczenie. Jeśli Twoja platforma nie potrafi odczytać nowych tagów ani przetwarzać raportów w zaktualizowanym formacie, tracisz wgląd w dane właśnie w momencie, gdy protokół ulega zmianom.

PowerDMARC jest już dostosowany do nowych specyfikacji i obsługuje:

Tworzenie rekordów zgodnych z RFC 9989, 9990 i 9991
Analiza nowych tagów np, psd i t
RFC 9990 – gromadzenie danych zbiorczych i raportowanie
Obsługa domen organizacyjnych w oparciu o przeglądanie drzewa DNS
Zaktualizowane zachowanie podczas przetwarzania, odzwierciedlające nowe zasady zgodności

Jeśli chcesz sprawdzić, jak Twoje obecne dane wypadają w porównaniu z nowym standardem, skorzystaj z naszego bezpłatnego narzędzia do sprawdzania zgodności z DMARC i zobacz, co należy poprawić.

Słowa końcowe

Zaktualizowane dokumenty RFC nie stanowią nowego protokołu. Jest to ten sam protokół DMARC, napisany w bardziej przejrzysty sposób i nadający mu status standardu. Po ponad dziesięciu latach praktycznego stosowania specyfikacja ta odzwierciedla obecnie rzeczywisty sposób działania poczty elektronicznej, w tym jej bardziej skomplikowane aspekty, takie jak przekazywanie wiadomości i listy mailingowe.

Dla wszystkich osób odpowiedzialnych za bezpieczeństwo domen opublikowanie dokumentów RFC 9989, 9990 i 9991 stanowi dobry pretekst do przeprowadzenia audytu rekordów oraz upewnienia się, że posiadane narzędzia są gotowe na obsługę nowych tagów i podejścia opartego na przeglądaniu drzewa DNS.

O
Latest Posts

Ahona Rudra

Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC

Ahona jest Marketing Managerem w PowerDMARC, z ponad 5-letnim doświadczeniem w pisaniu na tematy związane z cyberbezpieczeństwem, specjalizującym się w bezpieczeństwie domen i poczty elektronicznej. Ahona posiada dyplom ukończenia studiów podyplomowych w zakresie dziennikarstwa i komunikacji, umacniając swoją karierę w sektorze bezpieczeństwa od 2019 roku.

Latest posts by Ahona Rudra (zobacz wszystkie)