DMARC none

DMARC none to tryb polityki DMARC informujący jedynie o wyniku weryfikacji, bez podejmowania działań wobec niezgodnych wiadomości.

DMARC none – czym jest ten tryb polityki

DMARC none oznacza ustawienie, w którym właściciel domeny zbiera informacje o tym, jak wiadomości wysyłane z jego adresów przechodzą kontrolę uwierzytelniania, ale nie zleca automatycznego odrzucania ani oznaczania wiadomości niespełniających określonych warunków. Jest to tryb obserwacyjny, często wykorzystywany na początku porządkowania poczty elektronicznej. Pozwala sprawdzić, kto faktycznie wysyła wiadomości w imieniu domeny, z jakich źródeł pochodzą oraz czy konfiguracja pozostałych mechanizmów ochronnych jest spójna.

W praktyce polityka DMARC none nie zatrzymuje podejrzanej wiadomości tylko dlatego, że nie przejdzie kontroli DMARC. Decyzja o dostarczeniu, umieszczeniu wiadomości w folderze spamu albo jej odrzuceniu pozostaje po stronie systemu odbiorczego. Z tego powodu samo ustawienie none nie jest pełną ochroną przed podszywaniem się pod nadawcę. Jego głównym zadaniem jest dostarczenie danych potrzebnych do bezpiecznego zaplanowania dalszych zmian.

Informacja o trybie none znajduje się w rekordzie TXT opublikowanym dla nazwy _dmarc przed właściwą domeną. W uproszczonym przykładzie mogłoby to wyglądać tak: v=DMARC1; p=none. Taki zapis wskazuje, że domena uczestniczy w mechanizmie DMARC, lecz nie określa obowiązkowego sposobu postępowania z wiadomościami, które nie spełniają wymagań. W rozbudowanej konfiguracji mogą pojawić się również adresy do raportów, reguły dotyczące poddomen oraz sposób traktowania wiadomości wysyłanych z domeny organizacyjnej.

DMARC none a SPF, DKIM i zgodność domen

DMARC none nie działa samodzielnie. Ocena wiadomości opiera się na wynikach SPF oraz DKIM, a także na zgodności domen widocznych w tych wynikach z domeną używaną w polu From. SPF sprawdza, czy określony system jest uprawniony do wysyłania poczty z danej domeny. DKIM wykorzystuje podpis kryptograficzny do potwierdzenia, że wiadomość pochodzi z określonego źródła i nie została zmieniona w drodze do odbiorcy. DMARC łączy te informacje z adresem widocznym dla osoby odbierającej wiadomość.

Ważna jest tak zwana zgodność identyfikatorów. Pomyślne przejście SPF nie zawsze wystarczy, ponieważ domena sprawdzana przez SPF może różnić się od domeny pokazanej jako nadawca. Podobnie prawidłowy podpis DKIM może być powiązany z inną domeną niż ta umieszczona w polu From. Jeżeli nie ma zgodności, wiadomość może nie spełnić wymagań DMARC pomimo pozytywnego wyniku jednego z mechanizmów pomocniczych.

Przy polityce none takie przypadki są przede wszystkim rejestrowane w raportach. Dzięki temu można rozpoznać legalne źródła wysyłki, na przykład system do obsługi formularza kontaktowego, platformę do wysyłki biuletynu, aplikację księgową albo narzędzie do powiadomień. Raporty pozwalają też zauważyć próby podszywania się pod domenę. Nie każda pozycja w raporcie oznacza atak, ponieważ część rozbieżności wynika z przekazywania poczty, zmiany dostawcy lub niepełnej konfiguracji podpisów.

Porównanie DMARC none z innymi trybami jest proste. Tryb none służy do obserwacji i zbierania danych. Tryb określający kwarantannę sugeruje, aby wiadomości niespełniające warunków były traktowane ostrożniej, na przykład trafiały do spamu. Tryb odrzucenia wskazuje, że takie wiadomości mogą zostać odrzucone przez system odbiorczy. Przejście z none do bardziej restrykcyjnego ustawienia powinno być poprzedzone analizą legalnych źródeł wysyłki, ponieważ błędna zmiana może wpłynąć również na prawidłową korespondencję.

DMARC none – typowe problemy i błędne interpretacje

Najczęstszym nieporozumieniem jest traktowanie DMARC none jako ustawienia, które blokuje fałszywe wiadomości. W rzeczywistości jest to sygnał informacyjny. Osoba wysyłająca wiadomość podszywającą się pod daną domenę może nadal doprowadzić do jej dostarczenia, jeżeli system odbiorcy nie zastosuje dodatkowych filtrów. Z punktu widzenia bezpieczeństwa jest to etap rozpoznania sytuacji, a nie końcowy poziom ochrony.

Innym problemem jest brak dostępu do raportów albo ich nieczytelna konfiguracja. Sam rekord p=none nie pokazuje jeszcze, jakie źródła wysyłają pocztę. Do tego potrzebne są odpowiednie adresy raportowe i narzędzie, które potrafi uporządkować dane. Raporty mogą zawierać adresy techniczne, wyniki SPF i DKIM, nazwy domen oraz informacje o liczbie wiadomości obserwowanych przez dany system. Warto pamiętać, że raport zbiorczy nie jest zwykłą wiadomością przeznaczoną do czytania jak korespondencja, lecz dokumentem zawierającym dane kontrolne.

