DMARC raport XML: jak czytać i reagować krok po kroku

Codziennie na skrzynkę techniczną spływają pliki XML z raportem DMARC — i przez większość czasu lądują w koszu albo w archiwum, bo nikt nie wie, co z nimi zrobić. To błąd. Właśnie w tych kilkukilobajtowych plikach ukryte są informacje o tym, kto próbuje wysyłać maile w imieniu Twojej domeny — legalnie lub nie. Ten artykuł pokaże Ci, jak czytać dmarc raport krok po kroku, czym różni się aggregate report od forensic DMARC i jak na tej podstawie podjąć konkretne działania.

Czym właściwie jest raport DMARC i skąd pochodzi?

DMARC (Domain-based Message Authentication, Reporting and Conformance) to mechanizm opisany w RFC 7489, który opiera się na wynikach SPF i DKIM. Gdy odbiorca przetwarza wiadomość e-mail, sprawdza, czy przeszła ona weryfikację SPF lub DKIM, a następnie — czy domeny w tych mechanizmach zgadzają się z domeną w nagłówku From:. Wynik tego sprawdzenia trafia do raportu i jest wysyłany na adres podany w rekordzie DNS _dmarc.

Raporty generują duże serwisy pocztowe: Google (Gmail), Microsoft (Outlook/Hotmail), Yahoo, a także mniejsze systemy zgodne ze standardem. Każdy z nich wysyła raport raz na 24 godziny (domyślnie) w formacie skompresowanego XML — jako załącznik .xml.gz lub .zip.

Dwa typy raportów: aggregate i forensic DMARC

Zanim zaczniesz analizować pliki, musisz wiedzieć, że istnieją dwa zupełnie różne rodzaje raportów DMARC. Mylenie ich to najczęstszy błąd początkujących administratorów.

Aggregate report (RUA) — dane zbiorcze

Aggregate report to raport zbiorczy. Zawiera statystyki dla wszystkich wiadomości przetworzonych przez danego odbiorcę w ciągu doby — ile przeszło weryfikację, ile nie, z jakich adresów IP były wysyłane. Nie zawiera treści wiadomości ani nagłówków konkretnych maili. To dane ilościowe, idealne do monitorowania stanu infrastruktury.

Adres do dostarczania aggregate reportów konfiguruje się w rekordzie DNS przez tag rua=mailto:dmarc-rua@twojadomena.pl.

Forensic DMARC (RUF) — raporty incydentowe

Forensic DMARC (raport RUF) to zupełnie inna bestia. Generowany jest dla każdej pojedynczej wiadomości, która nie przeszła weryfikacji DMARC. Zawiera nagłówki wiadomości (a w niektórych implementacjach fragmenty treści), co pozwala zidentyfikować konkretny incydent spoofingu lub błąd konfiguracyjny. Adres konfiguruje się przez tag ruf=mailto:dmarc-ruf@twojadomena.pl.

Uwaga praktyczna: wielu dużych dostawców (w tym Gmail od 2023 r.) zaprzestało wysyłania raportów RUF ze względu na obawy dotyczące prywatności. Nie licz na forensic DMARC jako jedyne źródło danych — aggregate report jest dziś ważniejszy.

Struktura pliku DMARC XML — element po elemencie

Po rozpakowaniu archiwum znajdziesz plik XML. Poniżej omówienie kluczowych elementów na przykładzie realnej struktury.

Nagłówek raportu (<report_metadata>)

Tutaj znajdziesz metadane: kto wysłał raport (org_name), adres e-mail kontaktowy, unikalny identyfikator raportu (report_id) oraz zakres czasowy (date_range z polami begin i end w formacie Unix timestamp). To pozwala ustalić, za jaką dobę dotyczy raport i który dostawca go wygenerował.

Polityka DMARC w momencie raportu (<policy_published>)

Ten element pokazuje, jaka polityka DMARC obowiązywała dla Twojej domeny w chwili generowania raportu. Kluczowe pola to:

