Czym jest ARF? Format zgłaszania nadużyć i raporty o niepowodzeniach DMARC (RFC 5965)

Czym jest ARF (Abuse Reporting Format)?

Skrót ARF oznacza „Abuse Reporting Format” (format zgłaszania nadużyć). Jest to znormalizowany, nadający się do odczytu maszynowego format służący do powiadamiania nadawców, że dana wiadomość e-mail spowodowała problem. Został on zdefiniowany w dokumencie RFC 5965 już w 2010 roku, w czasach, gdy zgłoszenia nadużyć miały głównie postać niespójnych wiadomości tekstowych, które administratorzy poczty musieli przeglądać ręcznie. Rozwiązanie to sprawdzało się dobrze, gdy liczba zgłoszeń była niewielka, ale przestało funkcjonować w momencie, gdy dostawcy zaczęli dążyć do automatyzacji procesów. Format ARF zapewnił odbiorcom, dostawcom usług internetowych (ISP) oraz dostawcom skrzynek pocztowych wspólną strukturę, dzięki czemu zdarzenia związane z nadużyciami mogły być zgłaszane właścicielom domen i nadawcom w formacie, który skrypty i parsery mogły z łatwością przetwarzać.

Obecnie ARF występuje w czterech głównych miejscach:

• Raporty o niepowodzeniu weryfikacji DMARC – gdy wiadomość nie przejdzie weryfikacji DMARC, odbiorca może wysłać raport ARF opisujący dokładnie, co poszło nie tak.
• Pętle informacyjne dostawców usług internetowych (ISP) – gdy odbiorca kliknie opcję „to jest spam”, niektórzy dostawcy przekazują tę skargę z powrotem do nadawcy w formacie ARF.
• Zgłoszenia do działu ds. nadużyć – zgłoszenia ręczne dotyczące nadużyć, przekazywane za pośrednictwem zautomatyzowanych systemów obsługi zgłoszeń dotyczących nadużyć.
• Zgłoszenia dotyczące phishingu i oszustw – zgłoszenia, w których wiadomość jest oznaczana jako oszukańcza, a nie tylko jako niechciana.

Warto to wyjaśnić od razu: ten skrót ARF nie ma nic wspólnego z żadnym innym skrótem, o którym być może myślisz. W świecie poczty elektronicznej ARF zawsze oznacza „Abuse Reporting Format” (format zgłaszania nadużyć).

Jak zbudowany jest raport ARF (trzy części)

W dokumencie RFC 5965 plik ARF zdefiniowano jako wiadomość MIME typu „multipart/report”, co oznacza po prostu, że jest to wiadomość e-mail złożona z trzech odrębnych części połączonych ze sobą. Każda z tych części jest przeznaczona dla innego odbiorcy: jedna dla człowieka, jedna dla maszyny, a trzecia stanowi dowód.

Część 1: Podsumowanie w formie czytelnej dla człowieka (text/plain)

Pierwsza część to blok tekstu zwykłego przeznaczony dla osoby przeglądającej skrzynkę odbiorczą. Zazwyczaj zawiera on jedno- lub dwuwierszowe podsumowanie tego, co się wydarzyło, dzięki czemu osoba rzucająca okiem na raport nie musi analizować pól przeznaczonych do odczytu maszynowego, aby zrozumieć ogólny sens.

Część 2: Raport w formacie nadającym się do odczytu maszynowego (message/feedback-report)

To jest sedno raportu i część, którą faktycznie analizują systemy automatyczne. Jest to blok pól typu „klucz-wartość”, takich jak Feedback-Type, Version, User-Agent, Source-IP i Arrival-Date, wraz z polami związanymi z uwierzytelnianiem, np. Auth-Failure. To właśnie w tej części tkwi rzeczywista wartość diagnostyczna raportu.

Część 3: Oryginalna wiadomość (message/rfc822 lub text/rfc822-headers)

