Raporty o niepowodzeniach DMARC (RUF): czym są, jak działają i jak je bezpiecznie włączyć

Opublikowanie rekordu DMARC jest ważnym krokiem w kierunku ochrony Twojej domeny przed spoofingiem, phishingiem i nieautoryzowanym wykorzystaniem poczty elektronicznej. Jednak prawdziwa wartość operacyjna wynika z raportów, które pokazują, czy legalni nadawcy przechodzą uwierzytelnianie wiadomości e-mail oraz gdzie występują niepowodzenia.

Wiele zespołów w przedsiębiorstwach korzysta z zbiorczych raportów DMARC w celu monitorowania ogólnego stanu domeny, jednak podsumowania te mogą nie zawierać wystarczających szczegółów do reagowania na incydenty, prowadzenia dochodzeń dotyczących zgodności z przepisami lub rozwiązywania złożonych problemów związanych z zewnętrznymi nadawcami. Raporty o niepowodzeniach DMARC (RUF) dostarczają kontekst na poziomie poszczególnych wiadomości, co może pomóc zespołom ds. bezpieczeństwa i IT w szybszym zidentyfikowaniu źródła niepowodzeń uwierzytelniania. 

W niniejszym przewodniku wyjaśniono, czym są raporty RUF, czym różnią się od danych zbiorczych oraz jak skutecznie z nich korzystać.

Czym jest raport o niepowodzeniu DMARC?

Raport o niepowodzeniu DMARC (zwany również raportem o niepowodzeniu lub raportem RUF) to szczegółowe powiadomienie wysyłane niemal w czasie rzeczywistym przez serwery pocztowe odbierające wiadomości, gdy wiadomość nie przejdzie uwierzytelnienia DMARC. Zawiera on informacje diagnostyczne na poziomie wiadomości, w tym wyniki uwierzytelnienia, źródło wysyłki oraz nagłówki wiadomości, dzięki czemu właściciele domen mogą zbadać potencjalne próby sfałszowania tożsamości oraz rozwiązywać problemy związane z uwierzytelnianiem wiadomości e-mail.

Uwaga terminologiczna: Terminy „raport o niepowodzeniu DMARC”, „raport o niepowodzeniu DMARC” oraz „raport RUF” odnoszą się do tego samego typu raportu. Podstawowym formatem jest AFRF (Authentication Failure Reporting Format), zdefiniowany w RFC 6591, który stanowi rozszerzenie formatu ARF (Abuse Reporting Format, RFC 5965) specyficzne dla DMARC. Terminy te są często używane zamiennie w branży.

• Kto je generuje? Serwery odbierające pocztę, dostawcy usług internetowych (ISP), korporacyjne bramy pocztowe oraz urządzenia zabezpieczające, ale tylko wtedy, gdy obsługują protokół RUF i wykryją niepowodzenie uwierzytelnienia. Właściciele domen żądają raportów za pomocą tagu ruf=, jednak to odbiorcy decydują o ich wysłaniu na podstawie własnych zasad ochrony prywatności i konfiguracji.
• Gdzie trafia ta wiadomość? Jest dostarczana na adres e-mail podany w tagu ruf= w rekordzie DNS DMARC.
• W jakim formacie są one generowane? W przeciwieństwie do raportów zbiorczych, które są dostarczane w postaci plików XML, raporty RUF wykorzystują format AFRF (Authentication Failure Reporting Format) w celu przedstawienia szczegółowych danych dotyczących niepowodzeń uwierzytelniania w strukturze bardziej przystępnej dla człowieka.

Jakie informacje zawierają raporty o niepowodzeniach DMARC?

Ponieważ RUF raporty DMARC są przeznaczone do szczegółowej diagnostyki problemów, zawierają one konkretne metadane dotyczące wiadomości, której dostarczenie nie powiodło się, których nie znajdziesz w raportach zbiorczych. Typowy raport RUF zawiera:

• Adres IP nadawcy: dokładny adres IP, z którego podjęto próbę wysłania wiadomości
• Adresy „From” i „Return-Path”: nagłówek „From” oraz nadawca koperty
• Temat wiadomości: rzeczywisty temat wiadomości e-mail, której wysłanie nie powiodło się
• Wyniki uwierzytelnienia: szczegółowe informacje wyjaśniające, dlaczego SPF lub DKIM nie powiodły się oraz czy zostało osiągnięte zostało osiągnięte
• Nagłówki wiadomości e-mail: pełne nagłówki informacji zwrotnej zawarte w wiadomości
• Czas odbioru: znacznik czasu wskazujący moment, w którym wiadomość dotarła do serwera odbiorczego
• Zastosowana polityka DMARC: polityka, która została zastosowana do wiadomości – „brak”, „kwarantanna” lub „odrzucenie”
• Wynik dostarczenia: czy wiadomość została dostarczona, umieszczona w kwarantannie czy odrzucona
• Dane umożliwiające identyfikację osoby (PII): ponieważ raporty te mogą zawierać tematy wiadomości i adresy odbiorców, często zawierają one dane osobowe

Informacja dotycząca ochrony prywatności

Ze względu na obecność danych osobowych wielu głównych dostawców usług pocztowych zrezygnowało z wysyłania raportów RUF w celu ochrony prywatności użytkowników. PowerDMARC rozwiązuje ten problem, obsługując szyfrowania PGP dla raportów RUF, dzięki czemu poufne dane pozostają zaszyfrowane i dostępne wyłącznie dla Ciebie. Niektórzy odbiorcy, którzy wysyłają raporty RUF, najpierw usuwają poufne fragmenty treści lub tematu wiadomości, co wyjaśnia, dlaczego niektóre raporty o niepowodzeniach są puste lub zawierają ciągi znaków [REDACTED].

Przykład raportu o niepowodzeniu DMARC: jak interpretować poszczególne pola

Aby zrozumieć, co dzieje się „pod maską”, należy przeanalizować surowe dane. Gdy wysłanie wiadomości e-mail kończy się niepowodzeniem, odbiorca generuje raport w formacie AFRF. Poniżej przedstawiono przykładowy przykład wykorzystujący zarezerwowane domeny i zakresy adresów IP zgodnie z RFC 5737.

Interpretacja poszczególnych pól

Porada praktyczna

Podczas analizowania raportu RUF należy po kolei zadać sobie cztery pytania. Czy adres IP nadawcy znajduje się na liście zatwierdzonych nadawców? Czy wystąpił błąd SPF, DKIM, czy też obu? Czy pole „Original-Mail-From” jest zgodne z Twoją domeną? Czy wygląda to na skrajny przypadek przekierowania lub przekazywanie wiadomości z listy mailingowej? Jeśli nie jesteś w stanie udzielić na te pytania jednoznacznej odpowiedzi, przekaż raport zespołowi ds. bezpieczeństwa w celu zbadania sprawy.

Jak wygląda ten wpis w Twoim systemie DNS

Aby otrzymywać te raporty, rekord DMARC musi zawierać tag ruf=. Typowy przykład:

Jeśli wysyłasz raporty do domeny innej niż Twoja własna, domena docelowa musi opublikować rekord DNS upoważniający ją do odbierania raportów w Twoim imieniu. Omówienie tagów:

• v=DMARC1: standardowy znacznik wersji identyfikujący protokół DMARC
• p=none: tryb monitorowania; komunikaty nie są odrzucane ani umieszczane w kwarantannie, a odbiorcy są proszeni o zgłaszanie wyników uwierzytelniania
• rua=: miejsce docelowe codziennych raportów zbiorczych podsumowujących całą aktywność związaną z uwierzytelnianiem
• ruf=: miejsce docelowe dla zgłoszeń o awariach; należy przekierować je na bezpieczną, dedykowaną platformę przetwarzania, a nie do ogólnej skrzynki odbiorczej
• fo=1: nakazuje odbiorcom wygenerowanie raportu, jeśli weryfikacja SPF lub DKIM zakończy się niepowodzeniem

