Odczytywanie raportów DMARC

Moduł 4: Dostarczalność: SPF, DKIM i DMARC w praktyce · Czas czytania: 12 minut

Cel lekcji: Po tej lekcji będą Państwo potrafili otworzyć i odczytać raport zbiorczy DMARC, określić dla każdego wiersza, jakie jest źródło i dlaczego przechodzi lub nie przechodzi weryfikacji, oraz zdecydować, co naprawić, co można zignorować i kiedy można zaostrzyć politykę.

Kluczowe pojęcia: raport zbiorczy (aggregate report, RFC 9990), rua, XML, gzip lub zip, report_metadata, policy_published, record, row, source_ip, count, policy_evaluated (disposition, dkim, spf), identifiers (header_from, envelope_from), auth_results, selektor, raport o błędach (ruf, RFC 9991), usługa raportowania, prywatność

Co Państwo otrzymują

Jeśli w rekordzie DMARC ustawili Państwo adres rua (lekcja 4.4), to więksi odbiorcy, tacy jak Google, Microsoft i Yahoo, będą wysyłać Państwu mniej więcej codziennie raport zbiorczy. Jest to wiadomość z załącznikiem, zwykle spakowanym plikiem XML o nazwie podobnej do:

receiver.example!example.com!1793923200!1794009599.xml.gz

Oznacza to: od odbiorcy receiver.example, dotyczący Państwa domeny example.com, za okres pomiędzy dwoma znacznikami czasu (sekundy od 1970 roku; w tym przypadku 6 listopada 2026, cały dzień w UTC).

Raport nie zawiera treści wiadomości, tematów ani zwykle adresów odbiorców. Zawiera natomiast, dla każdego serwera wysyłającego, liczbę wiadomości oraz wynik SPF, DKIM i DMARC. Dzięki temu jest to wiarygodny przegląd tego, kto wysyła pocztę w imieniu Państwa domeny, także źródeł, o których mogli Państwo zapomnieć, oraz oszustów.

Budowa raportu

Raport składa się z trzech części. Poniżej najważniejsze fragmenty z przykładowego pliku z tej lekcji (dmarc-rapport-1.xml).

1. Kto raportuje i za jaki okres

<report_metadata>
  <org_name>receiver.example</org_name>
  <email>noreply-dmarc@receiver.example</email>
  <report_id>receiver.example-20261106-7f3c2a91</report_id>
  <date_range>
    <begin>1793923200</begin>
    <end>1794009599</end>
  </date_range>
</report_metadata>

2. Jaką politykę znalazł odbiorca w Państwa domenie

<policy_published>
  <domain>example.com</domain>
  <p>none</p>
  <sp>none</sp>
  <np>none</np>
  <adkim>r</adkim>
  <aspf>r</aspf>
  <testing>n</testing>
</policy_published>

Zawsze to Państwo sprawdzają: jeśli nie zgadza się z tym, co według Państwa znajduje się w DNS, oznacza to, że odbiorca odczytał inny (lub nieaktualny) rekord.

3. Dla każdego źródła: jeden rekord

Każdy record dotyczy jednego wysyłającego adresu IP wraz z jedną kombinacją wyników:

<record>
  <row>
    <source_ip>198.51.100.40</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounce.mailer.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mailer.example</domain>
      <selector>k1</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.mailer.example</domain>
      <scope>mfrom</scope>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Najważniejsza różnica: auth_results a policy_evaluated

Tutaj kryje się sedno odczytywania raportu. W powyższym przykładzie w auth_results dwukrotnie widnieje pass: DKIM zakończył się sukcesem dla mailer.example, a SPF zakończył się sukcesem dla bounce.mailer.example. Mimo to w policy_evaluated dwukrotnie widnieje fail. Nie jest to sprzeczność: policy_evaluated uwzględnia tylko udaną weryfikację, która jest dopasowana do header_from. Żadna z tych dwóch domen nie należy do example.com, więc DMARC kończy się niepowodzeniem.

W ten sposób odczytuje się każdy wiersz:

1. Proszę spojrzeć na policy_evaluated. Czy przy dkim lub spf widnieje pass? Wtedy DMARC kończy się sukcesem i to źródło jest w porządku.
2. Czy wszystko kończy się niepowodzeniem? Proszę sprawdzić domeny w auth_results. Czy jest to Państwa usługa, która owszem przechodzi weryfikację, ale dla własnej domeny? Wtedy należy u tej usługi włączyć DKIM z Państwa własną domeną (lekcja 4.3).
3. Czy weryfikacja nie przechodzi również w auth_results, albo DKIM w ogóle brakuje? Proszę sprawdzić, do kogo należy adres IP (odwrotne DNS, lekcja 5.1, albo wyszukiwanie whois). Czy to jeden z Państwa systemów: należy go naprawić. Czy jest nieznany i chodzi o podejrzane ilości: prawdopodobnie to fałszerstwo.

Powtarzające się schematy

