Jak czytać zbiorczy raport DMARC (RUA): XML rozłożony na czynniki pole po polu

Zbiorczy raport DMARC (raport "rua") to plik XML, który dostawca skrzynek pocztowych, taki jak Google czy Microsoft, wysyła Ci raz dziennie. Wymienia on każdy adres IP, który wysłał pocztę używając Twojej domeny w nagłówku From, oraz informację, czy każdy z nich przeszedł DMARC. Aby przeczytać taki raport, sprawdzasz kolejno trzy bloki: kto wysłał raport i kiedy, względem jakiej polityki został on oceniony, a następnie każdy wiersz record pokazujący źródłowy IP, liczbę wiadomości oraz wynik pass lub fail dla wyrównania SPF i DKIM. Gdy już umiesz czytać surowy XML, potrafisz odróżnić nadawców legalnych, ale źle skonfigurowanych, od jawnego podszywania się, nie płacąc za żaden panel.

Trzy części każdego raportu zbiorczego

Każdy raport zbiorczy jest zgodny ze schematem zdefiniowanym w RFC 7489, Załącznik C. Elementem głównym jest <feedback>, a w jego wnętrzu zawsze znajdziesz trzy rodzaje bloków:

• <report_metadata> - kto wygenerował raport i jakie okno czasowe on obejmuje.
• <policy_published> - rekord DMARC, który raportujący znalazł w Twojej domenie w momencie oceny poczty.
• Jeden lub więcej elementów <record> - faktyczne źródła wysyłki, pogrupowane według IP i wyniku.

Raporty są sporządzane per dzień i per raportujący, więc pojedyncza domena z realnym ruchem otrzyma kilka plików dziennie. Opisują one pocztę, która już się wydarzyła. To lusterko wsteczne, a nie transmisja na żywo, dlatego segregacja polega na wychwytywaniu wzorców w wielu źródłach, a nie na reagowaniu na pojedynczą wiadomość.

report_metadata: kto Ci to mówi

<report_metadata>
 <org_name>google.com</org_name>
 <email>noreply-dmarc-support@google.com</email>
 <report_id>1234567890123456789</report_id>
 <date_range>
 <begin>1719964800</begin>
 <end>1720051200</end>
 </date_range>
</report_metadata>

org_name to raportujący, tutaj Google. Wartości date_range to znaczniki czasu Unix w UTC. Przelicz 1719964800, a otrzymasz 24-godzinne okno, które obejmuje ten plik. Zachowaj report_id, bo jeśli kiedykolwiek otworzysz zgłoszenie do wsparcia u raportującego, to właśnie ten numer będzie im potrzebny jako odniesienie. Ten blok nigdy nie mówi Ci, że coś jest nie tak. Jedynie ustawia kontekst dla reszty.

policy_published: tożsamość, która niesie DMARC

<policy_published>
 <domain>yourdomain.com</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>none</p>
 <sp>none</sp>
 <pct>100</pct>
</policy_published>

To kopia Twojego opublikowanego rekordu DMARC widziana przez raportującego. Ma to znaczenie, ponieważ DMARC nie interesuje, czy SPF lub DKIM przeszły same z siebie. Interesuje go, czy którykolwiek z nich przeszedł i wyrównał się z domeną w widocznym nagłówku From. Wyrównanie to cała gra.

• adkim i aspf ustawiają tryb wyrównania. r oznacza tryb luźny (relaxed) - domena organizacyjna musi się zgadzać, więc mail.yourdomain.com wyrównuje się z yourdomain.com. s oznacza tryb ścisły (strict) - wymagana jest dokładna zgodność.
• p to Twoja polityka dla domeny organizacyjnej: none, quarantine lub reject.
• sp to polityka dla subdomen. Jeśli jej brakuje, subdomeny dziedziczą p.
• pct to procent poczty niezdanej, do której polityka jest stosowana.

Jeśli ten blok nie zgadza się z rekordem, który Twoim zdaniem opublikowałeś, ktoś zmienił Twój DNS albo patrzysz na subdomenę, o której zapomniałeś. Różnicę między trzema poziomami polityki oraz to, kiedy przechodzić na wyższy, opisuje Polityka DMARC: none vs quarantine vs reject.

record: czytanie pojedynczego wiersza źródła

Tutaj spędzasz najwięcej czasu. Każdy <record> ma troje dzieci: row, identifiers i auth_results.

<record>
 <row>
 <source_ip>203.0.113.25</source_ip>
 <count>418</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <dkim>pass</dkim>
 <spf>pass</spf>
 </policy_evaluated>
 </row>
 <identifiers>
 <header_from>yourdomain.com</header_from>
 </identifiers>
 <auth_results>
 <spf>
 <domain>yourdomain.com</domain>
 <result>pass</result>
 </spf>
 <dkim>
 <domain>yourdomain.com</domain>
 <selector>s1</selector>
 <result>pass</result>
 </dkim>
 </auth_results>
</record>

row i policy_evaluated

source_ip to IP, które wysłało pocztę. count to liczba wiadomości, których dotyczył dokładnie ten wynik, więc fala podszywania się pojawia się jako jeden wiersz z dużą wartością count. policy_evaluated to werdykt raportującego:

• disposition to to, co faktycznie stało się z pocztą: none, quarantine lub reject.
• Wartości dkim i spf wewnątrz policy_evaluated to wyniki wyrównane, a nie surowe. To najczęściej błędnie odczytywane pole w całym formacie. Wiadomość może mieć DKIM pass w auth_results, a mimo to pokazywać tutaj fail, ponieważ domena podpisująca nie wyrównała się z domeną z From.

