Uwierzytelnianie poczty

Jak czytać raporty zbiorcze DMARC

Co zawiera raport zbiorczy DMARC (rua), jak czytać jego XML rekord po rekordzie i jak zamienić te dane na poprawki w konfiguracji nadawców i polityce.

Autor: Exmoor SoftwareZaktualizowano 25 października 2026Opublikowano 24 października 20267 min czytania

Raporty zbiorcze to pętla zwrotna, bez której DMARC trudno wdrożyć. Gdy Twój rekord DMARC zawiera adres rua=, odbiorcy obsługujący raportowanie przysyłają — zwykle raz na dobę — podsumowanie poczty, która dotarła do nich z Twoją domeną w nagłówku From: z jakich serwerów przyszła, ile było wiadomości i czy SPF, DKIM oraz DMARC dały wynik pozytywny.

Od maja 2026 format raportów opisuje RFC 9990, który zastąpił część RFC 7489 dotyczącą raportowania. Ten poradnik wyjaśnia, co jest w raporcie, jak go czytać i co oznaczają typowe wzorce, które w nim zobaczysz.

Jak raporty do Ciebie trafiają

Raporty zamawiasz w rekordzie DMARC:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Każdy odbiorca, który obsługuje raportowanie, wysyła wtedy na ten adres wiadomość raz na okres raportowania — zwykle jedną dobę UTC — i osobno dla każdej domeny polityki DMARC. Raport to plik XML w załączniku, najczęściej skompresowany gzipem. RFC 9990 określa format tematu i nazwy pliku, więc raporty łatwo odfiltrować:

Subject: Report Domain: example.com Submitter: mail.receiver.example Report-ID: <1792627200-example.com@mail.receiver.example>

mail.receiver.example!example.com!1792627200!1792713599.xml.gz

Dwie liczby w nazwie pliku to początek i koniec okresu raportowania w sekundach od 1 stycznia 1970 r. (UTC).

Nie każdy odbiorca wysyła raporty — RFC 9989 jako typowe powody rezygnacji wymienia ograniczone zasoby, lokalną politykę i ochronę prywatności. Traktuj te dane jak dużą próbkę ruchu, a nie pełne zestawienie.

Adres raportów w innej domenie

Jeśli rua wskazuje adres spoza Twojej domeny organizacyjnej — zwykle usługę analizy raportów — odbiorca najpierw sprawdza, czy właściciel adresu zgodził się przyjmować Twoje raporty (RFC 9990, sekcja 4). Dla rua=mailto:dmarc@reports.example.net w domenie example.com domena docelowa musi opublikować:

example.com._report._dmarc.reports.example.net.  IN  TXT  "v=DMARC1"

Usługa przyjmująca raporty dla dowolnych domen może użyć rekordu wieloznacznego: *._report._dmarc.reports.example.net. Bez tego rekordu odbiorcy muszą zignorować adres, a raporty po prostu nie przychodzą — bez żadnego komunikatu o błędzie. Sprawdzanie DMARC weryfikuje to dla każdego adresu w Twoim rekordzie.

Co jest w raporcie

Oto skrócony raport z dwoma rekordami:

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <version>1.0</version>
  <report_metadata>
    <org_name>Example Receiver</org_name>
    <email>dmarc-noreply@mail.receiver.example</email>
    <report_id>1792627200-example.com@mail.receiver.example</report_id>
    <date_range>
      <begin>1792627200</begin>
      <end>1792713599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <discovery_method>treewalk</discovery_method>
    <p>none</p>
    <sp>none</sp>
    <np>none</np>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <testing>n</testing>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.25</source_ip>
      <count>1840</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>example.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <selector>s2026</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
  <record>
    <row>
      <source_ip>198.51.100.40</source_ip>
      <count>312</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>bounces.mailer.example.net</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>mailer.example.net</domain>
        <selector>m1</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounces.mailer.example.net</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Plik ma trzy części.

report_metadata — kto wysłał raport i za jaki okres: org_name, kontaktowy email, unikalny report_id i date_range. Opcjonalny element error opisuje problemy, które odbiorca znalazł w Twoim rekordzie DMARC, np. błędny rua albo dwa rekordy DMARC pod tą samą nazwą.

policy_published — Twój rekord DMARC tak, jak zobaczył go odbiorca: domena polityki, p, sp, np, tryby zgodności, tryb testowy (t) oraz discovery_method: treewalk dla metody z RFC 9989 albo psl dla starszej metody opartej na Public Suffix List. Tagi nieobecne w rekordzie pojawiają się z wartościami domyślnymi.