• p — polityka dla domeny głównej: none, quarantine lub reject
• sp — polityka dla subdomen
• pct — procent wiadomości objętych polityką (domyślnie 100)
• adkim / aspf — tryb wyrównania dla DKIM i SPF: r (relaxed) lub s (strict)

Rekordy wiadomości (<record>)

To serce raportu. Każdy rekord opisuje grupę wiadomości z jednego adresu IP. Składa się z trzech podsekcji:

<row> — skąd i ile

• source_ip — adres IP serwera, który wysłał wiadomości
• count — liczba wiadomości z tego IP w danej dobie
• policy_evaluated — jaka decyzja została podjęta (pass, quarantine, reject) i wyniki SPF/DKIM (pass lub fail)

<identifiers> — kto nadał

Pole header_from to domena widoczna w nagłówku From: wiadomości — ta, którą widzi odbiorca. Pole envelope_from to domena w kopercie SMTP (używana przez SPF).

<auth_results> — wyniki weryfikacji

Tu znajdziesz szczegóły: która domena DKIM podpisała wiadomość, czy podpis był poprawny (pass/fail/permerror/temperror), oraz wynik SPF dla domeny kopertowej.

Jak czytać dmarc xml w praktyce — 5 kroków

Surowy XML jest czytelny, ale przy dziesiątkach raportów dziennie praca ręczna nie ma sensu. Oto jak podejść do analizy systematycznie.

1. Zbierz raporty w jednym miejscu. Ustaw dedykowaną skrzynkę (np. dmarc-rua@twojadomena.pl) i skonfiguruj automatyczne odpakowywanie załączników. Narzędzia open-source jak parsedmarc lub dmarc-srg robią to automatycznie i wrzucają dane do bazy.
2. Zidentyfikuj wszystkie źródłowe adresy IP. Każde IP w polu source_ip to serwer, który wysłał maile z Twoją domeną w From:. Sprawdź, czy znasz wszystkie te serwery — własny SMTP, CRM, platforma mailingowa, zewnętrzny helpdesk.
3. Sprawdź wyniki policy_evaluated. Rekordy z disposition: none i dkim: pass + spf: pass to poprawne wiadomości. Rekordy z dkim: fail i spf: fail jednocześnie to kandydaci do dalszego dochodzenia.
4. Wykonaj reverse DNS i whois dla podejrzanych IP. Jeśli IP nie należy do żadnego Twojego dostawcy usług, masz potencjalny przypadek spoofingu lub nieautoryzowanego nadawcy.
5. Porównaj z historią. Jednorazowy błąd z nieznanego IP może być przypadkiem (np. przekierowanie poczty). Powtarzający się ruch z tego samego IP przez kilka dni to sygnał alarmowy.

Tabela: najczęstsze kombinacje wyników i co oznaczają

Kogo „ścigać" — jak odróżnić spoofing od błędu konfiguracji

Nie każdy rekord z dmarc: fail oznacza atak. Zanim zaczniesz panikować, sprawdź trzy scenariusze.

Scenariusz 1: Zapomniany nadawca wewnętrzny

Twój dział marketingu zaczął używać nowego narzędzia do wysyłki newsletterów, ale nikt nie dodał jego serwerów do rekordu SPF ani nie skonfigurował DKIM. Wynik: setki rekordów fail z IP należącego do legalnego dostawcy. Rozwiązanie: dodaj IP do SPF i wygeneruj klucz DKIM. MailerPRO pozwala skonfigurować własną skrzynkę SMTP i wygenerować rekordy DNS w kilka minut — to typowy przypadek, gdzie aggregate report natychmiast wskazuje problem.

Scenariusz 2: Przekierowanie poczty (email forwarding)

Użytkownik ma skonfigurowane przekierowanie z domeny firmowej na prywatną skrzynkę Gmail. Serwer pośredniczący nie przepisuje koperty SMTP, więc SPF dla oryginalnej domeny failuje. DKIM zwykle przeżywa przekierowanie (o ile serwer pośredni nie modyfikuje treści). To nie atak — to ograniczenie architektury e-mail. Rozwiązanie: upewnij się, że DKIM jest skonfigurowany i podpisuje wiadomości, wtedy DMARC przejdzie mimo SPF fail.