W ostatniej części znajduje się albo pełna treść oryginalnej wiadomości, albo tylko jej nagłówki – w zależności od tego, jak nadawca skonfigurował system oraz ile szczegółów odbiorca jest skłonny ujawnić. Ponieważ treść wiadomości może zawierać dane osobowe, wielu odbiorców ogranicza ją wyłącznie do nagłówków lub usuwa niektóre fragmenty przed przekazaniem zgłoszenia dalej.

Rodzaje opinii w ramach ARF

Pole „Typ informacji zwrotnej” wskazuje, z jakim rodzajem raportu masz do czynienia:

W kontekście DMARC w tym miejscu zawsze pojawi się tylko jedna wartość: „auth-failure”. Dodatkowe typy informacji zwrotnych można zarejestrować w IANA, jeśli pojawi się nowy przypadek użycia, ale w przypadku DMARC od samego początku stosowana jest wyłącznie wartość „auth-failure”.

ARF, AFRF, RUF, raporty kryminalistyczne: wyjaśnienie terminologii

Jeśli zapoznałeś się z informacjami na temat raportowania DMARC i zauważyłeś, że terminy ARF, AFRF, RUF oraz „raport kryminalistyczny” są używane niemal zamiennie, to nie są to tylko twoje wyobrażenia. Terminy te rzeczywiście pokrywają się, a oto, jak faktycznie się ze sobą wiążą:

• ARF to podstawowy format danych zdefiniowany w dokumencie RFC 5965. Ma on charakter ogólny i nigdy nie był przeznaczony wyłącznie dla protokołu DMARC.
• AFRF (Authentication Failure Reporting Format) to rozszerzenie zdefiniowane w dokumencie RFC 6591, które dostosowało format ARF specjalnie do zgłaszania błędów uwierzytelniania w systemach SPF, DKIM i DMARC.
• RUF to tag DMARC (ruf=), który umieszcza się w rekordzie DNS, aby zlecić wysyłanie raportów o błędach dotyczących poszczególnych wiadomości na określony adres.
• „Raport kryminalistyczny ” to starsza nazwa tego samego elementu, przejęta z pierwotnej specyfikacji DMARC, RFC 7489. W aktualnym zestawie dokumentów RFC nazywa się go natomiast „raportem o niepowodzeniu”.

Kiedy więc ktoś pyta o „przykład raportu kryminalistycznego”, a ktoś inny nazywa to „raportem o niepowodzeniu DMARC”, mają na myśli to samo. Zmieniła się nazwa wraz z wprowadzeniem standardu, a nie sam mechanizm leżący u jego podstaw.

ARF i DMARC: wyjaśnienie raportów o błędach

Dodając tag „ruf=” do rekordu DNS DMARC, prosisz serwery pocztowe odbierające wiadomości o przesyłanie Ci raportu za każdym razem, gdy wiadomość rzekomo pochodząca z Twojej domeny nie przejdzie weryfikacji DMARC. W przeciwieństwie do raportów zbiorczych, które łączą ruch z całego dnia w jedno podsumowanie w formacie XML, raporty o niepowodzeniach mają być generowane wkrótce po wystąpieniu niepowodzenia i dotyczą pojedynczej wiadomości.

Raport o niepowodzeniu DMARC zawiera informacje, których nie dostarcza raport zbiorczy: wyniki uwierzytelniania dla tej konkretnej wiadomości, szczegóły dotyczące tego, który mechanizm zawiódł, informacje o źródle wysyłki oraz pełną treść wiadomości lub jej nagłówki, dzięki czemu można ustalić, skąd faktycznie pochodziła. To właśnie ten poziom szczegółowości sprawia, że raporty o niepowodzeniach są przydatne do wykrywania prób spoofingu niemal w czasie rzeczywistym – o ile faktycznie je otrzymujesz, co prowadzi nas do następnej sekcji.

Co zmienił dokument RFC 9991 (aktualizacja z 2026 r.)

W maju 2026 roku organizacja IETF opublikowała nowy zestaw dokumentów dotyczących DMARC, które zastępują pierwotny dokument RFC 7489: RFC 9989 (podstawowe zasady DMARC), RFC 9990 (raportowanie zbiorcze/RUA) oraz RFC 9991 (raportowanie błędów/RUF). Dokumenty te łącznie sprawiają, że RFC 7489 traci aktualność. Oto, co faktycznie zmieniło się w przypadku raportów o niepowodzeniach:

• Zmieniła się struktura dokumentów RFC: RFC 9991 obejmuje obecnie zgłaszanie awarii i zastępuje sekcje dotyczące zgłaszania awarii zawarte w RFC 7489. Aktualizuje on również RFC 6591 (AFRF), wprowadzając bardziej precyzyjny zestaw wymaganych pól.
• Sam format danych ARF nie uległ zmianie: podstawowym formatem pozostaje nadal RFC 5965.
• Nowe pole obowiązkowe: „Identyfikacja – zgodność”: lista rozdzielona przecinkami, wskazująca, który mechanizm – DKIM czy SPF – nie wygenerował zgodnego identyfikatora, lub „brak”, jeśli zgodny identyfikator potwierdził autentyczność. Jest to najbardziej przydatne pole dla każdego, kto zapoznaje się z raportem, ponieważ bezpośrednio wskazuje, czy mamy do czynienia z błędną konfiguracją, czy też z jawnym fałszowaniem,
• Nowy typ błędu uwierzytelniania: dmarc: Stosowany konkretnie w sytuacji, gdy żadny dopasowany identyfikator nie uwierzytelnił wiadomości, w odróżnieniu od ogólnego błędu SPF lub DKIM.
• Nowe pola obowiązkowe służące do diagnozowania błędów dopasowania: pola „DKIM-Domain”, „DKIM-Identity” i „DKIM-Selector” są wymagane w przypadku niepowodzenia sprawdzenia dopasowanego podpisu DKIM. Pole „SPF-DNS” jest wymagane w przypadku niepowodzenia sprawdzenia dopasowanego podpisu SPF.
• Nowe pola opcjonalne umożliwiające podanie dodatkowych szczegółów: „Delivery-Result” oraz para „DKIM-Canonicalized-Header/Body”, dostępne w przypadku, gdy odbiorca chce dołączyć więcej informacji diagnostycznych.

Dlaczego dostosowanie tożsamości ma tak duże znaczenie

DMARC tak naprawdę nigdy nie sprawdzał, czy SPF lub DKIM przeszły weryfikację osobno; sprawdza on, czy uwierzytelniony identyfikator jest zgodny z domeną widoczną w polu „From:”. Wiadomość może technicznie przejść weryfikację zarówno SPF, jak i DKIM, a mimo to nie przejść weryfikacji DMARC, jeśli żaden z tych identyfikatorów nie jest zgodny z domeną w polu „From:”. To pole wyraźnie to określa.

RUA kontra RUF: raporty zbiorcze kontra raporty o awariach

Zalecenie (takie samo jak poprzednio)

Zawsze należy skonfigurować parametr „rua=” w rekordzie DMARC. Najwięksi dostawcy usług pocztowych powszechnie obsługują raporty zbiorcze DMARC i zapewniają bieżącą widoczność niezbędną do monitorowania uwierzytelniania. Skonfigurowanie parametru „ruf=” jest opcjonalne i może zapewnić dodatkowe informacje diagnostyczne, jednak wielu odbiorców nie wysyła raportów szczegółowych, dlatego należy traktować je jako uzupełniające źródło danych.

Jak odczytywać raport ARF (przykład z podziałem na poszczególne pola)

Poniżej przedstawiono przykładowy raport o niepowodzeniu DMARC w przypadku fałszowania domeny bezpośredniej, w którym osoba atakująca wysyła wiadomość e-mail podszywającą się pod Twoją domenę, bez poparcia jej ważnym rekordem SPF lub DKIM:

Feedback-Type: auth-failure
Version: 1
User-Agent: MailReceiver/2.1
Auth-Failure: dmarc
Identity-Alignment: dkim, spf
Original-Mail-From: <[email protected]>
Reported-Domain: yourdomain.com
Source-IP: 198.51.100.44
SPF-DNS: v=spf1 include:_spf.yourdomain.com ~all
Authentication-Results: mx.receiver.example;
    dmarc=fail (p=reject) header.from=yourdomain.com;
    spf=fail smtp.mailfrom=spoofed-source.net;
    dkim=none
