Struktura i komponenty rekordu DMARC
Rekord DMARC (Domain-based Message Authentication, Reporting, and Conformance) jest tekstowym wpisem DNS typu TXT, który pozwala właścicielom domen kontrolować, jak serwery odbiorców powinny traktować wiadomości e-mail niespełniające wymogów uwierzytelniania SPF (Sender Policy Framework) oraz DKIM (DomainKeys Identified Mail).
Każdy prawidłowy rekord DMARC składa się z serii par klucz-wartość (tagów) rozdzielonych średnikami. Analiza poprawności tego rekordu wymaga weryfikacji kolejności tagów, ich unikalności oraz poprawności przypisanych im wartości. Narzędzie Sprawdzanie rekordu DMARC przetwarza podany ciąg znaków, identyfikuje poszczególne komponenty i wskazuje potencjalne błędy wdrożeniowe.
Rola znacznika v=DMARC1
Deklaracja wersji jest najważniejszym elementem całego rekordu. Obowiązują tu rygorystyczne reguły składniowe:
- Rekord musi bezwzględnie zaczynać się od wartości
v=DMARC1. W wielkości liter ma znaczenie każdy znak – zapis małymi literami lub z dodatkowymi spacjami przed tą deklaracją jest niedozwolony. v=DMARC1musi być pierwszym składnikiem w całym ciągu tekstowym. Jeśli parser wykryje ten tag na dalszej pozycji, zgłosi błąd:Składnik ‹position›: v=DMARC1 musi być pierwszym składnikiem..
W przypadku importowania rekordów bezpośrednio z konfiguracji strefy DNS, gdzie wpisy bywają dzielone na sekcje, narzędzie automatycznie łączy fragmenty ujęte w cudzysłowy przed przystąpieniem do właściwej analizy. Informuje o tym komunikat: Fragmenty DNS TXT w cudzysłowach połączono przed analizą..
Polityki DMARC i ich hierarchia (p, sp, np)
Polityka DMARC określa instrukcje dla serwera odbierającego pocztę, wskazując, co należy zrobić z wiadomościami, które nie przeszły pomyślnie autoryzacji SPF lub DKIM. Wyróżnia się trzy główne poziomy polityki: none (tylko monitorowanie), quarantine (kierowanie do folderu ze spamem/kwarantanny) oraz reject (całkowite odrzucenie wiadomości).
Mechanizm dziedziczenia i hierarchia tagów
W strukturze DMARC istnieją trzy odrębne tagi odpowiedzialne za definiowanie polityki dla różnych poziomów domeny:
- p (Domain policy): Główna polityka dla domeny najwyższego poziomu. Jeśli w rekordzie zabraknie tego tagu, parser zgłasza błąd, a polityka domeny automatycznie przyjmuje domyślną wartość
none. - sp (Subdomain policy): Polityka stosowana wobec subdomen.
- np (Non-existent subdomains): Polityka dla nieistniejących subdomen.
W przypadku braku bardziej szczegółowych tagów w rekordzie, systemy odbiorcze stosują mechanizm fallback (wycofania). Oznacza to, że polityka dla nieistniejących subdomen (np) w razie swojej nieobecności dziedziczy ustawienia z polityki dla subdomen (sp). Jeśli tag sp również nie został zdefiniowany, ostatecznym punktem odniesienia staje się główna polityka domeny p.
| Tag | Opis | Zachowanie w przypadku braku |
|---|---|---|
p |
Polityka dla domeny głównej | Przyjmuje domyślnie none |
sp |
Polityka dla subdomen | Dziedziczy wartość z tagu p |
np |
Polityka dla nieistniejących subdomen | Dziedziczy z sp, a w dalszej kolejności z p |
Konfiguracja raportowania i dopasowania identyfikatorów
Raportowanie jest kluczowym elementem DMARC, pozwalającym administratorom na monitorowanie infrastruktury wysyłkowej i wykrywanie prób podszywania się pod domenę. Narzędzie analizuje poprawność adresów docelowych dla dwóch typów raportów:
- rua (Aggregate reports): Adresy e-mail przeznaczone do odbierania zbiorczych raportów statystycznych. Jeśli w rekordzie nie zostanie zdefiniowany żaden poprawny adres URI w tagu
rua, raporty zbiorcze nie będą żądane. - ruf (Failure reports): Adresy do wysyłki szczegółowych raportów o pojedynczych błędach autoryzacji (raporty forensic).
Zależności i przestarzałe parametry raportowania
Podczas konfiguracji raportów należy pamiętać o zależnościach między tagami. Przykładowo, tag fo (opcje generowania raportów o błędach) jest całkowicie ignorowany przez serwery odbiorcze, jeżeli w rekordzie nie skonfigurowano poprawnego adresu w tagu ruf.
W starszych specyfikacjach technicznych (takich jak RFC 7489) dopuszczalne było stosowanie przyrostka określającego maksymalny rozmiar raportu bezpośrednio przy adresie e-mail (np. mailto:dmarc@example.com!10m). Zgodnie z nowym standardem RFC 9989, przyrostek !size jest przestarzały i powinien być ignorowany przez współczesne systemy odbiorcze.
Ewolucja standardu: Tagi aktywne i historyczne
Standardy DMARC ewoluują, co prowadzi do dezaktualizacji niektórych parametrów, które były powszechnie stosowane w przeszłości. Narzędzie klasyfikuje wykryte tagi pod kątem ich statusu w aktualnych specyfikacjach:
- Status RFC 9989 (Aktywne): Tagi w pełni wspierane i zalecane przez najnowszy standard, takie jak
np,psdczyt. - Status RFC 7489 (Historyczne): Tagi, które utraciły swoje pierwotne znaczenie lub zostały wycofane. Przykładem jest tag
pct(procent wiadomości objętych polityką). W starszych wdrożeniach służył on do stopniowego wdrażania polityki, jednak obecnie jego stosowanie ogranicza pokrycie polityką wyłącznie u odbiorców, którzy nadal korzystają ze starych specyfikacji DMARC. - Tagi nieznane i nieprawidłowe: Wszelkie niestandardowe tagi, które nie są zarejestrowane, zostaną zignorowane przez serwery odbiorcze.
Tryb testowy (t=y)
Wprowadzenie tagu t=y oznacza, że domena znajduje się w trybie testowym. Wpływa to bezpośrednio na interpretację polityki przez odbiorców. Podczas testów rygorystyczność polityki zostaje obniżona: polityka reject jest traktowana jak quarantine, natomiast polityka quarantine działa jak none. Pozwala to na bezpieczne zbieranie raportów bez ryzyka zablokowania legalnej korespondencji.
Obsługa narzędzia i prywatność danych
Narzędzie Sprawdzanie rekordu DMARC przetwarza dane wejściowe w sposób bezpieczny dla prywatności użytkownika. Cały proces analizy składniowej oraz walidacji reguł odbywa się bezpośrednio w przeglądarce internetowej użytkownika. Wklejony rekord DMARC nie jest przesyłany na żadne serwery zewnętrzne, nie jest zapisywany w bazach danych ani nie jest przechowywany w pamięci lokalnej przeglądarki. Narzędzie nie wykonuje również żadnych zewnętrznych zapytań sieciowych powiązanych z analizowanym tekstem.
Aby dokonać analizy, należy wkleić rekord w pole Wartość DMARC TXT i kliknąć przycisk Sprawdź rekord DMARC. Maksymalna dopuszczalna długość wprowadzanego rekordu wynosi 20 000 znaków. Przekroczenie tego limitu spowoduje wyświetlenie błędu: Ten rekord jest wyjątkowo duży. Ogranicz go do 20 000 znaków..
FAQ – Najczęściej zadawane pytania
Uwagi dotyczące składni i polityki: p / sp / np?
W przypadku braku określonej polityki dla subdomen (sp) lub nieistniejących subdomen (np), systemy odbiorcze stosują regułę dziedziczenia: np przejmuje wartość z sp, a sp z głównej polityki p. Jeżeli w rekordzie brakuje tagu p, domyślnie stosowana jest polityka p=none. Warto pamiętać, że polityka p=none służy wyłącznie do monitorowania i zbierania raportów – nie instruuje odbiorców o konieczności odrzucania lub kierowania do spamu wiadomości niespełniających kryteriów autoryzacji. Dodatkowo, użycie tagu testowego t=y tymczasowo obniża rygor polityki reject do quarantine, a quarantine do none.
RFC 9989: pct / rf / ri?
Zgodnie z najnowszym standardem RFC 9989, tagi takie jak pct (procentowe wdrażanie polityki), rf oraz ri są klasyfikowane jako historyczne (zdefiniowane pierwotnie w RFC 7489). Współczesne systemy odbiorcze mogą je ignorować. Nowy standard kładzie nacisk na tagi aktywne, do których należą m.in. np (polityka dla nieistniejących subdomen), psd (Public Suffix Domains) oraz t (tryb testowy).
Czy wynik bez problemów dowodzi, że moja konfiguracja DMARC działa? Nie. Ta strona sprawdza wyłącznie wklejony tekst pod kątem poprawności składniowej, struktury tagów oraz zgodności ze standardami. Narzędzie nie wysyła zapytań DNS, nie rozwija rekordów dostawców, nie testuje adresu IP nadawcy ani nie potwierdza odpowiedzi serwera pocztowego odbiorcy. Do pełnej weryfikacji działania wymagane jest poprawne opublikowanie rekordu w strefie DNS domeny oraz monitorowanie spływających raportów RUA.