DMARC wg RFC 9989: co się zmieniło i co zrobić

W maju 2026 roku IETF opublikowała DMARC jako standard (Standards Track) w dokumencie RFC 9989. Zastępuje on RFC 7489 z 2015 roku, na którym opiera się większość wdrożeń DMARC, oraz RFC 9091 — eksperyment dotyczący domen sufiksów publicznych. Raporty opisano w dwóch osobnych dokumentach: RFC 9990 (raporty zbiorcze) i RFC 9991 (raporty o błędach).

W skrócie: Twój obecny rekord v=DMARC1 nadal działa. Tag wersji się nie zmienił, a serwery odbiorców działające według którejkolwiek z tych specyfikacji pomijają tagi, których nie znają. Przyjrzyj się rekordowi bliżej, jeśli używasz pct albo publikujesz DMARC tylko na subdomenach.

Zmiany w pigułce

Obszar	RFC 7489 (2015)	RFC 9989 (2026)
Status	Informational, publikacja niezależna	standard IETF (Standards Track)
Dokumenty	jeden	trzy: RFC 9989, 9990, 9991
Domena organizacyjna	na podstawie Public Suffix List	metodą DNS Tree Walk
Nowe tagi	—	np, psd, t
Usunięte tagi	—	pct, rf, ri
Limit rozmiaru po adresie raportów (!10m)	dozwolony	przestarzały, pomijany
Tag wersji	v=DMARC1	v=DMARC1

RFC 7489 nie powstał w ramach prac IETF: jako dokument informacyjny (Informational) wydał go redaktor publikacji niezależnych, Independent Submissions Editor (Dodatek C.1), a jego podstawą były prace branżowego konsorcjum DMARC.org, do którego należeli m.in. duzi dostawcy skrzynek. RFC 9989 to dokument IETF ze ścieżki standardów (Standards Track), przygotowany przez grupę roboczą IETF DMARC. Znacznie dokładniej opisuje też, co powinien zrobić właściciel domeny (sekcja 5.1): SPF i DKIM ze zgodnymi domenami, skrzynka na raporty, najpierw p=none, a dopiero potem decyzja o egzekwowaniu polityki.

DNS Tree Walk zamiast Public Suffix List

DMARC potrzebuje domeny organizacyjnej do dwóch rzeczy: do znalezienia polityki, gdy domena z nagłówka From nie ma własnego rekordu, oraz do oceny zgodności domen (alignment) w trybie swobodnym (relaxed). RFC 7489 wyznaczał ją na podstawie listy sufiksów publicznych (Public Suffix List), takich jak com czy co.uk, nie precyzując, której listy używać ani jak często ją odświeżać.

RFC 9989 korzysta zamiast tego z zapytań DNS (sekcja 4.10). Dla poczty z news.mail.example.com bez własnego rekordu serwer odbiorcy idzie w górę drzewa DNS:

_dmarc.news.mail.example.com   ; sama domena z From
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

Bardzo długie nazwy są najpierw skracane, więc przejście nigdy nie wymaga więcej niż ośmiu zapytań.

• Polityka: pierwszeństwo ma własny rekord domeny z From (polityka z p). W przeciwnym razie obowiązuje rekord jej domeny organizacyjnej, a gdy go brak — rekord domeny sufiksu publicznego: sp dla istniejących subdomen, np dla nieistniejących, a p, gdy tych tagów brak (sekcja 4.10.1).
• Zgodność domen: domeną organizacyjną jest ta domena na tej ścieżce, która publikuje rekord DMARC i ma najmniej etykiet, chyba że tag psd stanowi inaczej (sekcja 4.10.2). Przy rekordzie _dmarc.example.com zarówno mail.example.com, jak i bounce.example.com należą do example.com — tak samo jak według Public Suffix List.

W typowych konfiguracjach — jeden rekord w example.com, ewentualnie z osobnymi rekordami dla kilku subdomen — obie metody dają ten sam wynik. RFC zauważa, że ścisła zgodność domen (strict) i jawne rekordy dla każdej domeny używanej w From całkowicie eliminują różnice między starymi i nowymi serwerami (Dodatek C.3).

Nowe tagi: np, psd i t

np — nieistniejące subdomeny

