Jak interpretować raporty DMARC: Kompletny przewodnik po wskaźnikach RUA i RUF

Opublikowałeś rekord DMARC, ustawiłeś parametr „rua=” na swój adres e-mail, a teraz raporty trafiają do Twojej skrzynki odbiorczej w postaci skompresowanych plików XML. Są one trudne do odczytania, pochodzą od firm, o których nigdy nie słyszałeś, i nie jest jasne, co – jeśli w ogóle – powinieneś z nimi zrobić.

Ten przewodnik rozwiązuje ten problem. Wyjaśnia, co zawierają raporty DMARC, jak odczytywać kod XML pole po polu, co właściwie oznaczają skróty RUA i RUF, a co najważniejsze – jakie działania należy podjąć, gdy nadawca przejdzie test, nie przejdzie go lub pojawi się nieoczekiwanie. Jeśli właśnie masz przed sobą swój pierwszy raport, zacznij od góry i przechodź w dół.

W tym wpisie zakładamy, że masz już utworzony rekord. Jeśli nie, najpierw opublikuj rekord DMARC, a następnie wróć tutaj, aby zinterpretować generowane przez niego raporty.

Czym są raporty DMARC?

Raporty DMARC to codzienne podsumowania wysyłane przez serwery pocztowe odbierające wiadomości na adres podany w tagu „rua=”. Każdy z nich zawiera listę wszystkich adresów IP, z których w danym okresie sprawozdawczym wysłano wiadomości e-mail podające się za pochodzące z Twojej domeny, oraz informację, czy SPF oraz DKIM zdały, czy nie zdały dla każdego źródła. Stanowią one podstawowe narzędzie do monitorowania stanu uwierzytelniania poczty elektronicznej w Twojej domenie. Dają one jedyny realny wgląd w to, kto wysyła wiadomości w Twoim imieniu — niezależnie od tego, czy są to nadawcy autoryzowani, czy nie.

Kto wysyła raporty DMARC?

Każdy serwer pocztowy, który odbiera wiadomości e-mail z Twojej domeny, wyśle raport, jeśli masz skonfigurowaną opcję rua=. Oczywiście dotyczy to Google, Microsoftu i Yahoo. Dotyczy to również mniejszych dostawców usług e-mailowych (ESP), korporacyjnych bram pocztowych, systemów uniwersyteckich oraz międzynarodowych dostawców, z których usług korzystają Twoi odbiorcy. 

Otrzymywanie zgłoszeń od organizacji, których nie znasz jest zjawiskiem normalnym i oczekiwanym. Może to po prostu oznaczać, że jakiś serwer przetworzył wiadomość, która wydawała się pochodzić z Państwa domeny. Należy jednak pamiętać, że duża liczba wiadomości w tych raportach pochodzących z adresu IP, nad którym nie mają Państwo kontroli, nadal wymaga zbadania, ponieważ jest to oznaka spoofingu.

Liczba raportów otrzymywanych dziennie zależy od tego, ile różnych serwerów pocztowych odebrało Twoją wiadomość. Jeśli wysyłasz wiadomości tylko do kilku odbiorców, możesz otrzymywać dwa lub trzy raporty dziennie. Nadawcy wysyłający duże ilości wiadomości mogą otrzymywać ich setki. Żadna z tych wartości sama w sobie nie wskazuje na problem. Liczba raportów odzwierciedla zróżnicowanie odbiorców, a nie stan Twojej domeny.

Kiedy pojawiają się raporty?

Większość dostawców wysyła jeden zbiorczy raport co 24 godziny, a raporty zazwyczaj docierają w ciągu 24–48 godzin od zdarzeń związanych z pocztą elektroniczną, które opisują. Od każdej organizacji generującej raporty otrzymujesz osobny raport (Google i Microsoft wysyłają swoje raporty niezależnie od siebie), więc korespondencja wysłana w ciągu jednego dnia do różnych odbiorców generuje kilka raportów obejmujących ten sam okres.

Raporty są wysyłane jako załączniki skompresowane w formacie .zip lub .gz przez automatyczne systemy wysyłające. Niektóre programy pocztowe oznaczają je jako podejrzane, więc jeśli oczekujesz raportów, a ich nie widzisz, sprawdź folder ze spamem lub wiadomościami niechcianymi, zanim uznasz, że coś nie działa.

