Raporty DMARC RUA i RUF — jak je czytać i analizować

Skonfigurowałeś rekord DMARC dla swojej domeny — brawo. Ale czy wiesz, co dzieje się z raportami, które zaczęły spływać na Twój adres rua@? Większość administratorów ignoruje te pliki, bo wyglądają jak nieczytelna masa XML. Tymczasem raporty DMARC to najdokładniejsze źródło wiedzy o tym, kto i w jaki sposób wysyła wiadomości podszywając się pod Twoją domenę. Ten poradnik przeprowadzi Cię przez cały proces — od otwarcia pierwszego pliku po wyciągnięcie wniosków, które realnie podniosą bezpieczeństwo Twojego mailingu.

Czym są raporty DMARC i dlaczego warto je czytać

DMARC (Domain-based Message Authentication, Reporting and Conformance) to mechanizm, który łączy SPF i DKIM w jeden spójny system weryfikacji. Gdy serwer odbiorcy przetworzy wiadomość, wysyła raport z powrotem do właściciela domeny — zgodnie z adresami podanymi w rekordzie DNS. Raporty dzielą się na dwa typy, które pełnią zupełnie różne funkcje.

Raport agregowany (RUA) — widok z lotu ptaka

DMARC aggregate report (tag rua=) to dzienny lub tygodniowy plik XML wysyłany przez każdego operatora skrzynki pocztowej, który obsłużył maile z Twojej domeny. Google, Microsoft, Yahoo — każdy z nich generuje osobny plik. Raport zawiera statystyki zbiorcze: ile wiadomości przeszło weryfikację SPF i DKIM, ile nie, z jakich adresów IP były wysyłane i jaka polityka DMARC została zastosowana. Nie znajdziesz tu treści maili ani danych osobowych nadawcy — tylko liczby i metadane techniczne.

Raport kryminalistyczny (RUF) — szczegóły pojedynczej wiadomości

Forensic report DMARC (tag ruf=) to powiadomienie generowane w czasie rzeczywistym dla każdej wiadomości, która nie przeszła weryfikacji. Zawiera nagłówki wiadomości, a czasem (zależnie od konfiguracji operatora) jej treść. Uwaga: wiele dużych dostawców — w tym Gmail — nie wysyła raportów RUF ze względu na ochronę prywatności użytkowników. Jeśli Twój rekord zawiera tylko ruf=, możesz nigdy nie otrzymać tych danych od największych graczy. Skup się więc przede wszystkim na RUA.

Struktura rekordu DMARC — co ustawiasz, to dostajesz

Zanim przejdziesz do analizy raportów, upewnij się, że Twój rekord DNS jest poprawnie skonfigurowany. Przykładowy rekord TXT dla domeny _dmarc.twojadomena.pl:

v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@twojadomena.pl; ruf=mailto:dmarc-ruf@twojadomena.pl; fo=1; pct=100; adkim=r; aspf=r

Jeśli adres rua= należy do innej domeny niż wysyłająca (np. korzystasz z zewnętrznego narzędzia do analizy), ta domena musi opublikować własny rekord weryfikacyjny w DNS, np. twojadomena.pl._report._dmarc.zewnetrznydomain.com TXT "v=DMARC1" — inaczej raporty nie zostaną dostarczone.

Anatomia pliku XML — jak czytać raporty DMARC krok po kroku

Raporty RUA przychodzą jako spakowane archiwa .zip lub .gz. Po rozpakowaniu znajdziesz plik XML. Nie musisz być programistą, żeby go zrozumieć — poniżej rozkładamy strukturę na czynniki pierwsze.

Sekcja nagłówkowa — metadane raportu

Każdy plik zaczyna się od bloku <report_metadata>. Zawiera on nazwę organizacji wysyłającej raport (np. google.com), unikalny identyfikator raportu, adres e-mail kontaktowy oraz zakres dat, który raport obejmuje (znaczniki czasu Unix). Sprawdź, czy zakres dat zgadza się z tym, czego oczekujesz — czasem raporty przychodzą z opóźnieniem.

Sekcja polityki — co było aktywne w danym okresie

Blok <policy_published> pokazuje, jaki rekord DMARC odczytał odbiorca w momencie przetwarzania wiadomości. Porównaj go z tym, co masz aktualnie w DNS — rozbieżności mogą wskazywać na błąd propagacji lub nieautoryzowaną zmianę rekordu.

Sekcja rekordów — serce analizy DMARC XML

Każdy blok <record> opisuje grupę wiadomości wysłanych z konkretnego adresu IP. Oto kluczowe pola:

• <source_ip> — adres IP serwera, który wysłał wiadomości. To pierwsze miejsce, gdzie szukasz nieznanych nadawców.
• <count> — liczba wiadomości z tego IP w danym okresie.
• <disposition> — co zrobił odbiorca: none, quarantine lub reject.
• <dkim> i <spf> — wyniki weryfikacji: pass lub fail.
• <header_from> — domena z nagłówka From:, która musi być wyrównana z domeną DKIM lub SPF.

Przykładowy fragment XML, który powinieneś umieć odczytać:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>1842</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
</record>

Co to oznacza? Google wysłał 1842 wiadomości z Twojej domeny (np. przez Gmail Workspace). DKIM przeszedł — podpis cyfrowy jest poprawny. SPF nie przeszedł — prawdopodobnie serwer wysyłający nie jest uwzględniony w rekordzie SPF. Wynik końcowy DMARC: pass (bo DKIM wystarczy przy trybie relaxed). Ale to sygnał, żeby zaktualizować SPF.

Najczęstsze wzorce w raportach i co z nimi zrobić

Scenariusz 1: Nieznane IP z wynikiem „fail"

