DMARCbis oficjalnym standardem: czym jest DMARC, co zmieniają dokumenty RFC 9989, 9990 i 9991 oraz jak się przygotować

TL;DR

• Publikacja DMARCbis: po latach pracy w grupie roboczej IETF specyfikacja DMARC została oficjalnie zaktualizowana. Trzy nowe dokumenty, RFC 9989, 9990 i 9991, zastępują informacyjny RFC 7489 z 2015 roku.
• Wsteczna kompatybilność: istniejące rekordy zaczynające się od v=DMARC1 pozostają w pełni ważne. Nie ma potrzeby masowej aktualizacji konfiguracji.
• Algorytm DNS Tree Walk: statyczna lista Public Suffix List (PSL) została zastąpiona dynamicznym algorytmem DNS Tree Walk, który precyzyjniej wyznacza domenę organizacyjną.

Czym jest DMARC i dlaczego ma znaczenie?

Przed przejściem do nowości wprowadzonych przez DMARCbis warto przypomnieć fundamentalną rolę, jaką ten protokół odgrywa w bezpieczeństwie poczty elektronicznej.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) łączy protokoły uwierzytelniania SPF i DKIM z domeną widoczną w nagłówku „From”. Dostarcza serwerom odbiorczym jasnych instrukcji dotyczących postępowania z wiadomościami, które nie przeszły weryfikacji. Jednocześnie generuje raporty, które pozwalają nadawcy zobaczyć, kto faktycznie wysyła wiadomości z jego domeny, w tym wszelkie nieautoryzowane próby podszywania się.

Właściciele domen mogą stosować jedną z trzech polityk:

• none: serwer odbiorczy nie podejmuje żadnej akcji wobec wiadomości z błędami, ale generuje i przesyła raporty do nadawcy.
• quarantine: wiadomości, które nie przeszły weryfikacji, trafiają do folderu ze spamem.
• reject: wiadomości z błędami są całkowicie blokowane przed dotarciem do skrzynki odbiorcy.

Na początku 2024 roku Google i Yahoo nałożyły na nadawców obowiązek wdrożenia DMARC, co ostatecznie przekształciło ten protokół z opcjonalnego dodatku w obowiązkowy standard branżowy.

Wskazówka dla marketerów: Nawet jeśli nie zarządzasz rekordami DNS bezpośrednio, zrozumienie tych trzech polityk daje ważny kontekst biznesowy. Pozwala ocenić, jak konfiguracja utrzymywana przez zespół techniczny wpływa na dostarczalność kampanii, i wiedzieć, o co zapytać, gdy coś idzie nie tak.

Od RFC 7489 do DMARCbis: dekada przygotowań

Oryginalna specyfikacja DMARC, opisana w dokumencie RFC 7489, została opublikowana w 2015 roku wyłącznie jako dokument “informacyjny”, a nie formalny standard internetowy. Oznaczało to, że choć protokół był powszechnie stosowany, jego implementacja pozostawała niejednolita, a dostawcy poczty mogli interpretować specyfikację na własny sposób.

Po latach prac w ramach grupy roboczej IETF (Internet Engineering Task Force) protokół przeszedł gruntowną rewizję. Prace trwały tak długo między innymi dlatego, że specyfikacja musiała rozwiązać trudne problemy, których RFC 7489 nie przewidywał, w szczególności kwestię przepływów pośrednich, obsługi domen publicznych oraz rosnącej złożoności ekosystemu poczty elektronicznej.

Nowa specyfikacja, znana jako DMARCbis, została podzielona na trzy dedykowane dokumenty:

• RFC 9989: główny dokument opisujący rdzenny mechanizm protokołu DMARC.
• RFC 9990: specyfikacja raportów zbiorczych (aggregate reports).
• RFC 9991: specyfikacja raportów o awariach (failure reports).

Todd Herr, jeden z redaktorów RFC 9989, potwierdził publikację na LinkedIn, podkreślając wagę tego kroku dla całego ekosystemu poczty elektronicznej. Pełna treść dokumentu jest dostępna w RFC Editor.

