SecVaultAudytor
EN
Poradnik, aktualizacja 05.11.2026

Raporty DMARC: jak je czytać i co z nimi zrobić

Po dodaniu adresu rua do rekordu DMARC zaczynają przychodzić maile z załącznikami XML. To zbiorcze raporty od serwerów, które odbierają pocztę z Twojej domeny. Pokazują, kto wysyła w Twoim imieniu i czy ta poczta przechodzi DMARC. Z nich dowiesz się, czy możesz bezpiecznie zaostrzyć politykę.

Sprawdź swoją domenę za darmo

Raporty zbiorcze (rua) i awaryjne (ruf)

Rekord DMARC może wskazać dwa rodzaje adresów. Tag rua to adres na raporty zbiorcze: podsumowanie wiadomości z jednego okresu, bez treści pojedynczych listów. Tag ruf to adres na raporty awaryjne, czyli opisy pojedynczych wiadomości, które nie przeszły sprawdzenia. Awaryjne raporty niosą więcej szczegółów o konkretnych wiadomościach, więc mogą zawierać dane osobowe: adresy nadawców i odbiorców, a czasem fragmenty listu. RFC 9990 zaznacza, że raporty o takim poziomie szczegółów niosą większe ryzyko niż zbiorcze. Nie masz gwarancji, że dany odbiorca je wyśle, a te, które przyjdą, traktuj jak pocztę z danymi klientów.

Na start ustaw tylko rua. Tag ruf dodawaj świadomie, jeśli masz kogoś, kto je przeczyta i zabezpieczy skrzynkę.

Kto wysyła raporty i jak często

Raport wysyła serwer, który odebrał pocztę z Twojej domeny, na przykład duży dostawca skrzynek pocztowych. Każdy taki odbiorca przysyła własne raporty, więc im więcej adresatów obsługuje Twoja poczta, tym więcej plików. Według Google zwykle przychodzą raz na dobę, a duże organizacje mogą dostawać setki, a nawet tysiące raportów dziennie. Standard określa okres raportu w polu date_range; typowo to jedna doba UTC. Tag ri pozwala poprosić o inny odstęp (domyślnie 86400 sekund), ale odbiorca nie musi się do tego stosować.

Jak wygląda plik

Raport to mail z załącznikiem. RFC zaleca kompresję gzip, więc plik ma zwykle rozszerzenie .xml.gz. Nazwa ma postać odbiorca!twoja-domena!początek!koniec.xml.gz, gdzie początek i koniec to sekundy od 1 stycznia 1970 (czas uniksowy). W temacie maila stoją pola "Report Domain:", "Submitter:" i "Report-ID:". Rozpakuj plik i otwórz XML w edytorze tekstu albo przeglądarce.

Poniżej skrócony przykład z fikcyjną domeną i adresami z zakresów dokumentacyjnych:

<feedback>
  <report_metadata>
    <org_name>mail.odbiorca.example</org_name>
    <email>[email protected]</email>
    <report_id>1234567890</report_id>
    <date_range><begin>1767225600</begin><end>1767311999</end></date_range>
  </report_metadata>
  <policy_published>
    <domain>twojafirma.pl</domain>
    <adkim>r</adkim><aspf>r</aspf>
    <p>none</p>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.10</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim><spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>twojafirma.pl</header_from></identifiers>
    <auth_results>
      <dkim><domain>twojafirma.pl</domain><selector>poczta2026</selector><result>pass</result></dkim>
      <spf><domain>twojafirma.pl</domain><result>pass</result></spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.77</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim><spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers><header_from>twojafirma.pl</header_from></identifiers>
    <auth_results>
      <spf><domain>newsletter.example</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Najważniejsze pola

  • report_metadata: org_name to odbiorca, który wygenerował raport, a date_range z polami begin i end to okres, którego dotyczą dane.
  • policy_published: polityka, którą odbiorca zobaczył w Twoim DNS w chwili raportu. Sprawdź, czy p zgadza się z tym, co opublikowałeś. Są tu też tryby wyrównania adkim i aspf (r - luźny, s - ścisły).
  • record: jedna grupa wiadomości o tych samych wynikach. W środku jest row, identifiers i auth_results.
  • row: source_ip to adres serwera, który połączył się z odbiorcą, a count to liczba wiadomości w tej grupie.
  • policy_evaluated: wynik DMARC. dkim i spf mają tu wartość pass albo fail i oznaczają sprawdzenie z wyrównaniem do domeny z pola "Od". disposition to działanie odbiorcy: none, quarantine lub reject. Przy p=none będzie none także dla wiadomości, które nie przeszły. Opcjonalny reason tłumaczy odstępstwa, na przykład forwarded albo mailing_list.
  • identifiers: header_from to domena z widocznego pola "Od", czyli ta, którą chroni DMARC.
  • auth_results: surowe wyniki DKIM (domena d=, selektor, wynik) i SPF (domena, wynik), bez oceny wyrównania. Różnica między auth_results a policy_evaluated jest główną wskazówką diagnostyczną: w drugim przykładzie SPF "przeszedł" dla domeny newsletter.example, ale nie jest wyrównany z twojafirma.pl, więc DMARC zapisuje fail.

Jak rozpoznać źródło wiadomości

Dla każdego source_ip zadaj trzy pytania: czyj to adres, jaką domeną podpisano DKIM i jaką domeną przeszedł SPF, oraz czy wynik DMARC to pass.

  • Własny serwer albo dostawca poczty firmowej: adres należy do dostawcy, w auth_results stoi Twoja domena, a policy_evaluated pokazuje pass. Tak ma wyglądać większość raportu.
  • Zapomniana usługa wysyłająca (newsletter, CRM, faktury ze sklepu, system rezerwacji, formularz na stronie): adres obcy, ale znasz usługę po nazwie domeny w auth_results albo po właścicielu adresu IP. Zwykle DKIM jest podpisany domeną dostawcy, SPF przechodzi dla domeny dostawcy, a DMARC daje fail, bo nic nie jest wyrównane z Twoją domeną.
  • Przekazywanie poczty: wiadomość wyszła legalnie, ale ktoś ją przekazał dalej, więc adres należy do serwera przekazującego, a SPF nie pasuje. Jeśli podpis DKIM przetrwał, DMARC nadal przejdzie. Odbiorca może oznaczyć takie przypadki w polu reason (forwarded, mailing_list).
  • Podszywanie: obcy adres, wyniki fail, brak Twojej domeny w auth_results i brak powiązania z żadną usługą, której używasz. Zwykle małe liczby wiadomości z wielu różnych adresów albo jeden duży strumień z jednego.

Właściciela adresu IP znajdziesz w publicznej bazie WHOIS albo odwrotnym wpisem DNS (PTR). Nie jest to dowód, ale wystarcza, by odróżnić znanego dostawcę od przypadkowego hostingu.

Co robić w każdym przypadku

  • Własne źródło z pass: nic. Pilnuj tylko, by nie zniknął podpis DKIM po zmianie dostawcy.
  • Prawowita usługa z fail: włącz w jej panelu podpis DKIM własną domeną i dodaj rekord DNS, który panel pokazuje. Jeśli usługa wysyła z Twojego adresu, dopisz ją też do SPF (poradnik DKIM, poradnik SPF). Wystarczy, że przejdzie jedno z dwóch w wyrównaniu, ale najlepiej oba. Gdy usługa nie pozwala podpisać własną domeną, rozważ jej wymianę, zanim zaostrzysz politykę.
  • Przekazywanie: zwykle nie wymaga zmian po Twojej stronie. Wiadomości, które przeszły dzięki DKIM, są bezpieczne przy ostrzejszej polityce. Przekazane bez podpisu mogą wtedy zostać odrzucone.
  • Podszywanie: nie wyłączaj raportów. Doprowadź prawowite źródła do pass i podnieś politykę, bo to właśnie reject blokuje taką pocztę. Szczegóły: podszywanie pod domenę.
  • Nieznany adres, ale wiadomości wyglądają na prawdziwe: zapytaj zespół, kto ostatnio podłączył nową usługę. Dopóki tego nie wyjaśnisz, nie zakładaj, że to atak.