Widzisz adres IP, którego nie rozpoznajesz, z wynikami dkim=fail i spf=fail. To klasyczny sygnał próby spoofingu lub phishingu — ktoś próbuje wysyłać maile podszywając się pod Twoją domenę. Sprawdź IP w serwisach takich jak ipinfo.io lub Shodan. Jeśli IP należy do nieznanego providera z kraju, z którym nie współpracujesz — to prawie na pewno atak. Przy polityce p=none te maile trafiają do odbiorców. Czas na p=quarantine lub p=reject.

Scenariusz 2: Znane IP, ale SPF fail

Twój system CRM lub platforma mailingowa wysyła wiadomości, DKIM przechodzi, ale SPF nie. Przyczyna: serwer wysyłający nie jest wymieniony w rekordzie SPF Twojej domeny. Rozwiązanie: dodaj mechanizm include: lub ip4: dla tego serwera. Pamiętaj, że rekord SPF nie może przekraczać 10 zapytań DNS (lookupów) — to limit protokołu (RFC 7208, sekcja 4.6.4).

Scenariusz 3: Własne IP, DKIM fail

Twój serwer jest w SPF, ale DKIM nie przechodzi. Najczęstsze przyczyny: rotacja kluczy DKIM bez aktualizacji DNS, błędna konfiguracja selektora lub modyfikacja treści wiadomości przez pośrednika (np. mailing list, który dodaje stopkę). Sprawdź, czy selektor DKIM w nagłówku DKIM-Signature odpowiada kluczowi opublikowanemu w DNS.

Scenariusz 4: Wysoki wolumen z disposition=quarantine

Setki lub tysiące wiadomości lądują w spamie u odbiorców — to widać w raporcie jako disposition=quarantine. Jeśli te maile to Twoje legalne wysyłki (np. newsletter), problem leży w reputacji IP lub domeny, nie w samym DMARC. Jeśli to nieznane IP — Twoja polityka DMARC działa poprawnie i chroni odbiorców.

Narzędzia do analizy raportów DMARC — nie musisz czytać XML ręcznie

Ręczne parsowanie XML ma sens edukacyjnie, ale w praktyce przy kilkudziesięciu raportach dziennie potrzebujesz narzędzia. Dostępne opcje to:

• dmarcian — jeden z najpopularniejszych serwisów, oferuje wizualizację danych i alerty. Plan darmowy dla małych domen.
• Postmark DMARC — bezpłatny parser, wysyła cotygodniowe podsumowania na e-mail.
• MXToolbox DMARC Analyzer — prosty interfejs, dobry do jednorazowej analizy.
• Google Postmaster Tools — jeśli wysyłasz dużo maili do użytkowników Gmail, to niezastąpione źródło danych o reputacji domeny.
• Własny skrypt Python — biblioteka xmltodict pozwala przetworzyć pliki RUA w kilkanaście linii kodu i wrzucić dane do bazy lub arkusza kalkulacyjnego.

Jeśli korzystasz z MailerPRO do wysyłki przez własne serwery SMTP, warto skierować adres rua= na dedykowaną skrzynkę i skonfigurować automatyczne parsowanie — dzięki temu od razu widzisz, które serwery wysyłające wymagają korekty konfiguracji SPF lub DKIM.

Monitorowanie domeny DMARC — od p=none do p=reject

Wdrożenie DMARC to proces, nie jednorazowa czynność. Standardowa ścieżka wygląda tak:

1. Faza obserwacji (p=none) — zbierasz raporty przez 2–4 tygodnie bez wpływu na dostarczalność. Identyfikujesz wszystkich legalnych nadawców.
2. Faza kwarantanny (p=quarantine; pct=10) — stopniowo zwiększasz procent wiadomości objętych polityką. Zacznij od 10%, obserwuj raporty, dojdź do 100%.
3. Faza odrzucania (p=reject) — najsilniejsza ochrona. Wiadomości, które nie przejdą DMARC, są odrzucane przez serwery odbiorców. Google i Yahoo wymagają p=reject lub p=quarantine od nadawców masowych (ponad 5000 wiadomości dziennie) zgodnie z wytycznymi z lutego 2024 roku.

Nie spiesz się z przejściem do p=reject bez dokładnej analizy raportów. Pochopna zmiana może zablokować legalne wysyłki — np. z systemu ERP, który wysyła faktury przez Twoją domenę, ale nie ma skonfigurowanego DKIM.

DMARC a RODO — co z danymi w raportach RUF

Raporty forensic (RUF) mogą zawierać nagłówki wiadomości, a w niektórych przypadkach adresy e-mail nadawców i odbiorców. To dane osobowe w rozumieniu art. 4 ust. 1 RODO. Jeśli przechowujesz te raporty dłużej niż jest to konieczne do celów bezpieczeństwa, powinieneś uwzględnić je w rejestrze czynności przetwarzania (art. 30 RODO) i określić okres retencji. Praktyczna zasada: raporty RUF przechowuj maksymalnie 30–90 dni, a dostęp do nich ogranicz do osób odpowiedzialnych za bezpieczeństwo IT.

Analiza raportów DMARC to nie jednorazowe zadanie — to ciągły proces monitorowania, który pozwala wychwycić próby spoofingu, błędy konfiguracyjne i nowe systemy wysyłające zanim staną się problemem. Zacznij od skonfigurowania dedykowanej skrzynki na raporty RUA, przeparsuj pierwsze pliki XML korzystając z powyższego przewodnika, a następnie wdróż narzędzie do automatycznej wizualizacji. Gdy Twoje raporty pokażą 95%+ wynik pass dla wszystkich znanych nadawców — jesteś gotowy, żeby przestawić politykę na p=reject i realnie chronić swoją domenę przed phishingiem.