DMARC: p=none, quarantine czy reject – kiedy zaostrzać

DMARC nie chroni poczty sam z siebie. To instrukcja dla serwera odbiorcy: co zrobić z wiadomością, która podała się za twoją domenę, ale nie potrafiła tego udowodnić. Trzy poziomy tej instrukcji to p=none, quarantine i reject. Różnią się wyłącznie tym, jak bardzo odbiorca ma być bezwzględny wobec podróbki. Wpis żyje w DNS pod nazwą _dmarc.domena.pl, a tag p ustawia politykę dla domeny głównej.

Co naprawdę robi polityka DMARC

Cały mechanizm stoi na dwóch filarach, które musisz mieć wcześniej: SPF i DKIM. DMARC sam z siebie nie sprawdza niczego. Bierze wyniki tamtych dwóch weryfikacji i dokłada jeden warunek: wyrównanie, czyli alignment. Domena z pola From musi zgadzać się z domeną z Return-Path (dla SPF) albo z domeną z podpisu DKIM. Sam pozytywny SPF nic nie daje, jeśli koperta idzie z domeny dostawcy, a w nagłówku widnieje twoja. Jeśli zaczynasz od zera, przejdź najpierw konfigurację SPF, DKIM i DMARC krok po kroku.

I tu wysypuje się większość wdrożeń. Firma widzi zielony wynik SPF w narzędziu diagnostycznym, przestawia politykę na reject i po tygodniu okazuje się, że faktury z systemu księgowego nie docierają. SPF przechodził. Tylko na domenie dostawcy.

Zapamiętaj kolejność. Bez działającego uwierzytelnienia zaostrzenie polityki niczego nie poprawia w dostarczalności. Wycina za to twoją własną pocztę – tę, którą wysyłasz legalnie, z narzędzi, o których zapomniałeś. A podszywający się nadawca to przeżyje, bo po prostu zmieni domenę. Ty zostaniesz z niedostarczonymi powiadomieniami transakcyjnymi.

Trzy polityki i ich realne skutki

Różnice sprowadzają się do losu wiadomości bez wyrównania.

• p=none – tryb obserwacji. Poczta idzie normalną drogą, filtry działają jak zwykle, nic się nie zmienia. Jedyny efekt to raporty spływające na wskazany adres. Etap zbierania danych, nie ochrona.
• p=quarantine – wiadomość bez wyrównania trafia do spamu albo do kwarantanny po stronie odbiorcy. Nadawca nie dostaje żadnego sygnału. Odbiorca może ją znaleźć, jeśli będzie szukał.
• p=reject – serwer odbiorcy odrzuca wiadomość na etapie sesji SMTP. Nadawca dostaje bounce z konkretnym powodem. Po stronie odbiorcy wiadomość po prostu nie istnieje.

Do tego dwa tagi, które ratują wdrożenia. pct pozwala objąć polityką tylko część ruchu, więc zaostrzasz stopniowo zamiast skokiem. sp ustawia osobną politykę dla subdomen. O tym drugim zapomina się notorycznie, a subdomena bez własnej reguły dziedziczy politykę domeny głównej dopiero wtedy, gdy nie wskażesz inaczej – w praktyce zostawiona luka bywa furtką dla podszywania się pod faktury.twojadomena.pl.

W raportach wszystkie trzy polityki wyglądają podobnie: widzisz adres IP, wyniki i deklarowaną dyspozycję. Różnica siedzi w skrzynce odbiorcy, nie w XML-u.

Zanim zaostrzysz: inwentaryzacja nadawców

Każda domena wysyła z większej liczby miejsc, niż ktokolwiek w firmie pamięta. System transakcyjny, CRM, moduł fakturowania, formularz kontaktowy na stronie, skrzynki handlowców, narzędzie do wysyłek masowych, monitoring, kadry. Każde z tych źródeł to osobny przypadek do sprawdzenia.