Proszę zwrócić uwagę również na IPv6: własny serwer, który czasem wysyła przez IPv6, podczas gdy Państwa SPF podaje tylko adres IPv4, spowoduje softfail w tych wierszach. Dzięki podpisowi DKIM DMARC mimo to przejdzie, ale jest to oznaka, że SPF jest niekompletny.

Od raportu do decyzji

Mogą Państwo zaostrzyć politykę (z none na quarantine, a następnie na reject), jeśli:

• każde źródło, które do Państwa należy, ma w policy_evaluated przynajmniej jedno pass;
• tak jest już od kilku tygodni, u wszystkich dużych odbiorców;
• to, co nadal nie przechodzi, to wyłącznie przekierowana poczta z ważnym podpisem DKIM (która mimo to przejdzie) albo wyraźne fałszerstwo.

Jeśli duże własne źródło, jak w przykładzie usługa newslettera z 1250 wiadomościami, nie przechodzi, to jeszcze za wcześnie. Przy p=reject odbiorca odrzuciłby tych 1250 newsletterów.

Jak zrobić raporty czytelnymi

Jeden raport w edytorze tekstu jest do opanowania. Dwadzieścia dziennie już nie. Są trzy sposoby:

• Usługa raportowania (jest ich wiele, również z darmowym wariantem). Wpisują Państwo jej adres w rua, a ona przekształca dane w wykresy i listy. Proszę zwrócić uwagę: w ten sposób dają Państwo tej usłudze wgląd w to, które serwery wysyłają pocztę w Państwa imieniu, a adres raportowania znajduje się w jej domenie (zob. zgoda przez _report._dmarc w lekcji 4.4). Proszę wybrać usługę, której Państwo ufają i która przestrzega RODO.
• Własne narzędzie: istnieją programy open source, które pobierają raporty ze skrzynki pocztowej i tworzą z nich zestawienie.
• Odczyt samodzielny za pomocą przeglądarki XML lub przeglądarki internetowej, do sporadycznego użytku.

Raporty o błędach (ruf, RFC 9991) są inne: dotyczą pojedynczej nieudanej wiadomości, czasem z jej fragmentami w środku. Niemal żaden duży odbiorca ich nie wysyła, właśnie ze względu na prywatność. Nie są one Państwu potrzebne do prawidłowego wdrożenia DMARC.

W praktyce: tak to wygląda

W WebOké mogą Państwo wpisać adres raportowania w pomocy DMARC w DirectAdmin lub Moje WebOké (zob. lekcja 4.4), i sami wybierają Państwo skrzynkę pocztową, do której trafiają raporty; osobny adres, na przykład dmarc@, z własnym folderem, zapobiega zasypaniu zwykłej poczty. Odczyt odbywa się za pomocą wybranej usługi raportowania lub programu. Działa to tak samo u każdego dostawcy: raport ma format standardowy.

Podsumowanie

• Raport zbiorczy to codzienny plik XML (często spakowany) od każdego odbiorcy, zawierający dla każdego wysyłającego IP liczbę wiadomości i wyniki.
• auth_results podaje surowy wynik SPF i DKIM; policy_evaluated tylko to, co przeszło weryfikację po dopasowaniu. Pass w auth_results może oznaczać fail w DMARC.
• Przekierowaną pocztę rozpoznaje się po DKIM pass z SPF fail; fałszerstwo po tym, że wszystko jest fail i IP jest nieznane.
• Politykę zaostrzają Państwo dopiero wtedy, gdy wszystkie własne źródła przechodzą weryfikację przez kilka tygodni.
• Raporty o błędach (ruf) są rzadkie i niepotrzebne.

Quiz

Zadanie

Zadanie Z4.5: Odczytanie raportu DMARC. Proszę otworzyć przykładowy plik dmarc-rapport-1.xml (raport zbiorczy dotyczący example.com, z fikcyjnymi danymi). Proszę odpowiedzieć na pytania: jaką politykę znalazł odbiorca, ile wiadomości łącznie znajduje się w raporcie, ile z nich nie przeszło DMARC, który wiersz to usługa newslettera i co należy z nim zrobić, który wiersz to przekierowana poczta, który wiersz to prawdopodobnie fałszerstwo, co należy zmienić w rekordzie SPF zgodnie z wierszem 6, który wiersz przechodzi weryfikację wyłącznie dzięki DKIM u usługi z własnym Return-Path, oraz czy domena może teraz przejść na p=quarantine? Program sprawdza Państwa odpowiedzi według ustalonego klucza i dla każdego pytania wyjaśnia, który wiersz raportu daje odpowiedź.

Więcej informacji

Kroki opisane w tych artykułach dotyczą paneli WebOké; u innych dostawców działa to podobnie.

• Czym jest DMARC? Wyjaśnienie w prostych słowach
• Instrukcja DirectAdmin 5.9: DMARC instellen
• Bezpłatny kurs DNS 4.5: DMARC: co odbiorcy powinni robić z fałszywą pocztą
• RFC 9990 (DMARC Aggregate Reporting), z przykładowym raportem w załączniku B; RFC 9991 (Failure Reporting)