record — co najmniej jeden na każdy adres IP nadawcy i kombinację wyników:

Element	Co mówi
`row/source_ip`	adres IP serwera, który połączył się z odbiorcą
`row/count`	liczba wiadomości z dokładnie taką kombinacją wyników
`row/policy_evaluated`	wynik DMARC: `disposition` oraz wyniki `dkim` i `spf` po sprawdzeniu zgodności domen
`identifiers/header_from`	domena z nagłówka From — może być subdomeną domeny polityki
`identifiers/envelope_from`	domena nadawcy koperty (MAIL FROM), którą sprawdzał SPF
`auth_results/dkim`	każdy podpis DKIM: `domain` (d=), `selector` (s=), `result`
`auth_results/spf`	`domain`, `scope` (zawsze `mfrom`) i `result` dla SPF

Najważniejsze rozróżnienie

Każdy rekord zawiera wyniki SPF i DKIM dwa razy — i znaczą one co innego:

auth_results to surowe wyniki, bez interpretacji pod kątem DMARC: czy SPF przeszedł dla jakiejś domeny, czy jakiś podpis się zweryfikował.
policy_evaluated mówi, czy te wyniki liczą się dla DMARC. Wartość pass pojawia się tylko wtedy, gdy domena z pozytywnym wynikiem jest zgodna z domeną z nagłówka From.

W drugim rekordzie powyżej SPF przeszedł dla bounces.mailer.example.net, a podpis mailer.example.net się zweryfikował — mimo to oba pola w policy_evaluated mają wartość fail, bo żadna z tych domen nie jest example.com. To usługa, która wysyła w Twoim imieniu, ale nie ma skonfigurowanej Twojej domeny — najczęstsze odkrycie na początku wdrożenia. Szczegółowe zasady opisuje poradnik Zgodność domen w DMARC.

Wiadomość przechodzi DMARC, gdy policy_evaluated/dkim lub policy_evaluated/spf ma wartość pass.

Dyspozycja i powody odstępstw

disposition mówi, co odbiorca zrobił z wiadomościami: none, quarantine lub reject, a także — nowość w RFC 9990 — pass dla wiadomości, które przeszły DMARC przy polityce egzekwującej. Jeśli odbiorca zastosował coś innego niż Twoja polityka, element reason podaje powód:

`reason/type`	Znaczenie
`policy_test_mode`	rekord ma `t=y`, więc zastosowano politykę o stopień łagodniejszą
`mailing_list`	odbiorca uznał, że wiadomość przyszła przez listę dyskusyjną
`trusted_forwarder`	wiadomość przyszła przez zaufany serwer przekazujący
`local_policy`	pierwszeństwo miały własne reguły odbiorcy
`other`	inny powód, opisany w `comment`

Typowe wzorce w raportach

Posortuj rekordy według count i przejdź po kolei przez źródła wysyłki. Odwrotny DNS (PTR) adresu source_ip zwykle podpowiada, czyj to serwer.

Twoje serwery, wszystko przechodzi. Zgodne DKIM i SPF z wynikiem pass. Tak powinno wyglądać każde legalne źródło — i po tym poznasz, że zmiana niczego nie zepsuła.

Usługa, z której korzystasz: surowy pass, zgodność fail. Jak w przykładzie: SPF i DKIM przechodzą dla domen dostawcy. Włącz w usłudze podpisywanie DKIM Twoją domeną (zwykle przez rekordy CNAME, które dostaniesz od dostawcy) oraz, jeśli to możliwe, własną domenę odbić (return-path), np. bounce.example.com. Samo dopisanie include: dostawcy do rekordu SPF nic nie da, dopóki usługa używa własnego nadawcy koperty.

Zapomniany nadawca. Znany Ci adres IP — system fakturowy, sklep internetowy, skaner — z SPF fail lub softfail i bez podpisu DKIM. Dopisz go do SPF, włącz DKIM w tym systemie albo kieruj jego pocztę przez usługę, która podpisuje wiadomości. Nadawcy wysyłający raz w miesiącu pojawią się dopiero po pełnym miesiącu, więc nie skracaj etapu p=none.