DMARC przechodzi, gdy co najmniej jedna z tych dwóch wyrównanych kontroli ma wynik pass. Obie mogą się nie powieść, a DMARC i tak zawiedzie.

identifiers i auth_results

header_from to domena, którą człowiek widzi w swoim programie pocztowym. To tożsamość, którą chroni DMARC. auth_results pokazuje surowe wyniki SPF i DKIM przed wyrównaniem: domain, dla której SPF się uwierzytelnił, oraz domain plus selector, którymi podpisał się DKIM. Porównywanie domen z auth_results z header_from to sposób na ręczne diagnozowanie błędów wyrównania. Jeśli DKIM podpisał dla sendgrid.net, ale header_from to yourdomain.com, surowy DKIM przeszedł, a wyrównany DKIM zawiódł. To właśnie ten wzorzec stoi za większością błędów wyrównania DKIM.

Segregacja: trzy wzorce i dokładne działanie dla każdego

Gdy już umiesz czytać wiersz, posortuj każde źródło do jednego z trzech koszyków.

Wzorzec 1: wyrównany pass, nie rób nic

policy_evaluated pokazuje dkim lub spf jako pass, a domena w auth_results to Twoja własna domena lub subdomena. To Twoja legalna poczta płynąca poprawnie. Zanotuj IP, aby je rozpoznać, i idź dalej.

Wzorzec 2: legalny, ale zawodzi, napraw to

source_ip należy do usługi, z której faktycznie korzystasz (Twój CRM, narzędzie do faktur, platforma marketingowa), ale policy_evaluated pokazuje zarówno dkim, jak i spf jako fail. Spójrz na auth_results. Jeśli SPF przeszedł dla własnej domeny dostawcy, ale nie dla Twojej, dostawca nie znajduje się w Twoim rekordzie SPF albo wysyła z return-path, którego nie autoryzujesz. Jeśli DKIM przeszedł dla domeny dostawcy, musisz skonfigurować z tym dostawcą podpisywanie DKIM wyrównane do domeny. Napraw to, zanim podniesiesz politykę, w przeciwnym razie zablokujesz własną pocztę. Kroki konfiguracji znajdziesz w jak skonfigurować DKIM oraz jak skonfigurować DMARC.

Wzorzec 3: nieznane źródło, zawodzi, prawdopodobnie podszywanie się

source_ip to takie, którego nie rozpoznajesz, geolokalizuje się gdzieś, gdzie nie masz infrastruktury, header_from to Twoja domena, a obie wyrównane kontrole zawodzą. Wysokie wartości count z jednego dziwnego IP to klasyczny podpis. To poczta, przed którą istnieje Twoja polityka DMARC. Dopóki te źródła nie potrafią wygenerować wyrównanego pass, przejście z polityką na p=quarantine, a następnie p=reject, zamyka je na dobre. Dokładnie tak DMARC blokuje podszywanie się pod markę, co opisano w jak zatrzymać podszywanie się pod Twoją domenę w e-mailach.

Od czytania do działania

Celem ręcznego czytania raportów nie jest robienie tego w nieskończoność. Chodzi o zbudowanie zweryfikowanej listy każdego legalnego nadawcy, doprowadzenie każdego z nich do wyrównanego pass, a następnie pewne opublikowanie rekordu w rodzaju v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; adkim=s; aspf=s. Zbiorczy XML nie pokazuje treści wiadomości ani odbiorców, więc jego egzekwowanie jest bezpieczne i nie stwarza ryzyka dla prywatności. Jeśli któryś wiersz nadal Cię dezorientuje, skonfrontuj go z surowymi nagłówkami prawdziwej wiadomości, korzystając z naszego przewodnika po nagłówku Authentication-Results, który pokazuje te same decyzje pass i fail z perspektywy serwera odbierającego.

Najczęściej zadawane pytania

Jaka jest różnica między wynikiem SPF w auth_results a w policy_evaluated?

Wynik SPF w auth_results to surowy rezultat według RFC 7208 dla domeny, którą uwierzytelnił SPF, zazwyczaj return-path. Wynik SPF w policy_evaluated to wynik wyrównany: jest on pass tylko wtedy, gdy ten surowy pass wyrównuje się także z domeną z From. DMARC używa tego wyrównanego.

Dlaczego dostaję tak wiele raportów zbiorczych?

Każdy dostawca skrzynek pocztowych wysyła jeden raport dziennie dla Twojej domeny, a osobny plik dostajesz od każdego dostawcy, który otrzymał Twoją pocztę. Domena wysyłająca do użytkowników Google, Microsoft i Yahoo dostanie co najmniej trzy pliki dziennie, plus kolejne od mniejszych odbiorców.

Czy raport zbiorczy może pokazać mi faktyczną treść e-maila?

Nie. Raporty zbiorcze zawierają wyłącznie adresy IP, liczby, wyniki uwierzytelniania i dane polityki. Nigdy nie zawierają tematów, treści wiadomości ani adresów odbiorców. Szczegóły na poziomie wiadomości znajdują się w raportach kryminalistycznych (ruf), których większość dużych dostawców już nie wysyła ze względu na prywatność.

Czy potrzebuję płatnego narzędzia, aby czytać raporty DMARC?

Nie. XML to udokumentowany, czytelny format, a dla małej domeny możesz segregować pliki ręcznie, korzystając z trzech powyższych wzorców. Płatne panele głównie oszczędzają czas, agregując i geolokalizując źródła na dużą skalę. Zrozumienie najpierw surowego XML oznacza, że potrafisz zweryfikować to, co mówi Ci dowolne narzędzie.