Dzięki tym publikacjom DMARC uzyskał oficjalny status IETF Proposed Standard. W praktyce oznacza to, że dostawcy poczty elektronicznej na całym świecie będą interpretować i wdrażać protokół w bardziej spójny sposób.

Status formalnego standardu przekłada się też na bardziej precyzyjne definicje, lepsze przykłady i wyraźniejsze wytyczne dla administratorów, co widać już w strukturze samych dokumentów, które są znacznie czytelniejsze niż RFC 7489.

Nie, to nie jest DMARC2. Co oznacza wsteczna kompatybilność?

Mimo kompleksowego charakteru najnowszej aktualizacji, DMARCbis nie wprowadza zmian zrywających wsteczną kompatybilność. Koncepcja “DMARC2” po prostu nie istnieje, a powód jest konkretny: nowe tagi i zmienione zasady działania zostały zaprojektowane tak, by serwery obsługujące stary standard mogły je po prostu zignorować, nie powodując błędów.

Wszystkie rekordy DMARC muszą nadal zaczynać się od ciągu v=DMARC1. To dobra wiadomość z operacyjnego punktu widzenia: istniejące i poprawnie skonfigurowane rekordy pozostają w pełni funkcjonalne, a administratorzy poczty nie muszą przeprowadzać natychmiastowych, masowych zmian w strefach DNS. Strategiczne aktualizacje rekordów warto planować dopiero wtedy, gdy główni dostawcy skrzynek pocztowych w pełni wdrożą i przetestują nową specyfikację na swoich serwerach.

Co faktycznie się zmieniło: kluczowe aktualizacje techniczne

DMARCbis wprowadza kilka istotnych zmian technicznych, które warto omówić osobno. Dotyczą one struktury rekordów polityki, sposobu ustalania domeny organizacyjnej oraz nowych wymagań dotyczących zgodności.

Zmiany w tagach: wersja skrócona

Struktura rekordów polityki DMARC została zaktualizowana. Część dotychczasowych tagów wycofano z powodu niskiego poziomu adopcji lub redundancji wobec innych mechanizmów. Równocześnie dodano nowe parametry odpowiadające aktualnym wymaganiom ekosystemu poczty elektronicznej.

Wycofany tag	Nowy tag	Funkcja techniczna
pct	t	Parametr procentowy został usunięty. Zastąpił go tag t (testing), który umożliwia testowanie polityki bez jej globalnego egzekwowania.
rf	brak	Parametr formatu raportowania został wycofany, ponieważ standardowe formaty XML są dziś powszechnie stosowane.
ri	brak	Parametr interwału raportowania został całkowicie usunięty.
brak	np	Pozwala zdefiniować politykę DMARC wyłącznie dla nieistniejących subdomen (non-existent subdomains).
brak	psd	Parametr służący do deklarowania domeny jako Public Suffix Domain.

Wskazówka dla marketerów: Jeśli Twój zespół techniczny używa w rekordzie tagu pct (np. pct=50 do stopniowego wdrożenia polityki), warto zaplanować migrację na nowy tag t. Funkcja jest podobna, ale nowa składnia jest prostsza i bardziej przewidywalna w działaniu.

Algorytm DNS Tree Walk zastępuje Public Suffix List

Do tej pory DMARC opierał się na liście Public Suffix List (PSL) do ustalania domeny organizacyjnej na potrzeby odkrywania rekordów i weryfikacji dopasowania identyfikatorów (alignment). Korzystanie z PSL generowało jednak istotne wyzwania operacyjne: lista wymagała ręcznych aktualizacji, powodowała opóźnienia w propagacji i często była źródłem błędów w złożonych strukturach domenowych.

RFC 9989 zastępuje PSL algorytmem DNS Tree Walk. Zamiast odpytywać statyczną bazę zewnętrzną, system dynamicznie analizuje hierarchię DNS, przeszukując jej poziomy krok po kroku, aż do precyzyjnego zidentyfikowania granicy organizacyjnej domeny. Ta zmiana zapewnia znacznie lepsze wsparcie dla środowisk Public Suffix Domains (PSD) i pozwala im na pełne uczestnictwo w ekosystemie DMARC.