Przekazywanie poczty (forwarding). source_ip należy do innego dostawcy skrzynek albo uczelni, envelope_from to Twoja domena, SPF nie przechodzi, ale DKIM jest zgodny i ma wynik pass. DMARC przechodzi dzięki DKIM — nie ma czego poprawiać. Jeśli DKIM też zawodzi, bo lista dyskusyjna zmieniła temat lub dopisała stopkę, możesz zobaczyć powód mailing_list. Po swojej stronie tego nie naprawisz — dlatego DKIM na całej Twojej poczcie jest tak ważny.

Nieznane źródła, brak zgodności. Niewielkie liczby z obcych adresów IP, brak podpisu DKIM albo podpis niezwiązanej domeny, SPF fail. To zwykle podszywanie się pod Twoją domenę — dokładnie to, co zatrzyma p=quarantine lub p=reject.

SPF permerror lub temperror dla wszystkich Twoich źródeł. Rekord SPF jest uszkodzony, często przez przekroczenie limitu 10 zapytań DNS. Użyj narzędzia Sprawdzanie SPF.

Raporty w starszym formacie

Odbiorcy, którzy wciąż stosują RFC 7489, wysyłają raporty według jego schematu: z inną przestrzenią nazw XML, bez np, testing i discovery_method, z elementem pct i tylko z dyspozycjami none, quarantine i reject. Wśród powodów odstępstw mają forwarded i sampled_out, których RFC 9990 już nie zna. Przez jakiś czas będziesz dostawać oba formaty — upewnij się, że narzędzie, które przetwarza raporty, obsługuje jeden i drugi. Pozostałe różnice między specyfikacjami podsumowuje poradnik DMARC wg RFC 9989: co się zmieniło i co zrobić.

Prywatność i bezpieczne przetwarzanie

Według RFC 9990 raporty zbiorcze nie zawierają danych osobowych, takich jak pojedyncze adresy e-mail czy treść wiadomości. Opisują jednak Twoje przepływy poczty, a RFC 9989 zauważa, że w małej organizacji raport może zdradzić wrażliwe informacje biznesowe. Jeśli przekazujesz raporty zewnętrznemu podmiotowi, sprawdź, czy pozwalają na to Twoje wewnętrzne zasady i umowy.

Traktuj przychodzące raporty jak niezaufane dane:

Raport to skompresowany plik XML z internetu. Używaj parsera odpornego na bomby dekompresyjne i bomby XML (RFC 9990, sekcja 8.1).
Raporty można sfałszować, by wpłynąć na Twoje decyzje (sekcja 8.2). Wiadomości z raportami same muszą przechodzić DMARC, więc te, które nie przechodzą, możesz odrzucać.
Odbiorca wysyłający raport ponownie musi użyć tej samej nazwy pliku i tego samego report_id — po nich usuwaj duplikaty.

Narzędzia do przetwarzania raportów

Czytanie XML-a ręcznie sprawdza się przy domenie testowej, nie przy codziennym ruchu; RFC 9989 zaleca przetwarzanie maszynowe. Typowe możliwości:

Jednorazowy podgląd w przeglądarce. Analizator raportów DMARC czyta jeden raport (XML, ZIP lub GZIP), grupuje rekordy według źródeł wysyłki i nie zapisuje pliku. Z bezpłatnym kontem możesz przechowywać raporty potwierdzonej domeny i śledzić trend z 90 dni.
Usługa analizy raportów DMARC. Ustawiasz rua na jej adres (usługa publikuje rekord autoryzacji) i dostajesz rekordy pogrupowane według źródeł. Sprawdź, gdzie i jak długo przechowuje dane.
Parser open source, który czyta skrzynkę, rozpakowuje załączniki i zapisuje rekordy w bazie danych lub silniku wyszukiwania.
Własny skrypt. Wyciągnij załączniki, przetwórz każdy record i sumuj count według source_ip, header_from oraz wyników z policy_evaluated.

Niezależnie od wyboru załóż dla rua osobną skrzynkę, żeby raporty nie zalewały niczyjej poczty.

Co dalej

Sprawdź, czy rekord zamawia raporty i czy zewnętrzne adresy są autoryzowane — Sprawdzanie DMARC.
Otwórz pierwsze otrzymane raporty w analizatorze raportów DMARC, aby zobaczyć, które źródła nie przechodzą.
Popraw każde legalne źródło, które ma fail w policy_evaluated — zobacz Zgodność domen w DMARC.
Gdy wśród niepowodzeń zostanie już tylko podszywanie się, przejdź na p=quarantine, a potem p=reject, jak opisuje poradnik Jak poprawnie skonfigurować DMARC.