Raport zbiorczy DMARC a raport o niepowodzeniach: RUA a RUF

Oba typy raportów są konfigurowane w ramach tego samego rekordu DMARC, ale służą one różnym celom. Raport RUA zapewnia wgląd w dane z całej domeny w ujęciu czasowym; raport RUF zawiera szczegółowe informacje na poziomie poszczególnych wiadomości dotyczące konkretnych błędów. Aby uzyskać bardziej szczegółowe zestawienie, zapoznaj się z tym porównaniem raportów raportów RUA i RUF.

Jak włączyć raporty o niepowodzeniach DMARC w rekordzie DNS

Aby włączyć funkcję RUF, należy zaktualizować istniejący rekord TXT DMARC w systemie DNS. Wykonaj poniższe czynności.

1. Wejdź na stronę swojego dostawcy usług DNS. Zaloguj się do konsoli zarządzania DNS swojej domeny.
2. Znajdź swój rekord TXT DMARC. Znajdź rekord TXT opublikowany pod adresem _dmarc.twojadomena.com.
3. Dodaj adres docelowy RUF. Wprowadź adres w formacie ruf=mailto:, na który mają być wysyłane raporty o błędach, jeśli jest to obsługiwane.
4. Skonfiguruj opcje postępowania w przypadku awarii. Dodaj tag fo=, aby określić, kiedy mają być generowane raporty; kwestia ta zostanie omówiona w następnej sekcji.
5. Należy stosować bezpieczne przetwarzanie. Przekierowuj raporty na bezpieczną platformę, taką jak PowerDMARC, zamiast do zwykłej skrzynki odbiorczej.
6. Zapisz i poczekaj na propagację. Propagacja zmian w systemie DNS na całym świecie może potrwać do 48 godzin.

Wysyłanie raportów RUF do standardowej skrzynki odbiorczej powoduje nadmiar informacji i zwiększa ryzyko ujawnienia danych. Platforma raportowa centralizuje dane DMARC, przekształca surowe dane uwierzytelniające w przejrzyste pulpity nawigacyjne oraz koreluje niepowodzenia z wynikami zgodności SPF, DKIM i DMARC, dzięki czemu zespoły mogą szybciej identyfikować problemy.

Wyjaśnienie działania DMARC dla tagu: Kiedy generowane są raporty o niepowodzeniach

Tag „fo” jest elementem rekordu DMARC, który określa, kiedy serwer odbierający ma wygenerować raport o niepowodzeniu.

Większość specjalistów ds. bezpieczeństwa stosuje ustawienie fo=1, ponieważ zapewnia ono maksymalną przejrzystość w zakresie niepowodzeń uwierzytelniania. Należy jednak pamiętać, że komunikaty z ustawieniem fo=1 powinny być kierowane na dedykowaną, bezpieczną platformę przetwarzania, a nie do skrzynki odbiorczej użytkownika. Bez automatyzacji ilość generowanych raportów może stać się niemożliwa do opanowania, a wysyłanie ich do niezabezpieczonej skrzynki odbiorczej zwiększa ryzyko ujawnienia poufnych danych zawartych w wiadomościach. A Niepowodzenie DKIM może wywołać lawinę raportów, które warto odizolować od wspólnej skrzynki pocztowej.

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

Jeśli włączono funkcję RUF, ale miejsce docelowe raportów jest puste, nie musi to oznaczać błędu konfiguracji. Istnieje kilka typowych przyczyn, które mogą powodować brak otrzymywanych raportów.

Właśnie dlatego w sprawozdaniu RUA raporty RUA są uznawane za wiarygodne źródło informacji na temat ogólnego stanu domeny, podczas gdy raporty RUF służą jako uzupełniające narzędzie analityczne w przypadku konkretnych scenariuszy awarii.

Kwestie dotyczące prywatności i bezpieczeństwa