Rodzaje raportów DMARC: RUA a RUF

Istnieją dwa rodzaje raportów DMARC. W przypadku niemal wszystkich domen wystarczy skupić się wyłącznie na pierwszym z nich.

Raporty zbiorcze (RUA): Standard

Raporty zbiorcze DMARC to 24-godzinne podsumowanie całego ruchu e-mailowego z Twojej domeny, który został przetworzony przez dany serwer pocztowy. Są one dostarczane w postaci skompresowanego pliku XML i pokazują adresy IP nadawców, liczbę wiadomości, wyniki weryfikacji SPF (pozytywne/negatywne), wyniki weryfikacji DKIM (pozytywne/negatywne) oraz dyspozycję DMARC (działanie podjęte przez odbiorcę). Co najważniejsze, nie zawierają one treści wiadomości e-mail ani danych osobowych, a jedynie metadane uwierzytelniające, dzięki czemu można je bezpiecznie odbierać i przechowywać w każdym regionie. Niniejszy przewodnik skupia się właśnie na tym raporcie. 

Raporty o błędach (RUF): Błędy dotyczące poszczególnych wiadomości

Raporty o niepowodzeniach DMARC (wcześniej nazywane raportami kryminalistycznymi) to powiadomienia wysyłane niemal w czasie rzeczywistym, informujące o tym, że konkretna wiadomość nie przeszła procesu uwierzytelniania. RFC 9991 (maj 2026 r.) formalnie ustandaryzował ten typ raportu. Ponieważ raport o niepowodzeniu może zawierać nagłówki wiadomości, a czasami także treść (dane, które mogą zawierać dane osobowe), główni dostawcy, w tym Google, Microsoft i Yahoo, w ogóle ich nie wysyłają. Włącz opcję ruf= tylko wtedy, gdy dysponujesz dedykowanym procesorem do przetwarzania tych danych, i nie oczekuj raportów od dużych dostawców usług pocztowych. 

RUA kontra RUF 

Co zawiera raport DMARC: pole po polu

Raport zbiorczy DMARC to plik XML podzielony na trzy główne sekcje: metadane raportu (kto go wysłał i kiedy), opublikowana polityka (Twój rekord DMARC widziany z perspektywy odbiorcy) oraz rekordy, po jednym wierszu na źródło wysyłki. Zrozum te trzy bloki, a reszta to już szczegóły.

Section 1: Report Metadata (<report_metadata>)

W tym bloku podano, kto przesłał raport oraz jaki okres obejmuje.

• org_name: organizacja sporządzająca raport (np. google.com).
• e-mail: adres kontaktowy nadawcy raportu.
• report_id: unikalny identyfikator tego konkretnego raportu.
• date_range (początek + koniec): przedział sprawozdawczy, podany w postaci znaczników czasu epoki; należy go przekonwertować na datę czytelna dla człowieka.

Co należy tutaj sprawdzić: upewnij się, że raport obejmuje oczekiwany okres.

Section 2: Policy Published (<policy_published>)

Poniżej przedstawiono rekord DMARC dokładnie w takiej postaci, w jakiej został on oceniony przez odbiorcę w momencie przetwarzania.

• domena: domena, do której odnosi się ta polityka.
• adkim / aspf: tryby dopasowania DKIM i SPF (łagodny lub ścisły).
• p: wybrana opcja (brak, kwarantanna lub odrzucenie).
• sp: zasady dotyczące subdomen, o ile zostały ustawione.
• pct: przestarzałe pole procentowe. Należy pamiętać, że pole pct zostało usunięte zgodnie z RFC 9989 (maj 2026 r.); nadal może ono pojawiać się w starszych raportach, ale w nowych rekordach nie powinno się go już umieszczać.

Co należy tutaj sprawdzić: upewnij się, że opublikowana polityka jest zgodna z Twoimi zamierzeniami. Jeśli tak nie jest, może to oznaczać, że zmiany w DNS nie zostały jeszcze w pełni zaktualizowane.

Section 3: Records (<record>): The Important Part

Each <record> represents all the emails from one source IP during the reporting period. This is where you spend most of your time.