Dwie rzeczy mylą się tu najczęściej. Return-Path decyduje o SPF, więc adres w kopercie i adres w polu From to dwa różne byty – mogą wskazywać różne domeny i zwykle wskazują. DKIM z kolei podpisuje treść i wybrane nagłówki, przez co przetwarzanie po drodze potrafi podpis unieważnić: dopisany baner, zmieniony temat, przepakowana wiadomość. Przekierowania i listy mailingowe łamią SPF praktycznie zawsze, bo koperta zmienia nadawcę. Ratuje je wtedy wyłącznie poprawny DKIM.

1. Zbierz listę wszystkich systemów wysyłających z twojej domeny. Pytaj działy, nie tylko IT.
2. Dla każdego sprawdź Return-Path i domenę podpisu DKIM pod kątem wyrównania z From.
3. Podłącz DKIM wszędzie, gdzie dostawca to umożliwia, z własną domeną w selektorze.
4. Dopiero po zamknięciu listy ruszaj tag p.

Tip: zacznij od skrzynek działu handlowego i narzędzi zewnętrznych. Tam najczęściej brakuje podpisu, bo integrację robiono na szybko i nikt nie wrócił do DNS. Warto przy okazji spisać, przez jakie integracje z zewnętrznymi systemami wychodzi poczta z twojej domeny.

Raporty DMARC: jak czytać je bez zgadywania

Adres w tagu rua zbiera raporty zbiorcze, ruf raporty z próbkami wiadomości. Na ruf nie licz – spora część operatorów ich nie wysyła, głównie ze względu na dane osobowe w treści. Cała praca odbywa się na raportach zbiorczych.

Pojedynczy raport pokazuje adres IP nadawcy, liczbę wiadomości, wynik SPF, wynik DKIM oraz to, czy któryś z nich był wyrównany. Surowy XML nadaje się do parsowania, nie do czytania. Potrzebujesz agregatora albo własnego parsera zrzucającego dane do tabeli.

Szukasz trzech rzeczy. Pierwsza: własna infrastruktura wysyłająca bez podpisu – serwer aplikacyjny, drukarka sieciowa, stary skrypt cron. Druga: dostawcy, o których nikt nie pamiętał, rozpoznawalni po zakresach IP. Trzecia: ruch obcy, czyli faktyczne podszywanie się pod domenę.

Z naszej strony wygląda to tak: przy własnej flocie serwerów wysyłkowych sprawdzamy zgodność Return-Path, rekordy PTR i podpis DKIM zanim ruszy pierwsza kampania klienta. Rutyna przed startem, nie reakcja na problem. Uczciwie o ograniczeniu: wbudowany panel raportów DMARC mamy na roadmapie, na dziś przy analizie korzystamy z zewnętrznego agregatora.

Kiedy przejść na quarantine

Warunek wejścia jest jeden. W raportach przez pełny cykl wysyłek nie pojawia się żaden legalny nadawca bez wyrównania. Pełny cykl znaczy: łącznie z procesami miesięcznymi i kwartalnymi. Nie dwa tygodnie obserwacji.

Przestawiaj się przez pct. Zacznij od części ruchu, poczekaj, podnieś. Jeśli coś pęknie, pęknie na ułamku wysyłek, a ty zdążysz zareagować przed lawiną zgłoszeń.

Obserwuj przy tym dwa źródła sygnału, nie jedno. Bounce i statystyki to jedno, ale poważniejsze rzeczy przychodzą z działu obsługi klienta: „klient nie dostał potwierdzenia”, „przypomnienie nie doszło”. Raport zbiorczy pokaże ci problem z opóźnieniem, człowiek zgłosi go tego samego dnia.

Najwięcej niespodzianek robią wysyłki rzadkie. Przypomnienia o płatnościach, powiadomienia roczne, korespondencja z systemów kadrowych, coroczne ankiety. Te procesy potrafią odezwać się raz na kilka miesięcy z serwera, którego nie ma na żadnej liście.

Tip: nie zaostrzaj polityki w tygodniu dużej kampanii ani przed długim weekendem. Zmianę w DNS trzeba mieć komu cofnąć.

Kiedy reject ma sens, a kiedy jest przedwczesny

Reject broni się tam, gdzie koszt fałszywej wiadomości przewyższa koszt wiadomości zgubionej. Domeny transakcyjne, banki, sklepy, marki narażone na podszywanie w phishingu. Jeśli ktoś rozsyła w twoim imieniu wezwania do zapłaty, kwarantanna to za mało.

