Znacznik pct w DMARC informuje serwery odbierające pocztę, do jakiego procentu Twoich niepoprawnych wiadomości należy zastosować opublikowaną politykę. Pozwala to włączać egzekwowanie stopniowo, zamiast od razu obejmować nim 100% ruchu. Pułapka, którą niemal każdy poradnik błędnie interpretuje, dotyczy tego, co dzieje się z pocztą, która nie została wybrana. Odbiorcy nie rezygnują wtedy z egzekwowania. Stosują następną, niższą politykę. Dlatego p=reject; pct=50 nie odrzuca połowy niepoprawnej poczty, przepuszczając resztę bez zmian. Odrzuca połowę, a drugą połowę poddaje kwarantannie.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
To zachowanie polegające na obniżeniu poziomu polityki jest najważniejszą rzeczą, którą musisz zrozumieć, zanim sięgniesz po pct, ponieważ zmienia ono sposób planowania wdrożenia i interpretowania jego skutków. Poniżej znajdziesz opis tego, co robi ten znacznik, dokładny harmonogram wdrażania, który utrzymuje przepływ legalnej poczty, oraz wyjaśnienie, dlaczego pct warto traktować jako narzędzie tymczasowe, a nie trwały element rekordu.
Co naprawdę robi znacznik pct
pct jest zdefiniowany w RFC 7489 jako liczba całkowita od 0 do 100, która ustala procent wiadomości z Twojej domeny, jaki odbiorca powinien objąć polityką DMARC. Jeśli go pominiesz, wartością domyślną jest 100, co oznacza, że polityka obejmuje wszystko, co nie przejdzie weryfikacji. Ustaw pct=25, a odbiorca zastosuje politykę do mniej więcej jednej na cztery niepoprawne wiadomości, wybieranych losowo dla każdej wiadomości.
Kompletny rekord z tym znacznikiem wygląda tak:
v=DMARC1; p=reject; pct=25; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1
Dwie rzeczy warto powiedzieć wprost. Po pierwsze, pct wpływa wyłącznie na wiadomości, które już nie przechodzą weryfikacji DMARC. Poczta, która przechodzi SPF lub DKIM z zachowaniem zgodności (alignment), nigdy nie jest tu ruszana, niezależnie od tego, co ustawisz. Po drugie, pct nigdy nie zmienia raportowania. Raporty zbiorcze (rua) nadal obejmują 100% Twojej poczty, więc zachowujesz pełny wgląd w każde źródło, nawet gdy egzekwujesz politykę tylko na wycinku. To właśnie sprawia, że etapowe wdrożenie jest bezpieczne: widzisz wszystko, a działasz na części.
Jeśli wciąż zastanawiasz się nad samymi poziomami polityki, najpierw przeczytaj Polityka DMARC: none, quarantine czy reject, a potem wróć do tempa egzekwowania.
Reguła obniżenia poziomu, która wszystkich zaskakuje
Oto zdanie z RFC 7489, które większość wpisów blogowych pomija. Gdy wiadomość nie zostanie wybrana przez próbkowanie pct, odbiorca stosuje politykę o jeden poziom niższą od opublikowanej. Reject zamienia się w quarantine. Quarantine zamienia się w none.
Przeanalizujmy dwa realne przypadki:
p=reject; pct=50oznacza, że 50% niepoprawnej poczty jest odrzucane, a pozostałe 50% trafia do kwarantanny. Żadna z tych wiadomości nie jest dostarczana normalnie do skrzynki odbiorczej.p=quarantine; pct=50oznacza, że 50% niepoprawnej poczty trafia do kwarantanny, a wobec pozostałych 50% nie jest podejmowane żadne działanie, więc ląduje ona w skrzynce odbiorczej.
Ma to ogromne znaczenie dla planowania. Ludzie zakładają, że pct=10 przy polityce reject oznacza "zablokuj 10%, dostarcz 90% jak dotychczas". Tak nie jest. Oznacza to "odrzuć 10%, a 90% poddaj kwarantannie". Jeśli którykolwiek z Twoich legalnych nadawców nie przechodzi kontroli zgodności, te 90% trafi do folderu ze spamem, a nie do skrzynki odbiorczej. Dlatego niskie pct przy p=reject nadal jest agresywne. Najbezpieczniejszy sposób wprowadzenia twardego egzekwowania to najpierw czyste dojście do p=quarantine; pct=100, potwierdzenie, że raporty są czyste, i dopiero potem przejście do reject.
Harmonogram wdrażania egzekwowania tydzień po tygodniu
Zakładając, że siedziałeś już na p=none wystarczająco długo, by zidentyfikować i naprawić swoich legalnych nadawców, oto harmonogram, który doprowadzi Cię do pełnego egzekwowania w ciągu mniej więcej czterech do sześciu tygodni. Każdy krok jest uzależniony od analizy raportów, a nie wyłącznie od kalendarza. Jeśli jakiś krok ujawni uszkodzone źródło, zatrzymujesz się, naprawiasz je i czekasz, zanim ruszysz dalej.
Tygodnie 1 do 2: kwarantanna przy niskim procencie
Opublikuj p=quarantine; pct=10. Teraz 10% niepoprawnej poczty trafia do kwarantanny, a 90% pozostaje nietknięte, więc zasięg oddziaływania jest niewielki. Przeanalizuj pełny tydzień raportów zbiorczych. Szukasz dowolnego źródła, które nie przechodzi ani zgodności SPF, ani zgodności DKIM, ale wyraźnie należy do Ciebie: platformy do fakturowania, narzędzia help-desk, systemu marketingowego, o którym zapomniałeś.
Tydzień 2 do 3: podnieś do 25, potem do 50
Jeśli raporty są czyste, przejdź na pct=25, odczekaj kilka dni, a następnie na pct=50. Przy 50% poddajesz kwarantannie połowę całej niepoprawnej poczty, co daje wolumen wystarczający, by każde pozostałe uszkodzone źródło głośno ujawniło się w skargach lub w danych raportowych. To punkt kontrolny, w którym często pojawiają się błędy związane z przekierowaniami, ponieważ przekierowana wiadomość może zepsuć SPF. Jeśli je zauważysz, zrozum przyczynę, czytając dlaczego przekierowywanie poczty psuje SPF, zanim uznasz, że nadawca jest źle skonfigurowany.
Tydzień 3 do 4: kwarantanna przy 100
Ustaw p=quarantine; pct=100 i utrzymaj to przez co najmniej tydzień. Każda niepoprawna wiadomość trafia teraz do kwarantanny. Jeśli Twoja legalna poczta uwierzytelnia się poprawnie, dostarczalność nie ucierpi, ponieważ poczta przechodząca weryfikację nigdy nie podlega polityce. Czysty tydzień na tym etapie to Twoje zielone światło dla reject.
Tydzień 4 i dalej: reject przy 100
Przejdź od razu na p=reject; pct=100. Nie zawracaj sobie głowy niskim pct przy reject, ponieważ, jak pokazano wyżej, obniża on jedynie resztę do kwarantanny, którą i tak działałeś już przy 100% przez tydzień. Niewiele na tym zyskasz, a semantyka wprowadza operatorów w zakłopotanie. Skok do pełnego reject po czystym tygodniu kwarantanny to standardowe, bezpieczne zakończenie. Pełny scenariusz przejścia między politykami znajdziesz w jak przejść z DMARC none do reject.
Jak analizować raporty przed każdym krokiem
Wdrożenie jest tak bezpieczne, jak dokładna jest Twoja analiza raportów. Każdy raport zbiorczy to plik XML od odbiorcy, podsumowujący, jak Twoja poczta uwierzytelniała się w ciągu doby. Zanim przejdziesz do kolejnego kroku, potwierdź trzy rzeczy: każdy nadający IP o dużym wolumenie odsyła do źródła, które rozpoznajesz, każde z tych źródeł przechodzi zgodność SPF lub zgodność DKIM (najlepiej obie), a liczba niepoprawnej, lecz legalnej poczty zmierza do zera.
Jeśli źródło, które należy do Ciebie, nie przechodzi weryfikacji, napraw leżące u podstaw uwierzytelnianie, zamiast obniżać pct, by je ukryć. Zmniejszenie procentu nie naprawia uszkodzonego nadawcy, jedynie odsuwa dzień, w którym się to wysypie. Nasz przewodnik jak czytać zbiorczy raport DMARC omawia dokładnie, które pola XML sprawdzić i jak powiązać dany IP z konkretną usługą.
Główny powód, dla którego warto uzależnić postęp od raportów, jest taki, że pct chroni Cię przed Twoimi własnymi lukami w wiedzy, a nie przed atakującymi. Atakujący podszywający się pod Twoją domenę i tak nie przejdą DMARC. Procent istnieje po to, aby wtedy, gdy jeden z Twoich własnych nadawców jest źle skonfigurowany w sposób, którego raporty jeszcze nie ujawniły, wpłynęło to jedynie na ułamek tej poczty, dając Ci czas na wychwycenie problemu.
DMARCbis wycofuje pct: zabezpiecz swój rekord na przyszłość
DMARCbis, zaktualizowana specyfikacja DMARC opublikowana w 2026 roku jako RFC 9989, usuwa znacznik pct. Zastępuje go pojedynczy znacznik t (tryb testowy), w którym t=y sygnalizuje postawę testową zamiast probabilistycznego procentu. Grupa robocza porzuciła pct, ponieważ opisane wyżej zachowanie obniżające poziom polityki było powszechnie źle rozumiane i niespójnie wdrażane przez różnych odbiorców, a także dlatego, że wartości inne niż 0 i 100 rzadko dawały przewidywalne wyniki na dużą skalę.
W praktyce oznacza to dwie rzeczy. Używaj pct dziś, jeśli potrzebujesz stopniowego wdrożenia, ponieważ obecni odbiorcy nadal go respektują. Nie buduj jednak wokół niego długoterminowych procesów. Traktuj go jak rusztowanie, które usuwasz, gdy tylko osiągniesz p=reject; pct=100. Gotowy rekord nie powinien zawierać żadnego znacznika pct, co odpowiada zarówno domyślnej wartości 100 z RFC 7489, jak i kierunkowi, który standaryzuje DMARCbis. Jeśli publikujesz zupełnie nowy rekord od zera, nasz przewodnik konfiguracji DMARC pokazuje jego czystą, trwałą postać.
Najczęściej zadawane pytania
Czy pct=50 przy p=reject przepuszcza połowę mojej poczty?
Nie. Odrzuca 50% niepoprawnej poczty, a pozostałe 50% poddaje kwarantannie. Żadna z Twojej niepoprawnej poczty nie jest dostarczana normalnie do skrzynki odbiorczej. Niewybrana część spada do następnej, niższej polityki, którą dla reject jest quarantine, a nie none.
Czy powinienem użyć niskiego pct przy przejściu na reject?
Nie. Ponieważ reszta polityki reject jest obniżana do kwarantanny, niskie pct przy p=reject zachowuje się niemal identycznie jak p=quarantine; pct=100. Osiągnij najpierw czystą kwarantannę przy 100%, a potem przeskocz od razu na p=reject; pct=100.
Czy pct ograniczy liczbę raportów DMARC, które otrzymuję?
Nie. Znacznik pct wpływa wyłącznie na egzekwowanie polityki wobec niepoprawnej poczty. Raporty zbiorcze nadal obejmują 100% Twojego ruchu, więc przez całe wdrożenie zachowujesz pełny wgląd w każde źródło wysyłki.
Skoro DMARCbis wycofuje pct, czy powinienem przestać go używać już teraz?
Możesz nadal go używać do etapowego wdrożenia, ponieważ obecni odbiorcy go respektują. Po prostu usuń go, gdy osiągniesz pełny reject. Gotowy rekord nie potrzebuje żadnego znacznika pct, co odpowiada zarówno domyślnej wartości z RFC 7489, jak i kierunkowi DMARCbis.