Ponieważ raporty RUF mogą zawierać tematy wiadomości, adresy odbiorców, nagłówki, a czasami także treść wiadomości, należy obchodzić się z nimi ostrożnie w ramach przepisów dotyczących ochrony prywatności, takich jak RODO oraz CCPA. W przypadku organizacji działających w sektorach podlegających regulacjom, takich jak finanse, opieka zdrowotna, edukacja, handel detaliczny i administracja publiczna, dane dotyczące awarii powinny być przetwarzane za pomocą bezpiecznych systemów z kontrolą dostępu, które zapewniają zgodność z wymogami dotyczącymi prywatności i zgodności z przepisami.

Dla organizacji dążących do spełnienia wymagań Google, Microsoftu, standardu PCI DSS, RODO lub rządowych wymogów dotyczących uwierzytelniania poczty elektronicznej kluczowe znaczenie mają bezpieczne procesy raportowania. Dane RUF mogą stanowić wsparcie w prowadzeniu dochodzeń, jednak całościowy wgląd w dane DMARC, postępy w egzekwowaniu zasad oraz zarządzanie uwierzytelnionymi nadawcami pozostają niezbędne dla zapewnienia długoterminowej gotowości do zachowania zgodności z przepisami.

Najlepsze praktyki

• Korzystaj z dedykowanej, bezpiecznej platformy do zgłaszania incydentów.
• Włącz szyfrowanie PGP: model „przynieś własny klucz” oznacza, że tylko uprawnieni użytkownicy posiadający klucz prywatny mogą przeglądać poufną treść raportów o awariach.
• Należy ograniczyć dostęp do danych dotyczących awarii w zależności od roli i potrzeb operacyjnych.
• Należy określić zasady przechowywania danych dotyczących przechowywanych danych RUF zgodnie z obowiązującymi przepisami dotyczącymi ochrony prywatności.
• W jurysdykcjach, w których obowiązują rygorystyczne wymogi dotyczące ochrony danych, przed włączeniem funkcji RUF należy przeprowadzić analizę prawną.

Jak korzystać z raportów RUF w celu wykrywania fałszowania adresów i usuwania usterek

Gdy zaczniesz otrzymywać dane dotyczące niepowodzeń, traktuj każdy raport jako sygnał wymagający zbadania, a nie jako ostateczny werdykt. Przed podjęciem decyzji dotyczących działań naprawczych zweryfikuj ustalenia w oparciu o zatwierdzone wykazy nadawców, zbiorcze trendy DMARC, logi bramy pocztowej oraz dane wywiadowcze dotyczące zagrożeń. Pięć scenariuszy obejmuje większość sytuacji, które ujawniają dane dotyczące niepowodzeń.

Wykrywanie fałszowania domen

Jeśli w raporcie o awarii wykryto nieznany adres IP źródłowy, w którym w polu „From” nagłówka wiadomości użyto Twojej domeny, potraktuj to jako sygnał wymagający zbadania. Najpierw zweryfikuj ten adres źródłowy, porównując go z listami zatwierdzonych nadawców, zbiorczymi trendami, logami bram sieciowych oraz danymi wywiadowczymi dotyczącymi zagrożeń. Jeśli potwierdzisz, że adres ten jest nieautoryzowany, można go dodać do list blokowanych, a także powiadomić o tym centrum operacji bezpieczeństwa.

Naprawianie uzasadnionych błędów

Czasami legalne wiadomości e-mail nie docierają do adresatów, ponieważ dane nadawcy zewnętrznego nie są poprawnie skonfigurowane, selektor DKIM jest nieprawidłowo skonfigurowany lub rekord SPF domeny stał się zbyt złożony. Platforma raportująca pomaga zespołom zidentyfikować te awarie w odpowiednim kontekście oraz uprościć zarządzanie rekordami SPF dzięki hostowanym rekordom SPF i automatycznemu upraszczaniu, co zmniejsza ryzyko problemów z dostarczaniem wiadomości w miarę dodawania nowych narzędzi SaaS.