Rozdzielenie ruchu upraszcza całą operację. Domena firmowa z kontrolowaną wysyłką może iść na reject szybko. Domena obsługująca rozproszony ruch z kilkunastu integracji potrzebuje więcej czasu. Osobne domeny wysyłkowe dla marketingu i systemów transakcyjnych rozwiązują ten konflikt u źródła.

Domeny parkowane i nieużywane do wysyłki traktuj inaczej: reject od razu, do tego pusty rekord SPF. Nic stamtąd nie wychodzi, więc nie ma czego psuć.

Odpuść, jeśli nie masz kontroli nad DNS, jeśli kluczowy dostawca nie oferuje DKIM na twojej domenie albo jeśli twoja poczta idzie przez listy dyskusyjne nieobsługujące ARC. To nie porażka, to kolejność prac.

Jedno zastrzeżenie. Reject nie omija filtrów antyspamowych i nie poprawia reputacji nadawcy. Redukuje podszywanie się pod domenę i tyle. Z blokad u dużych filtrów wychodzi się stabilną infrastrukturą, rozsądnym warmupem nowych adresów IP i czyszczeniem listy z martwych adresów. Tag polityki nie ma z tym nic wspólnego.

DMARC a zgody i przepisy

Uwierzytelnienie i podstawa prawna wysyłki to dwie osobne sprawy, mylone zaskakująco często. DMARC odpowiada na pytanie „czy ta wiadomość naprawdę pochodzi od ciebie”. Nie odpowiada na pytanie „czy wolno ci ją wysłać”.

Po stronie prawnej obowiązują RODO oraz Prawo komunikacji elektronicznej. Artykuł 398 PKE wymaga zgody odbiorcy również wtedy, gdy adres należy do firmy. Rozróżnienie B2B kontra B2C nie zwalnia z obowiązku – liczy się to, czy adres jest przypisany do konkretnej osoby.

Idealnie skonfigurowany DMARC nie legalizuje wysyłki na kupioną bazę. Poprawi ci wyniki uwierzytelnienia, nie sytuację przed organem nadzorczym. Dlatego przy wyborze platformy patrz na rejestr zgód: czy system zapisuje moment, źródło i treść zgody, i czy potrafisz ją wykazać po roku. To realna funkcja, nie deklaracja w cenniku. Sprawdź, czy funkcje platformy wysyłkowej obejmują dokumentowanie zgód, a nie tylko samą wysyłkę.

My budujemy to razem: uwierzytelnienie po stronie infrastruktury i dokumentowanie zgód po stronie aplikacji. Jeśli szukasz jednego miejsca na obie rzeczy, zobacz platformę do email marketingu z własną flotą serwerów wysyłkowych.

Podsumowanie: kolejność, która działa

Kolejność jest prosta i nie ma w niej skrótów. SPF i DKIM dla wszystkich nadawców. Potem p=none i kilka tygodni raportów. Potem quarantine z rosnącym pct. Na końcu reject.

Przeskoczenie etapu kosztuje zawsze to samo: pocztę transakcyjną. Potwierdzenia zamówień, resety hasła, faktury. Rzeczy, których brak zauważy klient, zanim zauważy je twój monitoring.

Ustaw sp razem z p, żeby subdomeny nie zostały otwartą furtką. I traktuj DMARC jako proces, nie jednorazowy wpis w DNS – nowe narzędzie w firmie oznacza nowego nadawcę do sprawdzenia.

Lista kontrolna na najbliższy tydzień:

1. Sprawdź, czy _dmarc.twojadomena.pl w ogóle istnieje i jaką ma politykę.
2. Dodaj adres w tagu rua, jeśli go nie ma. Bez raportów pracujesz na wyczucie.
3. Spisz wszystkie systemy wysyłające z twojej domeny, dział po dziale.
4. Dla każdego zweryfikuj DKIM z własną domeną w selektorze.
5. Ustaw sp na tym samym poziomie co p.
6. Zaplanuj przegląd raportów w stałym terminie, na przykład raz w miesiącu.