Arrival-Date: Wed, 22 Jul 2026 09:14:02 +0000

Spacerując po polach, które mają największe znaczenie:

• Typ zgłoszenia: „auth-failure” potwierdza, że jest to zgłoszenie dotyczące błędu uwierzytelnienia, a nie zgłoszenie dotyczące spamu lub nadużycia.
• Błąd uwierzytelnienia: dmarc informuje, że chodzi konkretnie o błąd zgodności z DMARC, czyli typ błędu wprowadzony w RFC 9991.
• Sprawdzanie zgodności tożsamości: dkim, spf to kluczowy wiersz diagnostyczny. Żaden z tych mechanizmów nie wygenerował zgodnego identyfikatora, co w połączeniu z brakiem prawidłowego podpisu DKIM i niepowodzeniem weryfikacji SPF zdecydowanie wskazuje na jawne sfałszowanie, a nie na błędną konfigurację po Twojej stronie.
• Pola „Source-IP” i „Original-Mail-From” wskazują, skąd faktycznie pochodzi wiadomość, co jest przydatne przy tworzeniu list blokowanych adresów lub dalszym badaniu sprawy.
• Funkcja „Reported-Domain” pozwala sprawdzić, która z Twoich domen stała się celem ataku – to przydatna opcja, jeśli zarządzasz kilkoma domenami.
• SPF-DNS pokazuje rekord SPF, na podstawie którego odbiorca przeprowadził weryfikację, co pozwala sprawdzić, czy Twój rekord został poprawnie odczytany.

Gdyby natomiast był to legalny nadawca z zewnętrznej organizacji, którego autoryzacji zapomniałeś dokonać, zazwyczaj zobaczyłbyś, że mechanizm „Identity-Alignment” wskazuje tylko jeden element, a drugi wyświetla status „pass” – co wskazuje raczej na konieczność poprawy konfiguracji niż na atak.

Dlaczego możesz nie otrzymywać raportów o niepowodzeniach

Jeśli skonfigurowałeś opcję ruf=, a raporty w ogóle się nie pojawiają lub napływają bardzo sporadycznie, może to wynikać z kilku uzasadnionych przyczyn:

1. Najwięksi dostawcy zazwyczaj ich nie wysyłają

Gmail i Yahoo, które należą do największych źródeł poczty przychodzącej dla większości domen, zazwyczaj nie generują raportów o niepowodzeniach...

2. Prywatność i redagowanie treści

Raporty o błędach mogą ujawniać dane osobowe zawarte w nagłówkach lub treści wiadomości, co naraża nadawcę na naruszenie przepisów RODO i CCPA. Standard RFC 6590 dotyczy usuwania danych wrażliwych z raportów dotyczących nadużyć, jednak zastosowanie tej procedury może pozbawić raport znacznej części informacji, które sprawiały, że był on przydatny.

3. Należy zweryfikować lokalizacje zewnętrzne

Jeśli adres ruf= wskazuje na lokalizację poza domeną Twojej organizacji, norma RFC 9991 wymaga, aby odbiorca przeprowadził zewnętrzną weryfikację miejsca docelowego (ten sam mechanizm, który norma RFC 9990 określa dla raportów zbiorczych) przed wysłaniem jakichkolwiek danych pod ten adres. Bez odpowiedniego rekordu autoryzacyjnego raporty nie dotrą do adresata.

4. Przewiduje się ograniczenie przepustowości

W dokumencie RFC 9991 zaleca się, aby osoby zgłaszające ograniczały liczbę zgłoszeń o błędach wysyłanych do jednego odbiorcy – po części w celu uniknięcia przeciążenia skrzynki pocztowej, a po części w celu zapobiegania powstawaniu pętli zgłoszeń.

5. Brak awarii, brak zgłoszeń

Jeśli Twoja prawidłowa poczta przechodzi proces uwierzytelniania bez problemów, to w ogóle nie ma powodu, by generować zgłoszenie o niepowodzeniu.