Wymagania dotyczące zgodności (Conformance Requirements)

Zaktualizowana specyfikacja wprowadza nową sekcję poświęconą wymaganiom niezbędnym do pełnego uczestnictwa w środowisku DMARC. Określa ona precyzyjne kryteria techniczne zarówno dla właścicieli domen, jak i dla serwerów odbiorczych. Skodyfikowanie dawnych, nieformalnych najlepszych praktyk w formalne wymagania pozwoli na zachowanie większej spójności w globalnej infrastrukturze pocztowej.

Kontrowersje wokół polityki p=reject: co dokładnie mówi RFC 9989

Najbardziej odczuwalna zmiana wprowadzona przez DMARCbis dotyczy podejścia do polityki p=reject. Przepływy pośrednie, obejmujące systemy przekierowujące wiadomości oraz listy mailingowe, od lat łamią założenia dopasowania identyfikatorów DMARC. To ograniczenie techniczne pozostaje formalnie nierozwiązane również w najnowszej specyfikacji.

RFC 9989 odnosi się do tego problemu wprost, celowo zniechęcając do natychmiastowego odrzucania wiadomości przekazywanych drogą pośrednią. Specyfikacja formułuje wobec serwerów odbiorczych jednoznaczny nakaz:

“In the absence of other knowledge and analysis, Mail Receivers MUST treat such failing mail as if the policy were ‘p=quarantine’ rather than ‘p=reject’.” (RFC 9989, sekcja 7.4)

Użycie słowa MUST w terminologii RFC oznacza bezwzględne wymaganie, nie zalecenie. Serwery odbiorcze nie mogą więc odrzucać wiadomości wyłącznie na podstawie tagu p=reject, jeśli przyczyną niepowodzenia weryfikacji są problemy wynikające z przekierowań lub pośrednich przepływów wiadomości.

Praktyczne konsekwencje tego zapisu są istotne. Właściciele domen powinni wstrzymać się z restrykcyjnym wdrażaniem polityki p=reject, jeśli ich odbiorcy korzystają z list mailingowych lub mechanizmów przekierowań. Zamiast tego specyfikacja zaleca bieżące monitorowanie raportów pod kątem błędów dopasowania i eskalację polityki dopiero po ich wyeliminowaniu.

Wskazówka dla marketerów: Jeśli wysyłasz newslettery przez zewnętrzne platformy mailingowe lub Twoje wiadomości trafiają do odbiorców korzystających z list dyskusyjnych, polityka p=reject może powodować niezamierzone blokowanie legalnej korespondencji. Przed jej wdrożeniem warto skonsultować się z zespołem technicznym i przeanalizować raporty DMARC pod kątem przepływów pośrednich.

Aktualizacje raportowania: RFC 9990 oraz RFC 9991

• Raporty zbiorcze (RFC 9990): zasady generowania raportów zbiorczych zostały uszczegółowione, a wymagania wobec ich nadawców bardziej rygorystyczne. Zaktualizowano również strukturę formatu XML, uwzględniając nowe tagi rekordów oraz dostosowując specyfikację do praktyk faktycznie stosowanych przez dostawców poczty, które przez lata ewoluowały niezależnie od oryginalnego RFC 7489.
• Raporty o błędach (RFC 9991): mechanizm raportowania o awariach przeszedł jedynie drobne aktualizacje techniczne. Dodano jednak nową sekcję poświęconą implikacjom dotyczącym prywatności, wynikającym z przesyłania szczegółowych danych diagnostycznych o poszczególnych wiadomościach.

Wskazówka dla marketerów: Po wdrożeniu nowej specyfikacji przez dostawców poczty warto uważniej śledzić dane z raportów zbiorczych, zwracając szczególną uwagę na nieoczekiwane zmiany we wskaźnikach odrzuceń (bounce rate) oraz nagłe wahania w dopasowaniu identyfikatorów. Mogą one sygnalizować konieczność aktualizacji konfiguracji po stronie technicznej.

