Pytania o DMARC,
z odpowiedziami

DMARC (Domain-based Message Authentication, Reporting & Conformance) to protokół uwierzytelniania poczty e-mail, który informuje odbierające serwery pocztowe, co mają zrobić, gdy kontrole SPF lub DKIM zakończą się niepowodzeniem. Zapobiega wysyłaniu przez atakujących wiadomości, które wyglądają, jakby pochodziły z Pana/Pani domeny, chroniąc markę i odbiorców przed phishingiem i spoofingiem. DMARC jest zdefiniowany w RFC 7489.

Tak. Jeśli Pana/Pani domena wysyła wiadomości e-mail - a nawet jeśli nie wysyła - potrzebuje DMARC. Bez niego każdy może wysyłać wiadomości podszywające się pod Pana/Pani domenę. Google i Yahoo wymagają teraz co najmniej p=none dla domen wysyłających ponad 5000 wiadomości dziennie. PCI DSS v4.0 wymaga DMARC dla domen obsługujących klientów. Domeny niewysyłające poczty powinny publikować p=reject, aby zapobiec podszywaniu się.

Zacznij od upewnienia się, że SPF i DKIM są skonfigurowane dla Pana/Pani domeny. Następnie opublikuj rekord DNS TXT w _dmarc.twojadomena.com z p=none oraz adresem raportowania rua=. Monitoruj raporty zbiorcze przez co najmniej 90 dni, popraw uwierzytelnianie wszystkich legalnych nadawców, a następnie stopniowo przejdź do p=quarantine i wreszcie p=reject. Skorzystaj z naszego weryfikatora DMARC, aby zwalidować swój rekord.

Opublikowanie rekordu DMARC w p=none zajmuje kilka minut. Osiągnięcie pełnego egzekwowania w p=reject trwa zazwyczaj od 9 do 18 miesięcy. Każda faza (none, quarantine, reject) wymaga co najmniej 90 dni monitorowania, aby zidentyfikować wszystkie legalne źródła wysyłki i poprawić ich uwierzytelnianie. Organizacje z mniejszą liczbą zewnętrznych nadawców mogą postępować szybciej.

Rekord DMARC to rekord DNS TXT opublikowany w _dmarc.twojadomena.com. Typowy rekord wygląda tak: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com; adkim=r; aspf=r. Znaczniki v= i p= są wymagane; wszystkie pozostałe są opcjonalne, ale zalecane. Zobacz naszą stronę Czym jest DMARC, aby uzyskać pełne omówienie każdego znacznika.

SPF weryfikuje, czy serwer wysyłający jest autoryzowany przez rekord DNS domeny - sprawdza nadawcę koperty (Return-Path). DKIM dołącza podpis kryptograficzny, aby udowodnić, że wiadomość nie została zmieniona w tranzycie. DMARC łączy je ze sobą: wymaga, aby SPF lub DKIM przeszedł ORAZ był zgodny z widoczną domeną nagłówka From, a następnie informuje odbiorców, co robić, gdy uwierzytelnianie się nie powiedzie. Skorzystaj z naszego weryfikatora SPF oraz wyszukiwarki DKIM, aby przetestować swoje rekordy.

Nie. Domena musi mieć dokładnie jeden rekord DMARC TXT w _dmarc.domain.com. Wiele rekordów DMARC powoduje błąd PermError, a odbiorcy zignorują je wszystkie. Jeśli musisz wysyłać raporty na wiele adresów, wymień je oddzielone przecinkami w znaczniku rua=: rua=mailto:dmarc@example.com,mailto:reports@example.com.

Zgodność DMARC oznacza, że domena w widocznym nagłówku From musi odpowiadać domenie, która przeszła SPF lub DKIM. Zgodność relaxed (domyślna) pozwala na dopasowanie subdomeny - mail.example.com jest zgodne z example.com. Zgodność strict wymaga dokładnego dopasowania domeny. Zgodność zapobiega temu, by atakujący przeszli SPF z własną domeną, jednocześnie podszywając się pod Pana/Pani w nagłówku From.

Polityka p=none nakazuje odbierającym serwerom nie podejmować żadnych działań egzekucyjnych wobec wiadomości, które nie przejdą DMARC. Wiadomości są dostarczane normalnie, niezależnie od wyników uwierzytelniania. Celem jest monitorowanie: odbiorcy nadal wysyłają raporty zbiorcze, dając właścicielowi domeny wgląd we wszystkie źródła wysyłki. Zawsze zaczynaj od p=none przed przejściem do egzekwowania.