Kiedy podnieść politykę z none

Kryterium jest jedno: wszystkie prawowite źródła przechodzą DKIM albo SPF w wyrównaniu z domeną z pola "Od", i widać to w raportach z kilku kolejnych okresów obejmujących także rzadkie wysyłki, jak comiesięczne faktury czy sezonowy newsletter. Sztywnej liczby dni nie ma, bo zależy to od tego, jak rzadko wysyłają Twoje systemy. Jeśli w raporcie zostały tylko fail pochodzące z podszywania i przekazań bez podpisu, możesz iść dalej.

  1. Przejdź z p=none na p=quarantine. Wiadomości z fail trafią do spamu. Obserwuj raporty i skargi na zgubioną pocztę.
  2. Gdy po zmianie nie pojawia się nic prawowitego z fail, przejdź na p=reject.
  3. Pamiętaj o subdomenach: polityka sp dotyczy ich osobno, a w raportach każda poddomena wysyłająca poczty ma własne wiersze.

Pełny opis tagów i bezpiecznego wdrożenia: poradnik DMARC. Rekord przygotujesz w generatorze DMARC.

Raporty na adres w innej domenie

Gdy host w rua należy do innej domeny organizacyjnej niż domena z rekordem DMARC (na przykład raporty dla twojafirma.pl idą na adres w firma-raporty.example), odbiorca raportów musi to potwierdzić w swoim DNS. Bez tego potwierdzenia nadawca raportów ignoruje taki adres. Nazwa rekordu w DNS odbiorcy to <twoja-domena>._report._dmarc.<domena-odbiorcy>, typ TXT, wartość v=DMARC1:

twojafirma.pl._report._dmarc.firma-raporty.example. TXT "v=DMARC1"

Taki rekord dodaje właściciel domeny odbiorcy, nie Ty. Odbiorca może też opublikować rekord z symbolem wieloznacznym *._report._dmarc.<domena-odbiorcy>, który zezwala na raporty dla dowolnej domeny. Zewnętrzne serwisy do analizy raportów zwykle robią to same. Brak tego rekordu to częsta przyczyna, dla której po ustawieniu rua nic nie przychodzi.

Dedykowana skrzynka i narzędzia do czytania

  • Załóż osobny adres albo grupę na raporty, nie skrzynkę dyrektora. Wolumen rośnie z ruchem poczty i szybko zalewa zwykłą skrzynkę. Google też zaleca dedykowaną skrzynkę lub grupę.
  • Ustaw regułę, która odkłada raporty do osobnego folderu, i ogranicz do nich dostęp, bo zawierają adresy IP Twoich serwerów i listę usług, których używasz.
  • Ręczne czytanie XML wystarcza przy kilku raportach dziennie. Przy większej liczbie pliki można wczytać do bazy danych albo przekształcić arkuszem XSL w HTML, jak opisuje Google.
  • Osobną kategorią są serwisy do analizy raportów: odbierają raporty na własny adres, łączą je i pokazują źródła w tabeli. Przed wyborem sprawdź, gdzie trzymają dane (raporty mówią, jakich usług używasz) i czy mają politykę prywatności.

Stan DMARC, SPF i DKIM Twojej domeny sprawdzisz w darmowym audycie Audytora, a samego DMARC w narzędziu DMARC. Jeśli poczta z Twojej domeny ląduje w spamie, zobacz poradnik o spamie.

Źródła