• source_ip: adres IP nadawcy. Sprawdź tę wartość, aby ustalić, kto wysłał wiadomość.
• liczba: ile wiadomości nadeszło z tego adresu IP.
• policy_evaluated/disposition: podjęte działanie (brak, kwarantanna lub odrzucenie).
• policy_evaluated/dkim oraz policy_evaluated/spf: wynik zgodny ze standardem DMARC (pozytywny/negatywny) dla każdego z nich.
• identyfikatory/header_from: widoczna domena z pola „From:”, którą chroni protokół DMARC.
• auth_results/spf: domena SPF i wynik.
• auth_results/dkim: domena DKIM, selektor i wynik.

Co należy tutaj sprawdzić: czy wszystkie rozpoznawane adresy IP przechodzą weryfikację DMARC oraz czy są tam jakieś adresy IP, których nie rozpoznajesz?

Przykład raportu DMARC w formacie XML

Oto realistyczny, zanonimizowany raport zbiorczy przedstawiający trzy źródła wysyłki: jedno z prawidłowym adresem nadawcy, jedno z nieprawidłowym adresem nadawcy oraz jeden nieznany adres IP. Każde pole zawiera komentarz napisany prostym językiem. 

<?xml version="1.0" encoding="UTF-8"?>
<feedback>

  <!-- ===== SECTION 1: WHO SENT THIS REPORT AND WHEN ===== -->
  <report_metadata>
    <org_name>google.com</org_name>             <!-- The provider that generated this report -->
    <email>[email protected]</email>  <!-- Where the report came from -->
    <report_id>1234567890123456789</report_id>  <!-- Unique ID for this report -->
    <date_range>
      <begin>1718928000</begin>                 <!-- Start of window (epoch) = 2024-06-21 00:00 UTC -->
      <end>1719014400</end>                      <!-- End of window (epoch)   = 2024-06-22 00:00 UTC -->
    </date_range>
  </report_metadata>

  <!-- ===== SECTION 2: YOUR POLICY AS THE RECEIVER SAW IT ===== -->
  <policy_published>
    <domain>example.com</domain>                <!-- The domain this report is about -->
    <adkim>r</adkim>                             <!-- DKIM alignment: r = relaxed -->
    <aspf>r</aspf>                               <!-- SPF alignment:  r = relaxed -->
    <p>none</p>                                  <!-- Your policy: monitoring only -->
    <sp>none</sp>                                <!-- Subdomain policy -->
  </policy_published>

  <!-- ===== SECTION 3: ONE RECORD PER SENDING SOURCE ===== -->

  <!-- RECORD 1: Legitimate sender (Google). All passing, no action needed. -->
  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>      <!-- A Google sending IP -->
      <count>150</count>                         <!-- 150 messages from this IP -->
      <policy_evaluated>
        <disposition>none</disposition>          <!-- No action taken -->
        <dkim>pass</dkim>                         <!-- DKIM aligned & passed -->
        <spf>pass</spf>                           <!-- SPF aligned & passed -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Visible From: domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>google</selector>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 2: Known ESP. SPF passes but DKIM is not configured.
       Action: ask the provider to enable DKIM signing for your domain. -->
  <record>
    <row>
      <source_ip>198.51.100.42</source_ip>      <!-- Your email service provider -->
      <count>45</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>                         <!-- DKIM not aligned / not signed -->
        <spf>pass</spf>                           <!-- SPF passes -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
      <dkim>
        <domain>esp-vendor.example.org</domain>  <!-- Signed by vendor domain, not yours -->
        <selector>s1</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

  <!-- RECORD 3: Unknown sender. Both DKIM and SPF fail.
       Low volume here = monitor. High volume would signal active spoofing. -->
  <record>
    <row>
      <source_ip>203.0.113.17</source_ip>       <!-- Unrecognized IP -->
      <count>8</count>
      <policy_evaluated>
        <disposition>none</disposition>          <!-- Not blocked yet (p=none) -->
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>      <!-- Claiming to be your domain -->
    </identifiers>
    <auth_results>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>example.com</domain>
        <selector>unknown</selector>
        <result>fail</result>
      </dkim>
    </auth_results>
  </record>

</feedback>