Problemy sprawia także zmiana dostawcy poczty bez aktualizacji wpisów DNS. Nowa usługa może wysyłać wiadomości z innego źródła, używać innego selektora DKIM albo wymagać dodania nowego uprawnienia SPF. Jeżeli takie zmiany nie zostaną odnotowane, raporty DMARC none będą pokazywać pozorne błędy. Podobnie może stać się po uruchomieniu systemu do faktur, formularza internetowego lub automatycznych powiadomień, gdy narzędzie wysyła pocztę w imieniu domeny, ale nie zostało prawidłowo uwierzytelnione.

Nie należy też kopiować gotowego rekordu z innej domeny bez sprawdzenia własnych potrzeb. Odmienne źródła wiadomości, inne poddomeny oraz różne wymagania dotyczące raportowania sprawiają, że poprawny zapis dla jednego właściciela domeny może być nieodpowiedni dla drugiego. Weryfikacja powinna obejmować dokładną nazwę rekordu, jego składnię oraz to, czy w DNS nie istnieją sprzeczne wpisy.

DMARC none – praktyczne wskazówki wdrożeniowe

Rozsądne wdrożenie warto rozpocząć od sporządzenia listy wszystkich miejsc, które wysyłają wiadomości z użyciem domeny. Należy uwzględnić zwykłą skrzynkę pocztową, formularze na stronie, systemy powiadomień, wysyłkę marketingową, automatyczne potwierdzenia oraz narzędzia używane przez pracowników. Następnie można sprawdzić, czy każde źródło ma prawidłowo skonfigurowany SPF lub DKIM i czy domena używana przez te mechanizmy jest zgodna z adresem widocznym dla odbiorcy.

W trybie DMARC none dobrze jest obserwować raporty przez czas obejmujący zwykłe dni pracy oraz okresy nietypowej aktywności, na przykład wysyłkę większej kampanii lub comiesięczne powiadomienia. Pojedynczy raport nie zawsze pokazuje pełny obraz. Dopiero zestawienie danych z wielu dni pozwala odróżnić stałe źródło wysyłki od jednorazowego zdarzenia. Przy analizie warto zwracać uwagę na źródła, które regularnie uzyskują negatywny wynik, oraz na te, które wysyłają wiadomości bez oczekiwanego podpisu.

Przed zmianą polityki należy potwierdzić, że legalne wiadomości przechodzą kontrolę niezależnie od tego, czy są wysyłane bezpośrednio, przekazywane przez zewnętrzną usługę, czy generowane automatycznie. Pomocne jest wykonanie testów z różnych formularzy i skrzynek, a także sprawdzenie nagłówków otrzymanych wiadomości. W nagłówkach można znaleźć informacje o wyniku SPF, DKIM i DMARC, chociaż sposób prezentacji zależy od systemu odbiorczego.

Warto prowadzić dokumentację zmian. Powinna obejmować datę modyfikacji rekordu, opis dodanego źródła, wynik testu oraz decyzję dotyczącą dalszego zaostrzenia zasad. Taki zapis ułatwia późniejsze znalezienie przyczyny, gdy po zmianie dostawcy lub aplikacji część wiadomości zacznie być oceniana inaczej. Należy również pamiętać o czasie potrzebnym na odświeżenie danych DNS, ponieważ aktualizacja nie zawsze jest widoczna natychmiast we wszystkich miejscach.

DMARC none – kiedy potrzebna jest pomoc serwisu

Do serwisu warto zgłosić się wtedy, gdy problem z pocztą pojawia się razem z innymi objawami technicznymi, na przykład trudnościami z działaniem programu pocztowego, błędami systemu, utratą dostępu do ustawień albo nieprawidłowym działaniem urządzenia używanego do obsługi korespondencji. Pomoc może obejmować uporządkowanie objawów, sprawdzenie podstawowej konfiguracji oraz przygotowanie informacji potrzebnych do dalszej konsultacji z administratorem domeny lub dostawcą poczty.

Warszawskie Pogotowie Komputerowe 24/7 zajmuje się wsparciem przy problemach ze sprzętem komputerowym, które mogą utrudniać codzienną pracę z pocztą i innymi aplikacjami. W przypadku DMARC none szczególnie przydatne jest rozdzielenie problemu urządzenia od problemu konfiguracji domeny. Jeżeli program pocztowy działa nieprawidłowo, ale rekord DNS jest poprawny, przyczyna może leżeć lokalnie. Jeżeli natomiast urządzenie działa prawidłowo, a raporty wskazują na niezgodność źródeł wysyłki, potrzebna może być analiza ustawień domeny i usług pocztowych.

Przed zgłoszeniem problemu dobrze przygotować przykładowe daty, adres nadawcy, adres odbiorcy, opis oczekiwanego rezultatu oraz informację, czy trudność dotyczy wszystkich wiadomości, czy tylko korespondencji wysyłanej przez konkretną aplikację. Nie powinno się przekazywać haseł ani pełnych treści prywatnych wiadomości, jeśli nie jest to konieczne. Wystarczające bywają zanonimizowane nagłówki i opis błędu.

DMARC none jest użytecznym etapem przejściowym, ponieważ pokazuje, co dzieje się z pocztą domenową, zanim zostaną wprowadzone bardziej stanowcze reguły. Nie należy jednak utożsamiać go z aktywnym blokowaniem podszywania się pod nadawcę. Najważniejsze jest zebranie danych, rozpoznanie legalnych źródeł wysyłki, poprawienie SPF i DKIM oraz dopiero późniejsze podjęcie decyzji o zmianie polityki. Takie podejście ogranicza ryzyko zakłócenia prawidłowej korespondencji i ułatwia utrzymanie spójnej konfiguracji.