6. Ustawienia tagu „fo”

Tag „fo=” określa dokładnie, kiedy generowany jest raport: wartość „fo=0” (domyślna) powoduje wygenerowanie raportu tylko wtedy, gdy zarówno SPF, jak i DKIM zakończą się niepowodzeniem lub nie są ze sobą zgodne; wartość „fo=1” generuje raport w przypadku niepowodzenia dowolnego z nich; wartość „fo=d” generuje raport konkretnie w przypadku niepowodzenia DKIM, a wartość „fo=s” – konkretnie w przypadku niepowodzenia SPF. Większość domen, które faktycznie chcą uzyskać przydatne informacje diagnostyczne, ustawia wartość „fo=1”.

Pętle informacji zwrotnej w poczcie elektronicznej i ARF

Raporty o błędach nie są jedynym miejscem, w którym pojawia się format ARF. Pętle informacji zwrotnej dostawców usług internetowych (w tympętla skarg serwisu Yahoo oraz programy JMRP/SNDS firmy Microsoft ) wykorzystują dokładnie ten sam format ARF, z tą różnicą, że parametr „Feedback-Type” jest ustawiony na „abuse” zamiast „auth-failure”.

Raporty te są generowane, gdy odbiorca oznaczy wiadomość jako spam, i stanowią one przydatny wczesny sygnał wskazujący na problemy z dostarczalnością, mimo że nie mają one żadnego związku z protokołem DMARC.

Jak skonfigurować funkcję ARF / zgłaszanie awarii dla swojej domeny

Jeśli chcesz zacząć gromadzić zgłoszenia o awariach dotyczących Twojej domeny:

1. Dodaj tag „ruf=” do rekordu DNS DMARC, wskazującego na dedykowaną skrzynkę pocztową lub adres raportowania.

2. Ustaw wartość fo=1, jeśli chcesz otrzymywać powiadomienia o niepowodzeniu weryfikacji SPF lub DKIM, a nie tylko wtedy, gdy obie weryfikacje zakończą się niepowodzeniem.

3. Jeśli adres ruf= znajduje się poza domeną Twojej organizacji, upewnij się, że istnieje rekord autoryzacji miejsca docelowego zewnętrznego, w przeciwnym razie odbiorcy nie będą wysyłać tam żadnych wiadomości.

4. Należy osobno zarejestrować się w programach pętli sprzężenia zwrotnego u głównych dostawców usług internetowych, ponieważ działają one całkowicie poza systemem DMARC.

5. Nie należy zakładać, że uda się je przejrzeć ręcznie w większej ilości. Nawet niewielka liczba wiadomości może generować więcej surowych raportów ARF, niż da się praktycznie przeanalizować ręcznie. Właśnie w tym przypadku zautomatyzowany narzędzie do analizy raportów DMARC znacznie ułatwia sprawę.

Podsumowanie

Raporty o niepowodzeniach stanowią jedno z konkretnych zastosowań mechanizmu ARF w ramach protokołu DMARC. Mechanizm RUF zapewnia szczegółowe informacje dotyczące poszczególnych wiadomości w momencie ich otrzymania, jednak znaczna część odbiorców nie wysyła tych raportów, co sprawia, że raportowanie zbiorcze (RUA) staje się niezawodnym, codziennym źródłem wglądu w sytuację. Ponieważ standard DMARC został obecnie sformalizowany w dokumentach RFC 9989, RFC 9990 i RFC 9991, prawidłowe stosowanie terminologii i szczegółów ma większe znaczenie niż kiedykolwiek, zwłaszcza w przypadku rozwiązywania problemów związanych z rzeczywistym incydentem spoofingu, a nie zwykłą błędną konfiguracją.

Jeśli po raz pierwszy konfigurujesz raportowanie lub chcesz przeglądać te dane bez konieczności samodzielnego analizowania surowych komunikatów ARF, nasze narzędzie DMARC Report Analyzer zostało stworzone właśnie z myślą o tym. Zarejestruj się już dziś, aby skorzystać z bezpłatnej wersji próbnej, i przeglądaj swoje raporty bez zbędnych komplikacji!