Diagnozowanie usterek związanych z przekazywaniem danych

Przekierowywanie wiadomości e-mail często powoduje naruszenie SPF, ponieważ adres IP serwera przekierowującego nie figuruje w rekordzie SPF pierwotnego nadawcy. Jeśli raport RUF wskazuje na niepowodzenia związane z rozpoznaną usługą przekierowującą lub serwerem przekaźnikowym listy mailingowej, przyczyną jest prawdopodobnie naruszenie SPF, a nie próba sfałszowania adresu. W takich przypadkach należy sprawdzić, czy DKIM nadal przechodzi pomyślnie, ponieważ podpisy DKIM zazwyczaj pozostają nienaruszone po przekierowaniu, oraz czy polityka DMARC może zostać spełniona wyłącznie poprzez dostosowanie DKIM.

Wykrywanie „cieniowego IT” i nieautoryzowanych nadawców

Raporty RUF mogą ujawniać źródła wysyłki, których zespoły IT nie autoryzowały lub o których nie wiedzą — na przykład zespół marketingowy, który podłączył nowe narzędzie do automatyzacji bez aktualizacji rekordu SPF. Jeśli raport o niepowodzeniu wskazuje na błąd pochodzący z adresu IP należącego do niedawno wdrożonej platformy SaaS, jest to raczej luka konfiguracyjna niż atak. Należy dodać tę usługę do listy autoryzowanych nadawców i odpowiednio zaktualizować rekord DMARC.

Przebieg postępowania wyjaśniającego

1. Zidentyfikuj adres IP źródłowy w raporcie RUF.
2. Sprawdź uprawnienia: czy ten adres IP jest powiązany z narzędziem lub usługą, z której korzysta Twoja organizacja?
3. Sprawdź zgodność: przejrzyj wyniki SPF i DKIM w polu „Authentication-Results”.
4. Sprawdź, czy ma to związek z przekazywaniem wiadomości lub listami mailingowymi: oceń, czy błąd SPF wynika z działania pośredniego serwera przekaźnikowego.
5. Sklasyfikuj ryzyko: autoryzowany nadawca z nieprawidłową konfiguracją, nieautoryzowany nadawca, artefakt wynikający z przekazywania wiadomości lub źródło z zakresu „shadow IT”.
6. Działania naprawcze: jeśli autoryzacja została przyznana, ale nie powiodła się, należy skorygować zgodność SPF lub DKIM. Jeśli autoryzacja nie została przyznana, należy zastosować politykę DMARC z ustawieniem p=quarantine lub p=reject w celu zapewnienia ochrony.
7. Monitorowanie za pomocą raportów zbiorczych: należy sprawdzić, czy działania naprawcze są skuteczne, analizując kolejne raporty RUA.

Kiedy warto włączyć RUF, a kiedy lepiej tego nie robić

Funkcja RUF nie jest domyślnie włączona dla każdej domeny. To, czy warto ją włączyć, zależy od tego, kto będzie czytał raporty i do czego będą one służyć. Istnieją trzy sytuacje, w których warto ją włączyć, oraz dwie, w których lepiej tego nie robić.

• Włącz tę funkcję, gdy dysponujesz zespołem ds. bezpieczeństwa, który zajmie się analizą danych. Analitycy SOC i specjaliści ds. reagowania na incydenty wykorzystują szczegółowe informacje na poziomie komunikatów do badania potwierdzonych przypadków spoofingu, co stanowi najistotniejsze zastosowanie tego raportu.
• Należy włączyć tę opcję podczas aktywnego rozwiązywania problemów. Gdy nadawca zewnętrzny ciągle ponosi niepowodzenia, a dane zbiorcze nie są wystarczająco szczegółowe, informacje o niepowodzeniu dotyczące konkretnego adresu IP oraz wyników dopasowania skracają czas diagnozy.
• Warto wdrożyć to rozwiązanie w środowiskach podlegających regulacjom, w których zapewniono już bezpieczne przetwarzanie danych. Jeśli już korzystasz z szyfrowanego systemu raportowania z kontrolą dostępu, dodatkowa szczegółowość analizy wiąże się z niewielkim ryzykiem marginalnym.
• Zastanów się nad tym, jeśli raporty miałyby trafiać do wspólnej skrzynki odbiorczej. Bez szyfrowania i kontroli dostępu otrzymywanie raportów zawierających dane osobowe stwarza ryzyko naruszenia zgodności z przepisami, które przeważa nad korzyściami.
• Należy to ponownie rozważyć, jeśli nikt nie jest odpowiedzialny za wyniki. Duża liczba danych (fo=1) bez analityka, który mógłby je przeanalizować, staje się szumem, a zbiorcze raporty już obejmują monitorowanie kondycji domeny.

