DMARC policy

DMARC policy to reguła zdefiniowana przez właściciela domeny, określająca sposób postępowania z wiadomościami niezgodnymi z weryfikacją.

DMARC policy jako reguła ochrony domeny

DMARC policy jest ustawieniem publikowanym dla domeny internetowej, które określa, co ma stać się z wiadomością wyglądającą na wysłaną z tej domeny, lecz niespełniającą warunków uwierzytelnienia. W praktyce jest to instrukcja dla systemów odbierających pocztę. Nie służy do tworzenia treści wiadomości ani do zarządzania skrzynką użytkownika, lecz do wskazania reakcji na pocztę, której pochodzenie lub sposób wysyłki budzi wątpliwości.

Reguła DMARC policy opiera się na współpracy kilku elementów. Domena nadawcy deklaruje zasady w rekordzie DNS typu TXT, a system odbiorcy sprawdza, czy wiadomość przechodzi mechanizmy SPF i DKIM oraz czy wyniki tych kontroli są zgodne z domeną widoczną w polu nadawcy. Dzięki temu możliwe jest ograniczenie podszywania się pod firmę, sklep internetowy, urząd albo inną organizację. Sama obecność rekordu DMARC nie oznacza jeszcze, że każda wiadomość zostanie zaakceptowana. Znaczenie ma zarówno wybrana polityka, jak i poprawność pozostałych ustawień.

Ważne jest rozróżnienie między domeną używaną do technicznego uwierzytelnienia a domeną prezentowaną odbiorcy. DMARC sprawdza ich zgodność w ramach tak zwanego dopasowania. Wiadomość może przejść SPF, ale nadal nie spełnić DMARC, jeśli domena użyta przy wysyłce nie odpowiada domenie widocznej dla odbiorcy. Podobnie poprawny podpis DKIM może nie wystarczyć, jeśli został wykonany przez inną domenę i nie zachodzi wymagane dopasowanie.

DMARC policy w kontekście SPF, DKIM i dostarczania poczty

Najłatwiej porównać DMARC policy do warstwy decyzyjnej umieszczonej nad SPF i DKIM. SPF opisuje, z jakich adresów technicznych może być wysyłana poczta dla danej domeny. DKIM dodaje do wiadomości podpis kryptograficzny, który pozwala sprawdzić, czy określone elementy nie zostały zmienione oraz czy podpisujący dysponuje odpowiednim kluczem. DMARC wykorzystuje wyniki tych kontroli i dodaje wymaganie zgodności z domeną nadawcy widoczną dla człowieka.

Trzy podstawowe wartości polityki oznaczają różny poziom reakcji. Ustawienie p=none ma charakter obserwacyjny. Wiadomości niezgodne z kontrolą nie muszą być od razu odrzucane, ale mogą zostać uwzględnione w raportach. Takie rozwiązanie bywa użyteczne na początku porządkowania wysyłki, ponieważ pozwala wykryć legalne źródła poczty, o których wcześniej nie pamiętano.

Ustawienie p=quarantine wskazuje, że wiadomości niespełniające reguł powinny być traktowane jako podejrzane. Ostateczne zachowanie zależy od systemu odbierającego, dlatego poczta może zostać skierowana do folderu z wiadomościami niepożądanymi albo poddana dodatkowym kontrolom. Z kolei p=reject wyraża najbardziej stanowczą instrukcję: wiadomość niespełniająca warunków powinna zostać odrzucona podczas przyjmowania lub zgodnie z procedurą stosowaną przez odbiorcę.

Polityka może dotyczyć również subdomen. Służy do tego parametr sp, który pozwala wskazać odrębne zachowanie dla adresów znajdujących się niżej w strukturze domeny. Dodatkowo można określić tryb dopasowania dla SPF i DKIM, procent wiadomości objętych działaniem reguły oraz adresy przeznaczone do odbierania raportów. Każdy z tych parametrów powinien być dobierany do rzeczywistego sposobu wysyłania poczty, ponieważ zbyt rygorystyczne ustawienie w nieprzygotowanym środowisku może wpłynąć na legalną korespondencję.

DMARC policy a typowe problemy z wiadomościami

Jednym z częstszych problemów jest wdrożenie polityki bez wcześniejszego rozpoznania wszystkich źródeł wysyłki. Poczta może być tworzona nie tylko w głównym systemie pocztowym, lecz także przez formularz kontaktowy, platformę do wysyłki biuletynów, system obsługi zgłoszeń, narzędzie do automatycznych powiadomień lub aplikację działającą na stronie. Jeżeli choć jedno z tych źródeł nie korzysta z prawidłowo skonfigurowanego SPF albo DKIM, po zaostrzeniu DMARC policy wiadomości mogą zacząć trafiać do niepożądanych albo nie docierać do odbiorców.

Inny kłopot pojawia się przy przekazywaniu wiadomości. Mechanizm SPF może nie przejść po zmianie trasy, ponieważ odbiorca widzi inny adres techniczny niż oczekiwany przez pierwotną domenę. DKIM jest w takiej sytuacji często pomocny, o ile podpis pozostaje ważny i obejmuje właściwe nagłówki. Problematyczne bywają także zmiany wprowadzane przez pośrednie systemy, które modyfikują temat, treść lub wybrane nagłówki wiadomości.