Polityka p=quarantine nakazuje odbierającym serwerom kierowanie wiadomości, które nie przeszły weryfikacji, do folderu spam lub wiadomości-śmieci. Wiadomość nadal istnieje - odbiorcy mogą ją znaleźć - ale jest oznaczona jako podejrzana. To pośredni etap egzekwowania między p=none (monitorowanie) a p=reject (pełna blokada). Zobacz nasz przewodnik Polityka DMARC, aby poznać pełną progresję.

Polityka p=reject nakazuje odbierającym serwerom odrzucanie wiadomości, które nie przeszły weryfikacji, na poziomie SMTP. Odbiorca nigdy nie widzi wiadomości, a serwer wysyłający otrzymuje odbicie (bounce). To najsilniejsza ochrona DMARC i ostateczny cel dla każdej domeny. Osiągnięcie p=reject wymaga wcześniejszego dokładnego monitorowania przez fazy p=none i p=quarantine.

Znacznik pct= kontroluje, jaki procent wiadomości, które nie przeszły weryfikacji, otrzymuje działanie egzekucyjne. Przy pct=25 tylko 25% wiadomości jest poddawanych kwarantannie lub odrzucanych - reszta jest traktowana jak p=none. Pozwala to na stopniowe wdrażanie egzekwowania. Zacznij od pct=10, zwiększ do 25, 50, a następnie 100 w ciągu kilku tygodni. Jeśli pct= zostanie pominięty, jego wartość domyślna to 100.

Raport zbiorczy (RUA) to plik XML wysyłany codziennie przez odbierające serwery pocztowe, podsumowujący wyniki uwierzytelniania wszystkich wiadomości podających się za pochodzące z Pana/Pani domeny. Pokazuje, które adresy IP wysłały wiadomości, czy SPF i DKIM przeszły oraz jaka polityka została zastosowana. Raporty zbiorcze są fundamentem monitorowania DMARC - dostarczają danych potrzebnych do podejmowania decyzji egzekucyjnych. DMARC Report przekształca te pliki XML w wizualne pulpity.

Raport kryminalistyczny (RUF) dostarcza szczegółów niepowodzenia dla poszczególnych wiadomości - konkretnej wiadomości, która nie przeszła uwierzytelniania, adresu IP nadawcy, niezgodności From/Return-Path oraz który mechanizm zawiódł. Raporty kryminalistyczne są przydatne do badania aktywnych prób spoofingu, ale są rzadziej obsługiwane przez odbiorców niż raporty zbiorcze. Niektórzy odbiorcy w ogóle nie wysyłają raportów RUF ze względu na obawy dotyczące prywatności.

Surowe raporty zbiorcze DMARC to pliki XML, które trudno czytać ręcznie. Skorzystaj z analizatora raportów DMARC, takiego jak DMARC Report, aby przekształcić XML w wizualne pulpity pokazujące status uwierzytelniania nadawców, wyniki zgodności i działania polityki. Narzędzie automatycznie klasyfikuje nadawców według dostawcy (Google Workspace, Microsoft 365, SendGrid itp.) i podkreśla niepowodzenia wymagające uwagi.

Częste przyczyny: Pana/Pani rekord DMARC nie zawiera znacznika rua=, adres e-mail rua= zawiera literówkę lub wysłano zbyt małą ilość wiadomości, aby wyzwolić raporty (odbiorcy zazwyczaj grupują raporty codziennie). Jeśli rua= wskazuje na inną domenę niż ta uwierzytelniana, potrzebny jest zewnętrzny rekord DNS weryfikacji. Odczekaj od 24 do 72 godzin po opublikowaniu rekordu DMARC, aby raporty zaczęły napływać. Skorzystaj z naszego weryfikatora DMARC, aby zwalidować składnię rekordu.

Większość odbiorców wysyła raporty zbiorcze raz na 24 godziny, zazwyczaj o północy UTC. Niektórzy duzi odbiorcy, jak Google i Microsoft, mogą wysyłać kilka raportów dziennie. Ilość otrzymywanych raportów zależy od tego, ilu różnych odbiorców przetwarza wiadomości z Pana/Pani domeny. Popularne domeny mogą otrzymywać setki raportów dziennie od dziesiątek odbiorców.

Droga od p=none do p=reject trwa zazwyczaj od 9 do 18 miesięcy. Każda faza wymaga co najmniej 90 dni: p=none dla monitorowania i identyfikacji nadawców, p=quarantine dla pośredniego egzekwowania oraz p=reject dla pełnej ochrony. Organizacje z mniejszą liczbą zewnętrznych nadawców i prostszą infrastrukturą pocztową mogą postępować szybciej, ale pośpiech w egzekwowaniu powoduje blokowanie legalnych wiadomości.

