DMARC — jak ustawić monitoring i przejść do ochrony domeny?

DMARC pozwala właścicielowi domeny sprawdzić, czy poczta widocznie wysłana z jego adresu jest uwierzytelniona w sposób zgodny z tą domeną. Udostępnia też raporty o źródłach wysyłki i politykę dla wiadomości, które nie spełniają wymagań. Bezpieczne wdrożenie zaczyna się od obserwacji, a nie od natychmiastowego odrzucania.

Krótka odpowiedź: najpierw uruchom SPF i DKIM we wszystkich legalnych systemach. Następnie opublikuj jeden rekord TXT pod _dmarc.twojadomena.pl, początkowo z p=none i kontrolowanym adresem rua. Analizuj raporty, przypisz każde legalne źródło i popraw wyrównanie domen. Dopiero gdy dane pokazują, że prawidłowa poczta przechodzi DMARC, rozważ p=quarantine albo p=reject. Aktualny standard to RFC 9989 z maja 2026 roku; usunął on dawny tag pct i wprowadził testowy tag t.

Co sprawdza DMARC?

DMARC zaczyna od domeny autora widocznej dla użytkownika w nagłówku From. Następnie sprawdza wyniki SPF i DKIM oraz ich wyrównanie z tą domeną.

Wiadomość przechodzi DMARC, jeżeli spełniona jest przynajmniej jedna ścieżka:

1. SPF kończy się wynikiem pass, a oceniana domena SPF jest wyrównana z domeną From; albo
2. DKIM kończy się wynikiem pass, a domena d= prawidłowego podpisu jest wyrównana z domeną From.

Nie trzeba uzyskać obu wyników jednocześnie, choć praktycznie warto skonfigurować oba mechanizmy. Samo spf=pass dla technicznej domeny dostawcy lub dkim=pass dla niewyrównanej domeny nie wystarcza.

Wyrównanie domyślnie jest relaksowane. Oznacza to, że odpowiednia subdomena może być organizacyjnie zgodna z domeną autora. Tryb ścisły wymaga dokładniejszej zgodności i powinien być włączany tylko po rozpoznaniu wszystkich strumieni.

Co zmieniło RFC 9989?

W maju 2026 roku opublikowano RFC 9989, które zastąpiło wcześniejsze RFC 7489 oraz RFC 9091. Ma to praktyczne znaczenie dla poradników i generatorów rekordów.

Aktualny standard:

• nadal używa p=none, p=quarantine i p=reject;
• zachowuje raporty zbiorcze przez rua;
• usuwa dawny tag procentowy pct, ponieważ odbiorcy wdrażali go niespójnie;
• wprowadza tag t, którego wartość y sygnalizuje tryb testowy bez stosowania żądanej polityki, a n jest wartością domyślną.

Dlatego stary schemat „ustaw p=reject; pct=10, potem zwiększ procent” nie jest już rekomendacją zgodną z aktualnym RFC. Internetowe poradniki, panele dostawców i odbiorcy mogą przez pewien czas odwoływać się do starszego standardu. Weryfikuj realną obsługę u najważniejszych odbiorców i opieraj decyzję na raportach, nie na samym generatorze rekordu.

Krok 1: zinwentaryzuj pocztę przed DMARC

Spisz każdy system, który używa domeny w widocznym From:

• skrzynki pracowników;
• formularze z WordPressa;
• wiadomości sklepu;
• newsletter;
• faktury i rezerwacje;
• CRM, helpdesk i automatyzacje;
• dostawców działających w imieniu firmy;
• urządzenia lub monitoring wysyłające alerty.

Dla każdego strumienia zapisz adres From, domenę envelope sender, wynik SPF, domenę d= podpisu DKIM i właściciela biznesowego. Wyślij prawdziwe testy do co najmniej dwóch niezależnych usług pocztowych. Nie zakładaj, że wszystkie wiadomości u jednego dostawcy przechodzą identyczną trasą.

Jeśli formularz ustawia jako From adres klienta, popraw go przed wdrożeniem DMARC. Stały From powinien należeć do firmy, a adres klienta po walidacji trafiać do Reply-To.

Krok 2: przygotuj odbiór raportów

Najprostszy rekord monitorujący może wyglądać tak:

v=DMARC1; p=none; rua=mailto:dmarc@example.pl

To przykład składni, nie gotowa wartość dla każdej firmy. Adres rua musi być kontrolowany i przygotowany na automatyczne raporty zbiorcze. Odbiorcy zwykle przesyłają zagregowane dane w plikach XML, często skompresowanych.