Jak analizować raporty DMARC: krok po kroku

Krok 1: Otwórz i rozpakuj raport

Zgłoszenia są przesyłane jako załączniki do wiadomości e-mail o temacie w rodzaju: „Zgłoszenie domeny: twojadomena.com”, „Nadawca: google.com”, „Identyfikator zgłoszenia: …”. Zapisz załącznik, rozpakuj go (wbudowane w systemie operacyjnym narzędzia do rozpakowywania plików bez problemu obsługują formaty .zip i .gz), a następnie otwórz uzyskany plik .xml w dowolnym edytorze tekstowym. 

Jeśli chcesz zrobić coś więcej niż tylko rzucić okiem, prześlij plik do naszego narzędzie DMARC Report Analyzer zamiast analizować surowy kod XML, aby dogłębnie przeanalizować dane w formacie czytelnym dla człowieka.

Krok 2: Określenie organizacji sprawozdawczej

Check <org_name> in the metadata so you know whose view you are looking at. Google’s report covers your Gmail recipients; Microsoft’s covers Outlook and Hotmail. You will get separate reports from each, so never assume one report is the whole picture.

Krok 3: Sprawdź opublikowaną politykę

Confirm <p>, <sp>, <adkim>, and <aspf> match what you intended to publish. If they do not, your record may have been propagated incorrectly or edited. Verify the live record with our DMARC Checker.

Krok 4: Sprawdź każdy rekord (źródło wysyłki)

For each <record>: look up the <source_ip> with a reverse DNS or IP lookup to identify the service (for example, 209.85.220.41 resolves to Google). Check the <count>. High volume from an IP you do not recognize is a red flag. Then check the disposition and the DKIM/SPF results. A legitimate sender should show both dkim=pass and spf=pass; a failure on either for a sender you recognize means something needs fixing.

Krok 5: Podziel każde źródło na kategorie

Przyporządkuj każde źródło do jednej z trzech kategorii:

1. Zgodne z przepisami i dopuszczalne: nie trzeba nic robić.
2. Zgodne z przepisami, ale nieskuteczne: wymaga poprawek (zobacz poniższy plan działania).
3. Nieznane i wysyłające: potencjalne fałszowanie adresów; monitoruj liczbę takich wiadomości i rozważ zaostrzenie zasad, jeśli ich liczba jest wysoka.

Analiza raportów DMARC na dużą skalę: narzędzia i automatyzacja

Gdy codziennie napływają raporty od wielu dostawców, ręczne analizowanie plików XML staje się niepraktyczne. Domena wysyłająca wiadomości do użytkowników Gmaila, Outlooka i Yahoo otrzymuje co najmniej trzy raporty dziennie, każdego dnia, a ręczne przeglądanie każdego z nich nie da się utrzymać dłużej niż przez pierwszy tydzień. Nie bez powodu automatyczne parsowanie jest standardem branżowym.

Jeśli chcesz przeprowadzić szybką, jednorazową weryfikację, bezpłatne narzędzia, takie jak DMARC Report Analyzer firmy PowerDMARC, pozwalają na przesłanie pliku XML w formacie surowym i wyświetlenie jego zawartości w formacie czytelnym dla człowieka bez konieczności otwierania edytora tekstu.

W przypadku ciągłego monitorowania na dużą skalę specjalna platforma zajmuje się wszystkim automatycznie: ujednolica raporty od wszystkich dostawców w jednym widoku, powiadamia o pojawieniu się nieznanego nadawcy, przechowuje historię oraz generuje pliki eksportowe gotowe do audytu. 

W przypadku użytkowników PowerDMARC nasz panel raportowy obsługuje wszystkie te funkcje zarówno w środowiskach z jedną, jak i z wieloma domenami, dzięki czemu analiza odbywa się na bieżąco, a nie tylko wtedy, gdy użytkownik o tym pamięta.