Najczęściej zadawane pytania

Czym jest raport o niepowodzeniu DMARC (kryminalistyczny)?

Jest to raport ARF generowany dla każdej wiadomości, gdy e-mail nie przejdzie uwierzytelnienia DMARC. Zawiera on szczegóły dotyczące konkretnej wiadomości, w tym informacje o tym, które mechanizmy uwierzytelniania zakończyły się niepowodzeniem oraz czy wygenerowały one identyfikator zgodny z domeną z pola „From:”. „Raport kryminalistyczny” to starsza nazwa tego samego dokumentu, przejęta z normy RFC 7489.

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

Raporty RUA (zagregowane) to codzienne podsumowania w formacie XML obejmujące całą pocztę otrzymaną z danej domeny, zdefiniowane obecnie w RFC 9990. Raporty RUF (o niepowodzeniach) to generowane niemal w czasie rzeczywistym raporty ARF dotyczące poszczególnych wiadomości, których dostarczenie nie powiodło się, zdefiniowane w RFC 9991. RUA jest powszechnie obsługiwane; RUF jest opcjonalne i wysyłane nieregularnie.

Kto wysyła raporty o niepowodzeniach DMARC?

Tylko niektórzy odbiorcy w ogóle je generują, a najwięksi dostawcy skrzynek pocztowych, tacy jak Gmail i Yahoo, zazwyczaj tego nie robią. Obsługa tej funkcji różni się w zależności od odbiorcy, a kwestie związane z ochroną prywatności, wymogi dotyczące ograniczania częstotliwości wysyłania oraz zasady weryfikacji adresatów określone w RFC 9991 – wszystko to ogranicza częstotliwość, z jaką wiadomości te faktycznie docierają do adresatów.

Jaka jest różnica między ARF a XARF?

ARF (RFC 5965) to format znormalizowany przez IETF, stosowany w raportach o błędach DMARC oraz w pętlach informacji zwrotnej dostawców usług internetowych (ISP). XARF to zastrzeżone rozszerzenie opracowane przez dostawcę, które dodaje dane JSON w celu ułatwienia analizy. Nie jest to standard IETF i nie jest stosowane przez głównych dostawców w raportowaniu DMARC.

Dlaczego nie otrzymuję żadnych raportów o niepowodzeniach DMARC?

Do prawdopodobnych przyczyn należą: wysyłanie raportów do głównych dostawców, którzy ich nie generują; usunięcie danych w celu ochrony prywatności, co powoduje okrojenie raportu; brak zewnętrznego rekordu weryfikacji miejsca docelowego, jeśli adres ruf= znajduje się poza domeną; obowiązkowe ograniczenie częstotliwości po stronie odbiorcy; lub po prostu brak błędów uwierzytelniania, które należałoby zgłosić. Ustawienie tagu fo= również decyduje o tym, kiedy dokładnie generowany jest raport.

• O
• Latest Posts

Ahona Rudra

Ekspert ds. bezpieczeństwa domen i poczty elektronicznej w PowerDMARC

Ahona jest Marketing Managerem w PowerDMARC, z ponad 5-letnim doświadczeniem w pisaniu na tematy związane z cyberbezpieczeństwem, specjalizującym się w bezpieczeństwie domen i poczty elektronicznej. Ahona posiada dyplom ukończenia studiów podyplomowych w zakresie dziennikarstwa i komunikacji, umacniając swoją karierę w sektorze bezpieczeństwa od 2019 roku.

Latest posts by Ahona Rudra (zobacz wszystkie)

• Czym jest ARF? Format zgłaszania nadużyć i raporty o niepowodzeniach DMARC (RFC 5965) – 24 lipca 2026 r.
• Większość instytucji finansowych korzysta z protokołu DMARC. Prawie żadna z nich nie jest jednak chroniona. – 22 lipca 2026 r.
• Czym jest zmęczenie MFA (bombardowanie push)? – 21 lipca 2026 r.