np określa politykę dla subdomen, które nie istnieją w DNS (zapytanie zwraca NXDOMAIN), na przykład zmyślonej billing-team.example.com w wiadomości phishingowej. Za istniejącą uznaje się nazwę z jakimkolwiek rekordem DNS (Dodatek A.4). Bez np obowiązuje sp, a potem p.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com"

Serwery wciąż działające według RFC 7489 pomijają np i stosują sp lub p.

psd — domeny sufiksów publicznych

psd=y jest przeznaczony dla operatorów sufiksów publicznych, np. rejestrów domen najwyższego poziomu; RFC 9989 wymaga od nich tego tagu (sekcja 5.2). psd=n oznacza, że domena jest osobną domeną organizacyjną — przydaje się na przykład działowi, który sam zarządza swoją częścią przestrzeni nazw (sekcja 5.1.8). Wartość domyślna u znaczy „ustal to przez DNS Tree Walk”. Jeśli masz zwykłą domenę, nie dodawaj psd.

t — tryb testowy

t=y prosi serwery odbiorców o zastosowanie polityki o jeden poziom łagodniejszej: quarantine jest traktowane jak none, a reject jak quarantine. Ten, kto sprawdza DMARC — serwer odbiorcy albo pośrednik, np. lista dyskusyjna — może też zastosować własne specjalne reguły, takie jak przepisanie nagłówka From. Tag nie wpływa na raporty i nie ma znaczenia przy p=none. Usuń go albo ustaw domyślne t=n, gdy przyjdzie pora na egzekwowanie polityki.

Usunięte tagi: pct, rf i ri

IANA oznacza teraz te tagi jako historyczne (sekcja 9.3). RFC 9989 już ich nie definiuje, więc serwery zgodne z nową specyfikacją ich nie uwzględniają; serwery działające według RFC 7489 — owszem.

Tag	Do czego służył	Co zrobić teraz
pct	Stosował politykę do części (procentu) poczty, która nie przeszła DMARC	pct=0: użyj t=y. pct=100: usuń. Wartości pośrednie: patrz niżej
rf	Wybierał format raportów o błędach	Usuń; format określa RFC 9991
ri	Określał odstęp między raportami	Usuń; raporty zbiorcze powinny przychodzić co najmniej raz dziennie (sekcja 8)

Dlaczego zniknął pct

Według Dodatku A.6 pct rzadko był stosowany dokładnie, jeśli miał wartość inną niż 0 lub 100, a implementacje bardzo się różniły. Za to pct=0 okazał się przydatny: część pośredników i dostawców skrzynek traktowała go jako sygnał do przepisania nagłówka From, co pomagało właścicielom domen przygotować się do egzekwowania polityki. t=y zachowuje tę funkcję pod czytelniejszą nazwą i ma działać jak pct=0, a t=n odpowiada pct=100.

Skutek jest ten sam: według RFC 7489 poczta niewylosowana przez pct do reject trafiała do kwarantanny, a niewylosowana do quarantine była obsługiwana normalnie — czyli poziom niżej, tak jak przy t=y.

Jeśli używasz wartości od 1 do 99

Tu zmiana może zaboleć. Przy p=reject; pct=25 serwer zgodny z RFC 7489 odrzuca mniej więcej jedną czwartą poczty, która nie przeszła DMARC, a resztę kieruje do kwarantanny. Serwer zgodny z RFC 9989 pomija pct i odrzuca wszystko. Zdecyduj, czego naprawdę chcesz:

• Raporty są czyste: usuń pct i egzekwuj politykę w pełni.
• Na pełne egzekwowanie jest za wcześnie: dodaj t=y — zaktualizowane serwery będą wtedy kierować pocztę do kwarantanny zamiast ją odrzucać, a starsze nadal będą stosować pct. Możesz też wrócić do p=quarantine bez pct.

W okresie przejściowym możesz zostawić obok siebie pct=0 i t=y: oba rodzaje serwerów zastosują wtedy politykę o poziom łagodniejszą niż p.

Raporty w RFC 9990 i RFC 9991

Tagi rua i ruf działają jak dotąd; same raporty opisano w osobnych dokumentach:

• Raporty zbiorcze (RFC 9990) zachowują format XML; schemat doprecyzowano, każdy raport dotyczy jednej domeny polityki, a przy każdym zgłoszonym podpisie DKIM wymagany jest selektor (RFC 9990, Dodatek C).
• Raporty o błędach (RFC 9991) mogą zawierać nagłówki lub całą wiadomość. RFC 9989 zauważa, że większość serwerów odbiorców nie wysyła ich ze względu na prywatność (sekcja 10.2).
• Zewnętrzne adresy raportów nadal wymagają autoryzacji: rekordu TXT v=DMARC1 pod nazwą example.com._report._dmarc. z dopisaną domeną odbiorcy raportów (RFC 9990, sekcja 4).

Limit rozmiaru po adresie raportów, np. mailto:reports@example.com!10m, jest przestarzały i powinien być pomijany. Zamiast wymogu obsługi co najmniej dwóch adresów raportów RFC 9989 mówi, że raport powinien trafić na każdy podany adres (Dodatek C.7).

Ostrzejsze słowa o p=reject

Sekcja 7.4, oparta na RFC 7960, wprost opisuje, co p=reject robi z pocztą przekierowaną, aliasami i listami dyskusyjnymi:

• Domeny z p=reject nie mogą polegać wyłącznie na SPF i muszą podpisywać pocztę DKIM: przekierowanie psuje SPF, a podpis DKIM zwykle przetrwa.
• Domeny, których użytkownicy mogą pisać na listy dyskusyjne, nie powinny publikować p=reject. Jeśli jednak to robią, powinny najpierw przez co najmniej miesiąc stosować p=none, a potem równie długo p=quarantine i porównać wyniki.
• Serwery odbiorców nie mogą odrzucać poczty wyłącznie z powodu p=reject; bez innych przesłanek muszą traktować pocztę, która nie przeszła DMARC, tak, jakby polityka brzmiała quarantine.

RFC przyznaje, że w praktyce wiele serwerów i tak taką pocztę odrzuca, a oprogramowanie list dyskusyjnych obchodzi problem, przepisując adres w From. Dla domeny, z której idzie tylko poczta transakcyjna i marketingowa, p=reject pozostaje rozsądnym celem; jeśli pracownicy korzystają z list dyskusyjnych, rozważ wady i zalety.

Czy mój rekord wymaga zmian?

Twój rekord	Czy trzeba coś zmienić?
v=DMARC1; p=…; rua=… bez pct, rf i ri	Nie
Zawiera pct=100, rf=afrf lub ri=86400	Nie, ale możesz je usunąć
Zawiera pct=0	Dodaj t=y
Zawiera pct od 1 do 99	Tak: usuń go albo dodaj t=y
Rekordy DMARC tylko na subdomenach	Dodaj rekord w domenie głównej
Domeny w From mające ponad osiem etykiet	Opublikuj rekordy dokładnie pod tymi nazwami (sekcja 5.1.8)

Lista kontrolna migracji

1. Sprawdź swoją domenę i każdą subdomenę, z której wysyłasz, w narzędziu Sprawdzanie DMARC. Stosuje ono DNS Tree Walk według RFC 9989 i wskazuje usunięte tagi.
2. Upewnij się, że domena główna, np. example.com, ma rekord DMARC.
3. Zastąp pct=0 tagiem t=y (przez jakiś czas możesz mieć oba) i rozstrzygnij każdy pct od 1 do 99.
4. Usuń rf, ri i limity rozmiaru w rodzaju !10m.
5. Rozważ np=reject: nieistniejące subdomeny nie wysyłają prawdziwej poczty.
6. Przed przejściem na p=reject upewnij się, że każde prawdziwe źródło poczty przechodzi DKIM z domeną d= zgodną z adresem From — w narzędziu Sprawdzanie DKIM i na prawdziwej wiadomości w Analizatorze nagłówków e-mail.
7. Nie dodawaj psd, chyba że prowadzisz sufiks publiczny albo wydzieloną część przestrzeni nazw.
8. Nie przestawaj czytać raportów zbiorczych. Serwery przechodzą na RFC 9989 we własnym tempie, a tam, gdzie specyfikacje się różnią, raporty pokażą, co faktycznie zrobił każdy z nich.

Pełne wdrożenie od p=none do p=reject opisujemy w poradniku Jak poprawnie skonfigurować DMARC.