DMARC generuje dwa rodzaje informacji zwrotnej, a to, który z nich otrzymasz, decydują tagi rua i ruf. Raporty zbiorcze (rua) to codzienne podsumowania w formacie XML dotyczące każdego źródła wysyłającego pocztę w imieniu Twojej domeny i stanowią podstawę każdego wdrożenia DMARC. Raporty o błędach, nazywane też raportami forensic (ruf), to próbki pojedynczych wiadomości, które nie przeszły uwierzytelniania, a większość dużych dostawców skrzynek pocztowych już ich nie wysyła ze względu na prywatność. Dla niemal wszystkich domen liczy się tag rua, natomiast ruf jest opcjonalny.
Odczytujemy wyłącznie publiczny DNS. Nic nie zapisujemy, dopóki nie przypiszesz domeny do konta.
Dwa typy raportów w skrócie
DMARC został pierwotnie zdefiniowany w RFC 7489 (2015), a w 2026 roku zaktualizowały go specyfikacje DMARCbis: RFC 9989 dla samego protokołu, RFC 9990 dla raportowania zbiorczego oraz RFC 9991 dla raportowania błędów. W każdej wersji protokół prosi odbierające serwery pocztowe o przesyłanie informacji zwrotnej do właściciela domeny, a informacja ta trafia do niego w dwóch formatach o bardzo różnym przeznaczeniu.
| Cecha | Zbiorczy (rua) | O błędach / forensic (ruf) |
|---|---|---|
| Co zawiera | Liczby wiadomości pogrupowane według wysyłającego IP, z wynikami SPF, DKIM i DMARC | Pojedynczą wiadomość, która nie przeszła weryfikacji: nagłówki, a czasem temat i treść |
| Format | XML, zwykle skompresowany gzip | AFRF, oparty na ARF (RFC 6591 i RFC 5965) |
| Częstotliwość | Raz dziennie od każdego odbiorcy (domyślnie) | Niemal w czasie rzeczywistym, dla każdej wiadomości z błędem |
| Dane osobowe | Brak. Tylko metadane i liczby | Duża ilość. Mogą ujawniać adresy odbiorców i treść |
| Kto je wysyła | Google, Yahoo, Microsoft i większość dużych odbiorców | Bardzo niewielu odbiorców; niemal żaden z dużych |
| Główne zastosowanie | Bieżące monitorowanie i dochodzenie do egzekwowania polityki | Dogłębne diagnozowanie konkretnego błędu |
W skrócie: raporty zbiorcze mówią Ci, co dzieje się z całą Twoją pocztą, a raporty o błędach pokazują dokładnie, jak wyglądała jedna wadliwa wiadomość. Program DMARC budujesz na tych pierwszych i sporadycznie uzupełniasz go tymi drugimi.
Raporty zbiorcze (rua): koń roboczy
Raport zbiorczy to dokument XML, który odbiorca wysyła zwykle raz na 24 godziny, podsumowując całą pocztę, jaką zobaczył jako rzekomo pochodzącą z Twojej domeny. Nie zawiera treści wiadomości. Zamiast tego grupuje wiadomości według źródłowego adresu IP i dla każdej grupy raportuje, ile wiadomości przeszło lub nie przeszło SPF, ile przeszło lub nie przeszło DKIM oraz jak rozstrzygnięta została zgodność (alignment) DMARC.
Ta struktura pozwala Ci zobaczyć cały ekosystem wysyłkowy: własne serwery pocztowe, platformę marketingową, narzędzie helpdesk oraz każdego spoofera lub źle skonfigurowany serwer przekazujący pocztę, który używa Twojej domeny. Każdy rekord niesie też politykę zastosowaną przez odbiorcę, dzięki czemu możesz potwierdzić, czy opublikowana przez Ciebie wartość p= jest faktycznie respektowana. Ponieważ dane to liczby, a nie treść, raporty zbiorcze nie niosą żadnego istotnego ryzyka dla prywatności i właśnie dlatego wysyła je praktycznie każdy duży odbiorca.
Raportowanie zbiorcze włączasz tagiem rua w rekordzie DMARC:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Kilka szczegółów wartych zapamiętania:
- Możesz podać wiele adresów docelowych oddzielonych przecinkami, na przykład
rua=mailto:reports@example.com,mailto:vendor@dmarc-vendor.com. - Opcjonalny tag
riustawia żądany interwał raportowania w sekundach. Domyślnie jest to86400(jeden dzień). Większość odbiorców i tak wysyła raporty codziennie niezależnie od tego, o co poprosisz, więc ustawianierirzadko ma sens. - Surowy XML jest żmudny do czytania ręcznie. Parser lub panel zamienia go w coś użytecznego. Zajrzyj do naszego przewodnika o tym, jak czytać raport zbiorczy DMARC pod adresem /pl/guides/jak-czytac-raport-zbiorczy-dmarc-rua.
Raporty zbiorcze to sposób, w jaki bezpiecznie przechodzisz od p=none do egzekwowania polityki. Obserwujesz, aż każde legalne źródło osiągnie zgodność, poprawiasz te, które jej nie mają, i dopiero wtedy zaostrzasz politykę. Ta droga została opisana w /pl/guides/jak-przejsc-z-dmarc-none-na-reject. Jeśli raporty pokazują pocztę, która nie przechodzi weryfikacji mimo poprawnego uwierzytelnienia nadawcy, przyczyną jest zwykle zgodność, a nie uszkodzony podpis, co jest osobną diagnozą wyjaśnioną w /pl/guides/dmarc-alignment-relaxed-czy-strict.
Raporty o błędach (ruf): szczegółowe, ale rzadko dostarczane
Raport o błędach powstaje w chwili, gdy pojedyncza wiadomość nie przechodzi oceny DMARC u uczestniczącego odbiorcy. Zamiast codziennego podsumowania jest to kopia lub częściowa kopia wadliwego e-maila, wysyłana w formacie AFRF (Authentication Failure Reporting Format, RFC 6591), który rozszerza Abuse Reporting Format (ARF, RFC 5965) o pola specyficzne dla uwierzytelniania.
Atrakcyjność jest oczywista. Zamiast widzieć, że adres IP 203.0.113.5 nie przeszedł DKIM 40 razy, widzisz rzeczywiste nagłówki jednej z tych wiadomości. Możesz odczytać nagłówek From, nagłówek Authentication-Results, ścieżkę wysyłki, a często i Subject. To sprawia, że raporty o błędach są naprawdę przydatne do jednego zadania: diagnozowania, dlaczego konkretne legalne źródło zawodzi, gdy same dane zbiorcze tego nie wyjaśniają.
Raporty o błędach zamawiasz tagiem ruf, a ich kształt określasz tagiem fo (failure options):
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:forensics@example.com; fo=1
Tag fo decyduje o tym, kiedy raport zostanie wygenerowany. Jest ignorowany, o ile nie występuje również tag ruf.
Wartość fo | Kiedy generowany jest raport o błędzie |
|---|---|
0 (domyślnie) | Tylko gdy wszystkie mechanizmy uwierzytelniania nie dają zgodnego pozytywnego wyniku |
1 | Gdy dowolny mechanizm daje coś innego niż zgodny pozytywny wynik |
d | Gdy podpis DKIM nie przechodzi oceny, niezależnie od zgodności |
s | Gdy SPF nie przechodzi oceny, niezależnie od zgodności |
fo=1 to najbardziej informatywne ustawienie, bo oznacza wiadomość nawet wtedy, gdy jeden mechanizm przeszedł pozytywnie, czyli dokładnie w sytuacji, gdy źródło jest skonfigurowane tylko połowicznie. Wartości możesz łączyć dwukropkami, na przykład fo=d:s. Istnieje też tag rf określający format raportu; jego domyślną wartością jest afrf i nie ma praktycznego powodu, aby ją zmieniać.
Dlaczego Google i Yahoo nie wysyłają RUF
Oto haczyk, który zaskakuje ludzi starannie dodających tag ruf, a potem czekających na raporty, które nigdy nie nadchodzą. Duzi dostawcy skrzynek pocztowych ich nie wysyłają.
Powodem jest prywatność. Raport o błędzie może zawierać adres odbiorcy, temat wiadomości i nagłówki ujawniające dane osobowe lub poufne informacje. Przekazywanie tych danych na dowolny adres podany w tagu ruf, potencjalnie w innej jurysdykcji, koliduje z obowiązkami z zakresu ochrony danych, takimi jak RODO. Google nigdy nie wysyłało raportów forensic. Yahoo i Microsoft również nie wysyłają ich do dowolnych domen. Skutek jest taki, że odbiorcy odpowiedzialni za zdecydowaną większość konsumenckich skrzynek nie wnoszą nic do Twojego strumienia ruf.
Niektórzy mniejsi lub firmowi odbiorcy nadal wysyłają raporty o błędach, czasem z zamaskowanymi wrażliwymi polami. Tag ruf nie jest więc bezużyteczny, ale wszelkie dane forensic, które otrzymasz, traktuj jako sporadyczny bonus, nigdy jako podstawę monitorowania. Każdy produkt sprzedawany z obietnicą bogatej widoczności forensic opisuje możliwość, którą rzeczywistość przestała dostarczać lata temu.
Którego powinieneś użyć?
Dla zdecydowanej większości domen odpowiedź jest prosta.
- Zawsze ustawiaj
rua. Raportowanie zbiorcze to rdzeń monitorowania DMARC. Bez niego egzekwujesz politykę na ślepo. Jeśli nie masz jeszcze rekordu DMARC, zacznij od /pl/guides/jak-skonfigurowac-dmarc-krok-po-kroku, a jeśli skan mówi, że go brakuje, zobacz /pl/guides/brak-rekordu-dmarc-jak-naprawic. - Dodawaj
ruftylko wtedy, gdy masz konkretny powód i potrafisz obsłużyć te dane. Dobrym powodem jest aktywne diagnozowanie uporczywego problemu ze zgodnością u odbiorcy, o którym wiesz, że wysyła raporty forensic. Jeśli go dodasz, dodaj teżfo=1, aby wychwytywać częściowe błędy, i upewnij się, że docelowa skrzynka jest zabezpieczona, ponieważ zawartość może obejmować dane osobowe. - Nie polegaj na
rufw kwestii pokrycia. Skoro Google, Yahoo i Microsoft milczą, Twój strumień forensic zawsze będzie ubogi i przechylony w stronę mniejszych nadawców.
Jeśli jesteś na wczesnym etapie wdrożenia i nie masz pewności, jak rygorystyczny być, kompromisy między p=none, quarantine i reject zostały wyjaśnione w /pl/guides/dmarc-jak-przejsc-none-do-reject.
Raportowanie do domeny, której nie kontrolujesz
Oba tagi akceptują adresy docelowe spoza Twojej własnej domeny, na przykład dostawcy przetwarzającego dane DMARC. Aby zapobiec nadużyciom, w których ktoś podaje Twój adres jako miejsce zrzutu raportów, odbiorca sprawdza autoryzację. Jeśli domena docelowa różni się od domeny, na której opublikowany jest rekord DMARC, musisz opublikować rekord TXT pod specjalną nazwą hosta w domenie docelowej, potwierdzający, że przyjmuje ona raporty dla Ciebie:
example.com._report._dmarc.vendor.example IN TXT "v=DMARC1"
Bez tego rekordu odbiorcy nie wyślą raportów na zewnętrzny adres. Dotyczy to zarówno rua, jak i ruf, a DMARCbis utrzymuje ten wymóg jako obowiązkowy również dla adresów docelowych raportów o błędach. To zwykły rekord DNS TXT jak każdy inny; zobacz /pl/guides/co-to-jest-rekord-txt-dns, jeśli potrzebujesz przypomnienia.
Najczęściej zadawane pytania
Czy potrzebuję RUF, skoro mam już RUA?
Nie. Raporty zbiorcze (rua) dają Ci wszystko, co potrzebne do monitorowania źródeł i przejścia do egzekwowania polityki. Raporty o błędach (ruf) mają wartość tylko wtedy, gdy diagnozujesz błąd konkretnej wiadomości, a i wówczas większość dużych dostawców i tak ich nie wyśle.
Dlaczego nie otrzymuję żadnych raportów forensic DMARC?
Ponieważ najwięksi odbiorcy, w tym Google, Yahoo i Microsoft, w ogóle nie wysyłają raportów ruf, powołując się na kwestie prywatności i ochrony danych. O ile mniejszy lub firmowy odbiorca, który nadal obsługuje forensic, nie zobaczy przypadkiem Twojej wadliwej poczty, Twoja skrzynka ruf pozostanie pusta nawet z poprawnym tagiem.
Jaka jest różnica między ustawieniami fo=0 i fo=1?
fo=0, czyli wartość domyślna, generuje raport o błędzie tylko wtedy, gdy każda metoda uwierzytelniania nie daje zgodnego pozytywnego wyniku. fo=1 generuje go, gdy dowolna metoda daje coś innego niż zgodny pozytywny wynik, dzięki czemu wychwytuje częściowe błędy, na przykład gdy SPF przechodzi, a DKIM nie. Oba ustawienia wymagają tagu ruf, aby miały jakikolwiek efekt.
Czy raporty zbiorcze DMARC stanowią ryzyko dla prywatności?
Nie. Raporty zbiorcze zawierają wyłącznie liczby i metadane pogrupowane według wysyłającego adresu IP, bez treści wiadomości, tematów czy adresów odbiorców. To właśnie dlatego wysyła je niemal każdy odbiorca, podczas gdy tak niewielu wysyła raporty forensic z treścią.
Chcesz zobaczyć dokładnie, o co prosi Twój obecny rekord DMARC oraz czy SPF, DKIM i zgodność trzymają się poprawnie? Uruchom bezpłatny skan z SPFWise i w kilka sekund otrzymaj napisane prostym językiem omówienie Twoich tagów rua, ruf i polityki.