Jeśli legalny nadawca nie przejdzie DMARC przy p=quarantine, jego wiadomość trafi do spamu. Przy p=reject zostaje całkowicie zablokowana. Aby to naprawić: sprawdź raporty zbiorcze, aby zidentyfikować nadawcę, który zawiódł, skonfiguruj jego include SPF lub podpisywanie DKIM i sprawdź, czy zgodność przechodzi. Użycie znacznika pct= do stopniowego wdrażania egzekwowania pomaga wykryć te problemy, zanim wpłyną na całą pocztę.

Kwarantanna zapewnia znaczącą ochronę - sfałszowane wiadomości opuszczają skrzynkę odbiorczą. Jednak p=reject jest zalecanym celem, ponieważ całkowicie zapobiega dostarczeniu. Niektóre ramy zgodności (PCI DSS v4.0, CISA BOD 18-01 dla agencji federalnych) wyraźnie wymagają p=reject. Ponadto p=reject jest wymagany, aby kwalifikować się do BIMI, które wyświetla logo Pana/Pani marki w obsługujących klientach pocztowych.

Tak. Tradycyjne przekazywanie wiadomości może zepsuć zgodność SPF, ponieważ IP serwera przekazującego nie znajduje się w rekordzie SPF domeny źródłowej. DKIM zazwyczaj przetrwa przekazywanie, ponieważ podpis jest dołączony do samej wiadomości. Dlatego zgodność DKIM jest szczególnie ważna dla domen, których odbiorcy przekazują wiadomości. ARC (Authenticated Received Chain) to nowszy protokół zaprojektowany, aby rozwiązać ten problem, ale jego przyjęcie wciąż rośnie.

DMARC jest wymagany przez rosnącą liczbę standardów i organizacji. Google i Yahoo wymagają co najmniej p=none dla nadawców masowych (5000+ wiadomości/dzień). PCI DSS v4.0 wymaga DMARC dla domen używanych w komunikacji z klientami (obowiązuje od marca 2025). CISA BOD 18-01 nakazuje p=reject dla amerykańskich agencji federalnych. Wiele polis cyberubezpieczeń i procesów zakupowych wymaga teraz egzekwowania DMARC.

Od lutego 2024 roku Google i Yahoo wymagają od wszystkich nadawców masowych (5000+ wiadomości/dzień do użytkowników Gmail/Yahoo) polityki DMARC na poziomie co najmniej p=none z prawidłowym adresem rua=. Ponadto nadawcy muszą mieć poprawnie skonfigurowane SPF i DKIM, zawierać nagłówki wypisania się jednym kliknięciem w wiadomościach marketingowych i utrzymywać wskaźnik skarg na spam poniżej 0,3%. Nadawcy niezgodni doświadczają ograniczania dostarczania i odrzuceń.

Tak. PCI DSS v4.0 (obowiązuje od marca 2025) wymaga od organizacji przetwarzających dane posiadaczy kart wdrożenia DMARC na domenach używanych w komunikacji z klientami. Konkretnie, wymaganie 5.4.1 stanowi, że mechanizmy antyphishingowe muszą obejmować uwierzytelnianie oparte na domenie (DMARC, SPF, DKIM). Większość audytorów PCI oczekuje p=reject lub p=quarantine dla zgodności.

Binding Operational Directive 18-01, wydana przez Cybersecurity and Infrastructure Security Agency (CISA), wymaga od wszystkich amerykańskich agencji federalnej władzy wykonawczej wdrożenia DMARC w p=reject. Dyrektywa ta znacząco zwiększyła przyjęcie DMARC w sektorze rządowym i jest często cytowana jako punkt odniesienia dobrych praktyk przez inne organizacje i branże.

DMARC wspiera zgodność z HIPAA, zapobiegając spoofingowi nazw domen z sektora opieki zdrowotnej, zmniejszając ryzyko ataków phishingowych, które mogłyby prowadzić do ujawnienia Chronionych Informacji Zdrowotnych (PHI). Chociaż HIPAA nie wymienia wprost DMARC, Security Rule wymaga zabezpieczeń chroniących elektroniczne PHI, a uwierzytelnianie poczty e-mail jest uważane za rozsądny i odpowiedni środek. Należy pamiętać, że raporty kryminalistyczne (RUF) mogą zawierać treść wiadomości, więc organizacje opieki zdrowotnej powinny używać wyłącznie raportów zbiorczych (RUA) lub zapewnić, że raporty kryminalistyczne są przetwarzane zgodnie z HIPAA.