Jak przygotować się na DMARCbis: rekomendacje dla techników i marketerów 

DMARCbis nie wymaga natychmiastowego działania, ale stwarza dobrą okazję do porządków w konfiguracji i przemyślenia strategii uwierzytelniania. Poniżej znajdziesz konkretne kroki w zależności od tego, jaką rolę pełnisz w organizacji. 

Rekomendacje dla administratorów i zespołów technicznych

• Audyt istniejących rekordów: przejrzyj aktualną konfigurację DMARC, zwłaszcza pod kątem wycofanych tagów pct, rf i ri. Ich obecność nie powoduje błędów teraz, ale warto wiedzieć, które rekordy będą wymagały aktualizacji.
• Planowanie migracji tagów: zaplanuj przejście z pct na nowy tag t oraz usunięcie przestarzałych parametrów. Nie musisz robić tego od razu, ale warto mieć ten punkt na liście zadań.
• Systematyczne monitorowanie raportów: przed przejściem do polityki p=reject analizuj raporty zbiorcze pod kątem błędów dopasowania w przepływach pośrednich. Eskalacja polityki bez tej analizy to prosta droga do niezamierzonego blokowania legalnej korespondencji.
• Bez pośpiechu: wstrzymaj się z wprowadzaniem istotnych zmian w DNS do czasu, gdy wiodący dostawcy poczty potwierdzą pełne wdrożenie DMARCbis na swoich serwerach.

Rekomendacje dla marketerów i właścicieli domen

• Upewnij się, że masz włączone raporty zbiorcze: jeśli Twój rekord DMARC nie zawiera tagu rua, nie otrzymujesz żadnych danych o tym, jak Twoje wiadomości są uwierzytelniane u odbiorców. To podstawa do jakiejkolwiek dalszej analizy.
• Porozmawiaj z zespołem technicznym o polityce przed zmianą ESP: każda zmiana platformy wysyłkowej lub dodanie nowego narzędzia marketingowego może zaburzyć dopasowanie identyfikatorów. Lepiej zweryfikować konfigurację przed migracją niż naprawiać problemy z dostarczalnością po fakcie.
• Jeśli korzystasz z list mailingowych jako odbiorców: polityka p=reject może powodować blokowanie Twoich wiadomości u subskrybentów korzystających z takich list. W tym scenariuszu bezpieczniejszym wyborem jest p=quarantine połączone z bieżącym monitoringiem.

DMARCbis w szerszym ujęciu

Publikacja RFC 9989, 9990 i 9991 nie jest zdarzeniem odizolowanym. To kolejny etap konsekwentnego procesu, który branża emailowa realizuje od kilku lat, zmierzając w kierunku powszechnego i egzekwowalnego uwierzytelniania poczty elektronicznej.

Ekosystem zmienia się dynamicznie. Restrykcyjne wymagania dostawców poczty wobec nadawców wprowadzone przez Google i Yahoo na początku 2024 roku wymusiły masowe wdrożenia DMARC wśród nadawców, którzy do tej pory odkładali ten temat. DMARCbis formalizuje i ujednolica to, co stało się de facto standardem rynkowym.

Równolegle trwają prace nad DKIM2, który ma rozwiązać problem przepływów pośrednich u źródła, a nie jedynie łagodzić jego skutki. ARC, protokół zaprojektowany jako tymczasowe obejście tego samego problemu, ma zostać zastąpiony przez DKIM2 i jest już formalnie wycofywany z użycia.

Zestawione razem, te zmiany tworzą spójny kierunek: silniejsze, bardziej przewidywalne i trudniejsze do nadużycia uwierzytelnianie poczty na każdym etapie dostarczania wiadomości. Dla nadawców działających w dużej skali oznacza to jedno: warto śledzić te zmiany na bieżąco, bo kolejne kroki będą następować szybko.