• Wszystkie raporty w jednym miejscu: Zamiast dziesiątek oddzielnych plików XML rozrzuconych po skrzynce odbiorczej, wszystkie raporty od wszystkich dostawców są ujednolicone w jednym widoku.
• Zasięg obejmujący wszystkie domeny: W przypadku zespołów zarządzających więcej niż jedną domeną konsolidacja ta obejmuje całe portfolio, dzięki czemu jeden pulpit nawigacyjny obejmuje wszystkie domeny, za które jesteś odpowiedzialny.
• Dane historyczne, a nie tylko migawki: Dzięki archiwum historii możesz śledzić wskaźnik pomyślnych dostarczeń z tygodnia na tydzień, upewnić się, że naprawa nieprawidłowo działającego nadawcy faktycznie przyniosła oczekiwane rezultaty, oraz wykryć powolny wzrost podejrzanej aktywności, zanim przerodzi się ona w incydent.
• Filtrowanie i wyszukiwanie: Wybierz konkretne źródło wysyłki lub typ błędu zamiast ręcznie przeglądać każdy rekord.
• Powiadomienia o nowych nadawcach: Otrzymuj powiadomienia o pojawieniu się nowych, nieautoryzowanych nadawców, dzięki czemu nie musisz czekać na kolejną ręczną weryfikację, aby ich wykryć.
• Eksport gotowy do audytu: Twórz raporty przeznaczone do eksportu na potrzeby kontroli zgodności oraz sprawozdawczości dla interesariuszy.

Co zrobić z raportami DMARC

Zapoznanie się z raportem to pierwszy krok. Dopiero podjęcie odpowiednich działań zapewni rzeczywistą ochronę Twojej domeny. Za każdym razem, gdy przeglądasz nową partię raportów, wykonaj poniższe czynności w podanej kolejności.

Napraw problem z prawidłowymi nadawcami, których wiadomości nie docierają

Jeśli nadawca, którego rozpoznajesz (Twój dostawca usług e-mailowych, system CRM, dział pomocy technicznej lub platforma do wysyłania newsletterów), wyświetla komunikat „dkim=fail” lub „spf=fail”:

1. W przypadku błędów SPF: dodaj zakres adresów IP nadawcy lub mechanizm „include:” do swojego rekordu SPF, a następnie sprawdź ponownie za pomocą naszego narzędzia do sprawdzania SPF.
2. W przypadku błędów DKIM: poproś dostawcę o włączenie niestandardowego podpisywania DKIM dla Twojej domeny i opublikuj klucz, który od niego otrzymasz, a następnie zweryfikuj go za pomocą naszego narzędziem do sprawdzania DKIM.

Rozpoznawanie i monitorowanie nieznanych nadawców

Adres IP, którego nie rozpoznajesz jako źródła wiadomości wysyłanych z Twojej domeny, może oznaczać: narzędzie wdrożone przez zespół bez poinformowania o tym nikogo, legalną usługę przekierowywania lub aktywną próbę spoofingu. Niewielka liczba wiadomości z nieznanego adresu IP jest zjawiskiem powszechnym i wiąże się z niskim ryzykiem. Duża liczba wiadomości z nieznanego adresu IP stanowi wyraźną oznakę spoofingu i właśnie w takich przypadkach zaostrzenie zasad w celu poddania wiadomości kwarantannie lub ich odrzucenia skutecznie powstrzymuje nadużycia.

Śledź swój wskaźnik zdawalności na przestrzeni czasu

Wskaźnik pozytywnych wyników DMARC to odsetek wiadomości, które pomyślnie przeszły uwierzytelnianie DMARC. Przy ustawieniu p=none nie ma to wpływu na dostarczanie wiadomości, ale wskazuje, w jakim stopniu jesteś gotowy do egzekwowania zasad. Przed zaostrzeniem polityki postaraj się osiągnąć i utrzymać wskaźnik pozytywnych wyników powyżej 95% dla wszystkich legalnych nadawców. Monitoruj ten wskaźnik co tydzień przez co najmniej dwa do czterech tygodni, zamiast reagować na wyniki z pojedynczego dnia.

Zdecyduj, kiedy rozszerzyć zakres swojej polisy

Przejdź do stanu p=kwarantanna, gdy spełnione są wszystkie trzy warunki gotowości:

1. Wszyscy znani, wiarygodni nadawcy mają wynik „pass” w testach DMARC.
2. W Twoich raportach nie pojawiają się żadni nieoczekiwani nadawcy wysyłający duże ilości wiadomości.
3. Wskaźnik zdawalności utrzymuje się niezmiennie na poziomie powyżej 95%.