Nie kieruj raportów na zwykłą skrzynkę pracownika. Użyj dedykowanego adresu lub zaufanej usługi analizującej, określ dostęp, retencję i odpowiedzialność za przegląd. Raporty zawierają metadane o źródłach poczty i powinny być traktowane jak dane operacyjne.

Jeżeli rua wskazuje domenę inną niż chroniona, potrzebna jest autoryzacja zewnętrznego miejsca raportowania opisana w standardzie. Bez niej odbiorcy mogą nie wysyłać raportów. Dostawca analizatora powinien podać dokładną konfigurację DNS.

Krok 3: opublikuj jeden rekord we właściwym miejscu

Dla example.pl rekord publikuje się pod nazwą:

_dmarc.example.pl

Typ to TXT, a wartość zaczyna się od v=DMARC1. Panel DNS może automatycznie dopisywać domenę, więc sprawdź końcową nazwę. Nie publikuj dwóch rekordów DMARC dla tej samej nazwy i nie umieszczaj go bezpośrednio pod example.pl.

Przed zmianą zachowaj istniejącą wartość oraz TTL. Po publikacji odczytaj publiczny DNS:

dig _dmarc.example.pl TXT

Weryfikator składni może znaleźć literówkę, lecz nie potwierdzi, że wszystkie legalne wiadomości są wyrównane. To pokażą dopiero nagłówki i raporty.

Jak czytać podstawowe tagi?

• v=DMARC1 — wersja rekordu;
• p=none — monitoring bez żądania kwarantanny lub odrzucenia;
• p=quarantine — prośba, aby niespełniające wiadomości traktować podejrzliwie, np. skierować do spamu;
• p=reject — prośba o odrzucanie wiadomości niespełniających DMARC;
• rua=mailto:... — adres raportów zbiorczych;
• adkim=r lub adkim=s — relaksowane albo ścisłe wyrównanie DKIM;
• aspf=r lub aspf=s — relaksowane albo ścisłe wyrównanie SPF;
• sp= — polityka dla subdomen w zakresie rekordu;
• np= — polityka dla nieistniejących subdomen;
• t=y — sygnał testowy według RFC 9989, bez stosowania opublikowanej polityki;
• t=n — zwykłe stosowanie polityki i wartość domyślna.

Nie dodawaj wszystkich tagów tylko dlatego, że istnieją. Krótsza, zrozumiała polityka jest łatwiejsza do utrzymania. Domyślne relaksowane wyrównanie zwykle dobrze odpowiada pierwszemu wdrożeniu.

Co oznacza p=none?

p=none nie prosi odbiorcy o specjalne potraktowanie wiadomości na podstawie samego niepowodzenia DMARC. Służy do monitorowania i uporządkowania źródeł. Nie chroni domeny tak mocno jak polityka egzekwująca, ale jest właściwym etapem startowym, jeśli nie masz kompletnej wiedzy o wysyłce.

Odbiorca nadal stosuje własne filtry antyspamowe i zasady bezpieczeństwa. Może odrzucić wiadomość z innych przyczyn albo przyjąć ją mimo wyniku. DMARC nie odbiera odbiorcy lokalnej kontroli.

Monitoring nie powinien trwać bezterminowo bez właściciela. Ustal cykl przeglądu raportów i kryteria przejścia dalej.

Jak analizować raporty zbiorcze?

Raport grupuje wiadomości według m.in. źródłowego IP, domen, wyników SPF/DKIM oraz zastosowanej polityki. Analiza powinna odpowiadać na pytania:

1. Czy rozpoznajemy źródło?
2. Która usługa i proces biznesowy je wykorzystuje?
3. Czy widoczny From jest zamierzony?
4. Czy SPF przechodzi i jest wyrównany?
5. Czy DKIM przechodzi i jest wyrównany?
6. Czy niepowodzenie dotyczy legalnej wiadomości, błędu konfiguracji czy podszycia?
7. Kto ma poprawić albo wyłączyć dany strumień?

Sam adres IP może należeć do dużej infrastruktury współdzielonej i nie wystarcza do identyfikacji. Łącz raport z nagłówkami kontrolowanej wiadomości, logami dostawcy i dokumentacją usługi.

Nie „naprawiaj” nieznanego źródła przez dopisanie go do SPF. Najpierw potwierdź właściciela i zasadność. Część ruchu będzie próbą podszycia, którą polityka ma docelowo ograniczyć.

Kiedy przejść do quarantine lub reject?

Nie wyznaczaj sztywnej liczby dni dla każdej domeny. Przejście jest uzasadnione, gdy:

• wszystkie legalne systemy są przypisane do właścicieli;
• reprezentatywne wiadomości przechodzą DMARC;
• raporty nie pokazują istotnego legalnego ruchu, który nadal nie jest wyrównany;
• procedura dodawania nowej usługi obejmuje SPF, DKIM i test DMARC;
• istnieje monitoring po zmianie oraz możliwość wycofania;
• osoba odpowiedzialna rozumie wpływ na subdomeny.

Można rozważyć etap p=quarantine przed p=reject, ale nie jest to automatyczny obowiązek ani procentowy rollout. Aktualne RFC usunęło pct. Jeśli używasz t=y do testowania przyszłej polityki, sprawdź, czy kluczowi odbiorcy rzeczywiście interpretują nowy tag zgodnie z RFC 9989. W okresie przejściowym najbardziej wiarygodne są własne testy i raporty.

Subdomeny i rozdzielenie strumieni

Tag sp pozwala określić politykę dla subdomen, a np dla nieistniejących subdomen. To przydatne, lecz wymaga znajomości architektury. Firma może używać osobnych subdomen dla newslettera, wiadomości transakcyjnych albo zwrotów. Nie ustawiaj ostrzejszej polityki dla subdomen, dopóki nie wiesz, które z nich legalnie wysyłają.

Rozdzielenie strumieni może ułatwić reputację i diagnostykę, ale nie powinno służyć ukrywaniu nieuporządkowanej konfiguracji. Każda używana domena nadal potrzebuje właściciela, prawidłowego uwierzytelnienia i obserwacji.

Najczęstsze błędy DMARC

• natychmiastowe p=reject bez inwentaryzacji;
• uznanie dowolnego spf=pass lub dkim=pass za wyrównany wynik;
• błędne ustawienie From w formularzu;
• raporty wysyłane na nieobsługiwaną skrzynkę;
• zewnętrzne rua bez wymaganej autoryzacji;
• dwa rekordy DMARC pod tą samą nazwą;
• błędna nazwa przez dwukrotne dopisanie domeny w panelu;
• bezrefleksyjne używanie starego pct mimo RFC 9989;
• zmiana adkim i aspf na tryb ścisły bez potrzeby;
• dopisywanie nieznanych źródeł do SPF zamiast ich identyfikacji;
• brak monitoringu po przejściu na politykę ochronną.

DMARC nie gwarantuje dostarczenia

Wynik dmarc=pass pomaga odbiorcy ustalić związek wiadomości z domeną autora. Nie gwarantuje skrzynki głównej. Na dostarczenie wpływają również reputacja domeny i adresów IP, jakość listy odbiorców, skargi, treść, częstotliwość oraz lokalne reguły odbiorcy.

Podobnie p=reject nie oznacza, że każda próba podszycia zniknie z internetu. Oszust może użyć podobnej domeny, innego adresu widocznego lub kanału komunikacji. DMARC chroni konkretny zakres nazw i powinien być częścią szerszego bezpieczeństwa marki.

Plan bezpiecznego wdrożenia

1. Spisz wszystkie strumienie i właścicieli.
2. Ustaw prawidłowy firmowy From w aplikacjach.
3. Skonfiguruj SPF bez drugiej polityki.
4. Włącz DKIM dla każdego dostawcy.
5. Potwierdź wyrównanie na rzeczywistych wiadomościach.
6. Przygotuj bezpieczny odbiór raportów.
7. Opublikuj p=none i analizuj dane.
8. Napraw albo wyłącz nierozpoznane legalne strumienie.
9. Ustal kryteria polityki ochronnej i plan wycofania.
10. Wdróż quarantine lub reject na podstawie dowodów.
11. Monitoruj stale i audytuj każdą nową usługę.

Checklista DMARC

• ☐ Korzystamy z aktualnego RFC 9989, a nie starego schematu z pct.
• ☐ Każdy legalny nadawca jest zinwentaryzowany.
• ☐ SPF i DKIM działają na prawdziwych wiadomościach.
• ☐ Co najmniej jeden wynik jest wyrównany z domeną From.
• ☐ Rekord istnieje pod właściwą nazwą _dmarc i tylko raz.
• ☐ rua prowadzi do kontrolowanego, monitorowanego miejsca.
• ☐ Zewnętrzny odbiorca raportów ma wymaganą autoryzację.
• ☐ Raporty mają właściciela, cykl przeglądu i retencję.
• ☐ Nieznane źródła są identyfikowane, a nie automatycznie dopuszczane.
• ☐ Polityka ochronna ma kryteria wdrożenia i plan wycofania.
• ☐ Po każdej zmianie kontrolujemy nagłówki, raporty i logi dostawców.