W przypadku większości zespołów domyślnym podejściem jest priorytetowe traktowanie danych zbiorczych. Należy uruchomić RUA w celu oceny stanu domeny i postępów w egzekwowaniu zasad, a następnie celowo włączyć RUF, gdy dochodzenie lub uporczywa awaria nadawcy wymaga dogłębnej analizy na poziomie wiadomości, kierując ją na platformę zaprojektowaną do obsługi danych wrażliwych.

Ograniczenia raportów o niepowodzeniach DMARC

Zrozumienie, czego raporty RUF nie są w stanie zapewnić, jest równie ważne jak wiedza o tym, co potrafią. Należy traktować raporty o niepowodzeniach jako uzupełniające narzędzie analityczne, a nie jako główny sygnał decydujący o działaniach w ramach programu DMARC.

• Ograniczone wsparcie ze strony dostawców: główni dostawcy usług poczty elektronicznej, w tym Gmail i Microsoft 365, zazwyczaj nie wysyłają raportów RUF ze względu na kwestie prywatności, więc zakres wykrywania awarii jest z natury rzeczy niekompletny
• Dane zredagowane: odbiorcy, którzy wysyłają raporty, mogą zredagować tematy wiadomości, treści wiadomości lub adresy odbiorców przed dostarczeniem wiadomości
• Fałszywe alarmy wynikające z przekazywania wiadomości: serwery przekaźnikowe list mailingowych i usługi przekazywania wiadomości często powodują błędy SPF, które wyglądają jak błędy uwierzytelniania, ale nie są próbami spoofingu
• Liczba raportów i poziom szumu: przy wartości fo=1 nadawcy wysyłający wiadomości z dużą częstotliwością mogą otrzymywać niemożliwą do opanowania liczbę zgłoszeń, z których wiele odzwierciedla raczej oczekiwane zachowanie związane z przekazywaniem wiadomości niż rzeczywiste zagrożenia
• Nie zastępuje RUA: raporty zbiorcze pozostają miarodajnym źródłem informacji o stanie uwierzytelniania w całej domenie, dlatego RUF powinien raczej uzupełniać bieżące monitorowanie RUA, a nie je zastępować
• Ryzyko ujawnienia danych osobowych (PII): bez szyfrowania i kontroli dostępu samo otrzymywanie raportów RUF może wiązać się z obowiązkami wynikającymi z RODO, CCPA i podobnych regulacji

W jaki sposób dostawcy usług zarządzanych (MSP) mogą wykorzystywać raporty o niepowodzeniach DMARC w domenach klientów

Dla dostawców usług zarządzanych (MSP) i dostawców usług bezpieczeństwa zarządzanego (MSSP) raporty o awariach stanowią cenne źródło informacji, gdy klient zgłasza brakujące wiadomości, podejrzenie spoofingu lub niewyjaśnione błędy uwierzytelniania. Jednak zarządzanie surowymi raportami RUF na dużą skalę jest trudne. Mogą one zawierać poufne dane klientów, napływać jednocześnie z wielu domen i wymagać korelacji z innymi sygnałami uwierzytelniającymi, aby można było podjąć odpowiednie działania.