Przejdź do poziomu p=reject, gdy te same warunki utrzymają się przez jeden do dwóch tygodni w okresie kwarantanny i nie pojawią się żadne nieoczekiwane zdarzenia. Pełny przebieg polityki został omówiony w naszym przewodniku po konfiguracji DMARC.

PowerDMARC automatyzuje cały ten proces analizy. Nasza platforma śledzi wskaźniki akceptacji, identyfikuje nadawców po nazwie, a nie po adresie IP, i powiadamia Cię natychmiast po pojawieniu się nowego, nieautoryzowanego nadawcy, dzięki czemu decyzja o dopuszczeniu jest podejmowana za Ciebie, a nie na podstawie surowych danych XML.

Dlaczego nie otrzymuję raportów DMARC?

Jeśli opublikowałeś rekord z ustawionym parametrem „rua=”, ale nie otrzymano żadnych zgłoszeń, przyczyną jest prawie zawsze jedna z tych sześciu przyczyn.

Problem nr 1: W Twoim rekordzie DMARC brakuje tagu „rua=”. Jest to najczęstsza przyczyna. Brak tagu „rua=” oznacza, że wyraźnie zrezygnowałeś z otrzymywania raportów. Rozwiązanie: dodaj rua=mailto:[email protected] do swojego rekordu i sprawdź poprawność za pomocą naszego narzędzia DMARC Checker.

Problem nr 2: Nieprawidłowy lub nieistniejący adres e-mail. Literówka, nieistniejąca skrzynka odbiorcza lub przepełniona skrzynka spowodują, że raporty nie zostaną dostarczone. Rozwiązanie: sprawdź, czy adres rua= faktycznie może odbierać wiadomości, wysyłając na niego wiadomość testową.

Problem nr 3: Zewnętrzny adres docelowy raportów nie jest autoryzowany. Jeśli parametr rua= wskazuje adres w domenie innej niż domena określona w rekordzie DMARC (Twoja domena to company.com, ale parametr rua= wskazuje adres [email protected]), domena zewnętrzna musi opublikować rekord autoryzacyjny pod adresem _report._dmarc.reportingservice.com zawierający v=DMARC1. Bez tego raporty są odrzucane. Większość platform DMARC zajmuje się tym automatycznie.

Problem nr 4: Opublikowałeś nowy wpis, ale dane DNS jeszcze się nie rozprzestrzeniły. Raporty zaczynają napływać w ciągu 24–48 godzin od momentu globalnego uruchomienia wpisu, więc aby rozwiązać ten problem, sprawdź rozprzestrzenianie się zmian za pomocą naszego narzędzia do sprawdzania propagacji DNS.

Problem nr 5: Raporty trafiają do folderu ze spamem. Raporty są wysyłane jako skompresowane załączniki przez automatyczne systemy i często są filtrowane. Aby to naprawić, sprawdź folder ze spamem i dodaj nadawców raportów do białej listy ([email protected], [email protected]).

Numer 6: Nie wysłano jeszcze żadnej wiadomości e-mail. Raporty są generowane tylko wtedy, gdy Twoja domena faktycznie wysłała wiadomość, która dotarła do dostawcy. Jeśli od momentu opublikowania rekordu nie wysłano żadnej wiadomości, nie ma jeszcze nic do zgłoszenia.

RFC 9990: Standard sprawozdania zbiorczego z 2026 r.

Od maja 2026 r., RFC 9990 reguluje format i sposób dostarczania zbiorczych raportów DMARC, przejmując rolę związaną z raportowaniem, która wcześniej była określona w RFC 7489. Schemat XML jest kompatybilny wstecznie (istniejące parsery i raporty, które już otrzymujesz, nadal będą działać), a główną zmianą jest formalna standaryzacja formatu raportowania i częstotliwości codziennego przesyłania raportów. 

Aby zapoznać się ze szczegółowym zestawieniem najnowszych aktualizacji, zapraszamy do zapoznania się z naszym przewodnik dotyczący standardów DMARC RFC 9989/9990/9991 . 

Najczęściej zadawane pytania

Czym jest raport DMARC?