Scenariusz 3: Prawdziwy spoofing

Nieznane IP, brak jakiegokolwiek powiązania z Twoją infrastrukturą, wysoki wolumen wiadomości, powtarzający się przez kilka dni. To klasyczny przypadek spoofingu — ktoś wysyła maile podszywając się pod Twoją domenę. Co robić:

• Zmień politykę DMARC z p=none na p=quarantine, a docelowo p=reject — wtedy serwery odbiorców będą odrzucać takie wiadomości.
• Zgłoś IP do odpowiedniego abuse contact (znajdziesz go przez whois lub serwis abuse.ch).
• Jeśli skala jest duża, rozważ zgłoszenie do CERT Polska (cert.pl) — szczególnie jeśli wiadomości mają charakter phishingowy i mogą naruszać art. 267 Kodeksu karnego (nieuprawniony dostęp do informacji) lub art. 287 k.k. (oszustwo komputerowe).
• Zachowaj forensic DMARC (jeśli dostępny) jako dowód — nagłówki wiadomości mogą być przydatne w postępowaniu.

Jak przyspieszyć analizę — narzędzia do parsowania XML

Ręczne otwieranie plików XML to strata czasu. Oto sprawdzone podejścia:

Narzędzia open-source

• parsedmarc — skrypt Python, który parsuje raporty RUA i RUF, zapisuje do Elasticsearch lub pliku JSON/CSV. Idealny do własnego środowiska.
• dmarc-srg — aplikacja webowa PHP, prosta w instalacji, dobra dla małych zespołów.
• Postmark DMARC Digests — darmowa usługa SaaS, która odbiera raporty i wysyła cotygodniowe podsumowanie e-mailem.

Jak zautomatyzować odbiór raportów

Najprościej: utwórz dedykowaną skrzynkę pocztową dla raportów DMARC, skonfiguruj regułę, która automatycznie przekazuje załączniki do parsera. Jeśli używasz własnego serwera SMTP (np. przez MailerPRO), możesz skierować raporty na lokalną skrzynkę i przetwarzać je skryptem crona co noc.

Droga do p=reject — jak bezpiecznie zaostrzać politykę

Przejście od p=none do p=reject powinno być stopniowe. Nagła zmiana bez uprzedniej analizy raportów może zablokować legalne wiadomości.

1. Faza 1 — monitoring (p=none): Zbieraj aggregate raporty przez minimum 2-4 tygodnie. Zidentyfikuj wszystkich legalnych nadawców.
2. Faza 2 — kwarantanna (p=quarantine; pct=10): Zacznij od 10% wiadomości objętych polityką. Obserwuj, czy coś trafia do spamu, czego nie powinno.
3. Faza 3 — stopniowe zwiększanie: Podnoś pct co 1-2 tygodnie: 25%, 50%, 100%.
4. Faza 4 — odrzucanie (p=reject): Gdy jesteś pewny, że wszyscy legalni nadawcy mają poprawne SPF i DKIM, przejdź na reject. To jedyna polityka, która realnie chroni przed spoofingiem.

Ważne: Polityka p=none to tryb obserwacji — nie chroni odbiorców przed spoofingiem. Raporty DMARC mają sens tylko wtedy, gdy docelowo prowadzą do p=reject.

Analiza raportów DMARC XML to nie jednorazowa czynność — to ciągły proces monitorowania, który pozwala utrzymać reputację domeny i chronić odbiorców przed phishingiem. Zacznij od skonfigurowania dedykowanej skrzynki RUA, zainstaluj parser, przejrzyj pierwsze raporty według opisanego schematu i zaplanuj migrację do p=reject. Twoja domena będzie wtedy znacznie trudniejszym celem dla oszustów — i znacznie bardziej wiarygodnym nadawcą dla odbiorców.