• Wgląd w wiele domen: agregowanie raportów z dziesiątek lub setek domen klientów bez scentralizowanej platformy wymaga znacznego nakładu pracy ręcznej
• Postępowanie z danymi wrażliwymi: Raporty RUF z domen klientów mogą zawierać dane osobowe klientów końcowych, co nakłada na dostawcę usług zarządzanych (MSP) obowiązki w zakresie zgodności z przepisami
• Zarządzanie liczbą zgłoszeń: domeny klientów o dużym natężeniu ruchu mogą generować ogromną liczbę raportów o awariach, które przeciążają procesy pracy techników
• Dostęp oparty na rolach: technicy powinni mieć wgląd wyłącznie w raporty dotyczące przypisanych im domen klientów

Scentralizowana platforma, taka jak PowerDMARC dla dostawców usług zarządzanych (MSP) i dostawców usług bezpieczeństwa zarządzanego (MSSP) pomaga dostawcom usług w bezpiecznym przetwarzaniu danych RUF, oddzielaniu domen klientów, skróceniu czasu poświęcanego na ręczne badanie problemów oraz zapewnieniu technikom szybkiego wglądu w to, który nadawca, adres IP lub mechanizm uwierzytelniania spowodował awarię, bez niepotrzebnego ujawniania poufnych danych.

W jaki sposób PowerDMARC pomaga w radzeniu sobie z raportami o niepowodzeniach DMARC

PowerDMARC bezpiecznie przetwarza dane dotyczące niepowodzeń DMARC i przekształca surowe informacje o błędach uwierzytelniania w przydatne wnioski. Zamiast wysyłać poufne raporty RUF na standardową skrzynkę odbiorczą, zespoły przeglądają raporty na scentralizowanym pulpicie nawigacyjnym, chronią poufne dane za pomocą szyfrowania PGP oraz korelują niepowodzenia z wynikami zgodności SPF, DKIM i DMARC.

• Pełna przejrzystość: szybsza identyfikacja źródeł, z których wysyłka zakończyła się niepowodzeniem, wyników uwierzytelniania oraz podejrzanych adresów IP we wszystkich Twoich domenach
• Bezpieczne przetwarzanie: Szyfrowanie PGP w modelu „bring-your-own-key” ogranicza ryzyko ujawnienia poufnych danych dotyczących awarii, dzięki czemu nawet PowerDMARC nie może odczytać zaszyfrowanej treści
• Scentralizowane zarządzanie: monitoruj DMARC, SPF, DKIM, BIMI, MTA-STS i TLS-RPT z jednej platformy bez konieczności przełączania się między narzędziami lub analizowania surowego kodu XML
• Szybsze usuwanie problemów: rozwiązywanie problemów związanych z błędami u wiarygodnych nadawców i próbami spoofingu bez konieczności ręcznego analizowania raportów AFRF, dzięki hostowanemu SPF i automatycznemu spłaszczaniu, co pozwala ograniczyć liczbę nieudanych dostaw w miarę dodawania nowych narzędzi SaaS
• Gotowość w zakresie zgodności z przepisami: ścieżki audytu, kontrola dostępu oparta na rolach oraz zgodność z wymaganiami Google, Microsoft, PCI DSS, RODO oraz rządowymi wymogami dotyczącymi nadawców

Najczęściej zadawane pytania

Czym dokładnie jest raport o niepowodzeniu DMARC?

Raport o niepowodzeniu generowany niemal w czasie rzeczywistym, gdy pojedyncza wiadomość e-mail nie przejdzie kontroli uwierzytelniającej określonej w polityce DMARC i opcjach postępowania w przypadku niepowodzenia. Zawiera on szczegółowe informacje na poziomie pojedynczej wiadomości, w przeciwieństwie do raportów zbiorczych, które podsumowują aktywność dotyczącą wszystkich wiadomości z ostatnich 24 godzin.

Czym różni się RUF od RUA?