Raport DMARC to codzienny plik XML wysyłany przez serwery pocztowe odbierające wiadomości na adres podany w tagu `rua=`, zawierający zestawienie wszystkich adresów IP, z których wysłano wiadomości e-mail z Twojej domeny, oraz informacje o tym, czy dla każdego z nich weryfikacja SPF i DKIM zakończyła się powodzeniem, czy też nie. Dostawcy tacy jak Google, Microsoft i Yahoo generują te raporty za każdym razem, gdy otrzymują wiadomość e-mail rzekomo pochodzącą z Twojej domeny. Stanowią one podstawowe narzędzie do monitorowania stanu uwierzytelniania poczty elektronicznej w Twojej domenie.

Jaka jest różnica między RUA a RUF w protokole DMARC?

Raporty RUA (zagregowane) to codzienne podsumowania w formacie XML obejmujące całą aktywność pocztową z Twojej domeny. Raporty RUF (o błędach) to powiadomienia o błędach dotyczące poszczególnych wiadomości, które mogą zawierać dane z nagłówków poszczególnych wiadomości e-mail. Większość głównych dostawców, w tym Google, Microsoft i Yahoo, nie wysyła już raportów o błędach ze względu na ograniczenia związane z ochroną prywatności, dlatego raporty zagregowane są bardziej powszechne i obsługiwane na całym świecie.

Jak często wysyłane są raporty DMARC?

Większość dostawców wysyła jedno zbiorcze sprawozdanie co 24 godziny. Ponieważ każdy serwer pocztowy odbierający wiadomości wysyła własne sprawozdanie, otrzymujesz po jednym sprawozdaniu od każdego dostawcy, którego użytkownicy otrzymali Twoją wiadomość, więc domena wysyłająca wiadomości do użytkowników Gmaila, Outlooka i Yahoo powinna spodziewać się co najmniej trzech sprawozdań dziennie.

Jak odczytać raport DMARC w formacie XML?

Raport XML DMARC składa się z trzech głównych sekcji: report_metadata (nadawca i okres), policy_published (oceniony rekord DMARC) oraz records (po jednym wpisie dla każdego adresu IP nadawcy wraz z wynikami weryfikacji SPF i DKIM). Praktyczny przewodnik po tym formacie znajdziesz w przykładzie kodu XML zamieszczonym wcześniej w niniejszym przewodniku. Jednak większość zespołów IT korzysta z automatycznego narzędzia analitycznego, które identyfikuje nadawców na podstawie nazwy, zamiast analizować surowy kod XML.

Dlaczego otrzymuję raporty DMARC od organizacji, których nie znam?

Każdy serwer pocztowy, który odbiera wiadomości e-mail rzekomo pochodzące z Twojej domeny, wysyła zgłoszenie, jeśli masz skonfigurowaną opcję `rua=`. Dotyczy to zarówno małych dostawców usług internetowych, korporacyjnych bram pocztowych, jak i międzynarodowych dostawców, z których usług korzystają Twoi odbiorcy – nie tylko Google i Microsoft. Otrzymywanie zgłoszeń od nieznanych organizacji jest zjawiskiem normalnym i oznacza po prostu, że serwery te przetworzyły wiadomości, które wydawały się pochodzić z Twojej domeny.

• O
• Latest Posts

Maitham Al Lawati

Ekspert ds. cyberbezpieczeństwa, dyrektor generalny w PowerDMARC

Maitham jest przedsiębiorcą technologicznym, ekspertem ds. cyberbezpieczeństwa, dyrektorem generalnym i założycielem PowerDMARC z ponad 15-letnim doświadczeniem w branży. Maitham posiada tytuł Global MBA Uniwersytetu w Manchesterze oraz różne certyfikaty zawodowe, w tym CISSP, CISM, CRISC i ISC2 CCSP.

Najnowsze posty autorstwa Maitham Al Lawati (zobacz wszystkie)

• Jak skonfigurować DMARC: Kompletny przewodnik konfiguracji krok po kroku (2026) - 20 czerwca 2026 r.
• Jak interpretować raporty DMARC: Kompletny przewodnik po wskaźnikach RUA i RUF – 10 czerwca 2026 r.
• Czym jest DMARC? Definicja, zasada działania i znaczenie – 28 kwietnia 2026 r.