Nieprawidłowe wyniki mogą wynikać również z błędów w DNS. Rekord bywa opublikowany pod niewłaściwą nazwą, zawiera literówkę, ma niepoprawny format albo jest dzielony w sposób, którego nie interpretuje prawidłowo system odbierający. Trzeba też pamiętać o ograniczeniach liczby odwołań w SPF. Rozbudowana lista zewnętrznych źródeł może przekroczyć dozwolony poziom zapytań i spowodować błąd kontroli, nawet gdy poszczególne wpisy są poprawne.

Raporty DMARC również wymagają ostrożnej interpretacji. Nie każdy adres widoczny w raporcie oznacza nadużycie, a nie każdy brak zgodności świadczy o fałszerstwie. Pojedynczy raport pokazuje tylko fragment sytuacji, często z opóźnieniem i po agregacji danych. Przy analizie należy uwzględnić częstotliwość wysyłki, używane subdomeny, dostawców zewnętrznych, przekazywanie poczty oraz różnice między raportami zbiorczymi i raportami o pojedynczych zdarzeniach.

DMARC policy i praktyczne wskazówki wdrożeniowe

Bezpieczne wdrażanie warto rozpocząć od spisu wszystkich legalnych zastosowań domeny w poczcie. Należy ustalić, które systemy wysyłają wiadomości, z jakiej domeny korzystają, czy stosują SPF, czy podpisują wiadomości DKIM oraz czy domena podpisująca odpowiada domenie prezentowanej odbiorcy. Przydatne jest także rozdzielenie głównej domeny od subdomen przeznaczonych do automatycznych komunikatów, jeżeli taki podział odpowiada rzeczywistej organizacji wysyłki.

Na etapie obserwacji powinno się regularnie analizować raporty i usuwać niezgodności. Szczególną uwagę warto zwrócić na nieznane źródła, duże skupiska nieudanych kontroli, nagłe zmiany wolumenu oraz wiadomości wysyłane z adresów, które nie są już używane. Nie należy automatycznie dodawać każdego wykrytego źródła do dozwolonej konfiguracji, ponieważ część danych może pochodzić z prób podszywania się pod domenę.

Po uporządkowaniu legalnych wysyłek można stopniowo zaostrzać regułę. Przejście od obserwacji do kwarantanny, a następnie do odrzucania powinno być poprzedzone sprawdzeniem, czy wiadomości od wszystkich istotnych nadawców przechodzą kontrolę. Warto też objąć działaniem tylko część ruchu, jeśli składnia rekordu na to pozwala. Takie etapowanie ułatwia wychwycenie błędów bez nagłego wpływu na całą korespondencję.

W rekordzie powinno się stosować wyłącznie parametry, które są potrzebne i zrozumiałe dla osoby odpowiedzialnej za konfigurację. Adresy raportowe powinny być monitorowane, a ich obsługa powinna uwzględniać ochronę danych oraz ograniczenie dostępu. Zmiana DMARC policy nie zastępuje zabezpieczenia kont, aktualizacji aplikacji ani kontroli uprawnień do wysyłki. Jest jednym z elementów ochrony tożsamości domeny, a nie samodzielnym rozwiązaniem każdego problemu z pocztą.

DMARC policy i moment zgłoszenia do serwisu

Do serwisu warto zgłosić się wtedy, gdy wiadomości wysyłane z własnej domeny zaczynają trafiać do folderu niepożądanych, są odrzucane albo przestają docierać tylko do wybranych odbiorców. Pomoc może być potrzebna także po zmianie dostawcy poczty, uruchomieniu nowego formularza, podłączeniu narzędzia do komunikacji automatycznej lub przejęciu domeny po innej osobie. Objawem wymagającym analizy może być również nagły wzrost raportów o wiadomościach wysyłanych z nieznanych źródeł.

Przed zgłoszeniem dobrze przygotować nazwę domeny, przykładowe nagłówki problematycznych wiadomości, informację o tym, z jakiego programu lub usługi zostały wysłane, oraz moment pojawienia się trudności. Nie powinno się przekazywać haseł ani kluczy prywatnych. Wystarczające bywają publiczne rekordy DNS, zanonimizowane nagłówki i opis oczekiwanego sposobu wysyłki. Tak zebrane dane ułatwiają rozróżnienie błędu w DMARC policy od problemu z SPF, DKIM, DNS lub samą trasą doręczania.

Warszawskie Pogotowie Komputerowe 24/7 może pomóc w uporządkowaniu ustawień związanych z pocztą domenową, sprawdzeniu zależności między rekordami oraz wyjaśnieniu, dlaczego określone wiadomości nie spełniają wymagań. W przypadku istotnej korespondencji zalecane jest wykonanie kopii aktualnych ustawień i dokumentowanie każdej zmiany. Dzięki temu można łatwo odtworzyć wcześniejszą konfigurację, porównać wyniki po modyfikacji i ograniczyć ryzyko przypadkowego zablokowania prawidłowo wysyłanej poczty.