RUA dostarcza codzienne podsumowanie dla całej domeny w formacie XML, obejmujące wszystkie komunikaty. RUF działa niemal w czasie rzeczywistym w odniesieniu do poszczególnych komunikatów, których wysłanie nie powiodło się, w formacie AFRF (RFC 6591, rozszerzającym format ARF z RFC 5965), zawiera szczegółowe informacje dotyczące konkretnych komunikatów i może zawierać dane osobowe (PII). RUA takich danych nie zawiera.

Jak włączyć te raporty?

Dodaj adres ruf=mailto:[email protected] do rekordu TXT DMARC pod adresem _dmarc.twojadomena.com. Dodaj parametr fo=1, aby otrzymywać raporty w przypadku niepowodzenia weryfikacji SPF lub DKIM. Kieruj raporty na bezpieczną platformę zamiast do standardowej skrzynki odbiorczej.

Skonfigurowałem RUF, ale nic się nie dzieje. Czy to nie działa?

Niekoniecznie. Wielu dostawców nie wysyła raportów RUF ze względu na ochronę prywatności, a podczas przesyłania wiadomości nie są generowane żadne raporty. Jeśli otrzymujesz zbiorcze raporty RUA, Twoje dane są prawdopodobnie poprawne. Sprawdź tabelę rozwiązywania problemów, aby poznać inne możliwe przyczyny.

Czy wszyscy dostawcy usług pocztowych wysyłają raporty o niepowodzeniach DMARC?

Nie. Usługi Gmail i Microsoft 365 zasadniczo tego nie robią, powołując się na ochronę prywatności użytkowników. Obsługa tej funkcji ogranicza się do odbiorców, którzy wdrożyli obsługę RUF – zazwyczaj są to niektóre korporacyjne bramy pocztowe, dostawcy usług internetowych oraz niezależne serwery pocztowe. Jest to istotne ograniczenie.

Czy otrzymywanie raportów o niepowodzeniach DMARC jest bezpieczne?

Mogą one zawierać dane osobowe, takie jak tematy wiadomości, adresy odbiorców i nagłówki. Odbieranie takich wiadomości bez odpowiednich środków kontroli może powodować powstanie zobowiązań wynikających z RODO i CCPA. Najbezpieczniej jest przekierowywać je na bezpieczną platformę wyposażoną w szyfrowanie PGP, dostęp oparty na rolach oraz określone zasady przechowywania danych.

Do czego służy tag „fo”?

Skrót ten oznacza „Failure Options” (opcje błędów) i określa, kiedy odbiorcy generują raport. Wartość fo=0 (domyślna) wymaga, aby zarówno SPF, jak i DKIM zakończyły się niepowodzeniem. Wartość fo=1 powoduje wysłanie raportu w przypadku dowolnego z tych błędów. Wartość fo=d uruchamia proces wyłącznie w przypadku niepowodzenia DKIM; wartość fo=s – wyłącznie w przypadku niepowodzenia SPF.

• O
• Latest Posts

Milena Baghdasaryan

Specjalista ds. treści w PowerDMARC

Milena jest wykwalifikowaną pisarką i twórczynią treści z ponad 7-letnim doświadczeniem w tworzeniu angażujących treści na temat IT, cyberbezpieczeństwa, wirtualnych wydarzeń i nie tylko. Ma udokumentowane doświadczenie w dostarczaniu wysokiej jakości prac dla międzynarodowych magazynów i jest absolwentką prestiżowych instytucji, takich jak New York University Abu Dhabi, UWC China i College of Europe.

Najnowsze posty autorstwa Milena Baghdasaryan (zobacz wszystkie)

• Raporty o niepowodzeniach DMARC (RUF): czym są, jak działają i jak je bezpiecznie włączyć – 11 sierpnia 2026 r.
• Uwierzytelnianie adresów e-mail w największych światowych firmach zajmujących się sztuczną inteligencją – 10 sierpnia 2026 r.
• 5 najlepszych narzędzi do walki z atakami typu Business Email Compromise (BEC) w 2026 r. – 31 lipca 2026 r.