Adres widoczny w polu From nie jest samodzielnym dowodem, że wiadomość rzeczywiście pochodzi od firmy. Podszywanie się pod domenę może służyć do phishingu, przesyłania fałszywych faktur albo osłabiania zaufania klientów i dostawców do firmowej poczty. Dlatego bezpieczna poczta elektroniczna wymaga nie tylko ostrożności użytkowników, lecz także technicznego uwierzytelniania wiadomości.
SPF, DKIM i DMARC dla firmy to zestaw uzupełniających się mechanizmów. SPF sprawdza źródło wysyłki, DKIM pozwala zweryfikować podpis kryptograficzny, a DMARC odnosi wyniki tych kontroli do domeny widocznej dla odbiorcy. W tym artykule omawiam praktyczny sposób sprawdzania konfiguracji, typowe przyczyny odrzucania prawidłowej poczty oraz połączenie ochrony domeny przed spoofingiem z procedurą reagowania na fałszywe e-maile. To materiał edukacyjny, a nie indywidualna instrukcja konfiguracji konkretnej domeny.
Dlaczego firmowa domena może być wykorzystywana w fałszywych wiadomościach
Techniczny adres użyty do wysłania wiadomości i adres pokazany odbiorcy nie muszą oznaczać dokładnie tego samego. W praktyce pole From może wyglądać jak adres pracownika, działu księgowości albo zarządu, choć sama wiadomość została wysłana z innego źródła. Sam wygląd nadawcy nie potwierdza więc autentyczności korespondencji.
Fałszywe wiadomości z domeny firmy mogą nakłaniać do kliknięcia linku, otwarcia załącznika, zmiany danych płatniczych lub przekazania informacji. Mogą też kierować odbiorcę do kontaktu z osobą, która jedynie udaje przedstawiciela organizacji. Z perspektywy firmy problemem jest nie tylko pojedynczy incydent, lecz także ryzyko utraty zaufania do wszystkich wiadomości wysyłanych z jej domeny.
SPF, DKIM i DMARC ograniczają ryzyko podszywania się pod domenę, ale nie zapewniają pełnej ochrony przed phishingiem. Nie zastępują ochrony kont, uwierzytelniania wieloskładnikowego, filtrów antyphishingowych, szkoleń ani procedur obsługi incydentów. Ich zadaniem jest dostarczenie odbiorcy informacji, czy źródło i sposób uwierzytelnienia wiadomości są zgodne z polityką domeny.
SPF, DKIM i DMARC — trzy różne mechanizmy
Choć te trzy skróty często występują razem, każdy opisuje inną kontrolę. Ich wspólnym celem jest ograniczenie nadużyć związanych z pocztą, lecz wyniki SPF i DKIM nie są tym samym co wynik DMARC.
SPF jako autoryzacja źródła wysyłki
SPF wskazuje, które hosty mogą wysyłać wiadomości z użyciem domeny w identyfikatorze MAIL FROM albo HELO/EHLO. Odbiorca porównuje źródło wysyłki z informacją opublikowaną dla domeny w DNS. Wynik SPF dotyczy zatem autoryzacji serwera lub innego źródła wysyłki, a nie całej wiadomości widocznej dla odbiorcy.
To rozróżnienie ma znaczenie diagnostyczne. Wiadomość może przejść kontrolę SPF, ponieważ pochodzi z autoryzowanego źródła, ale nadal nie spełniać wymagań DMARC, jeśli domena użyta w SPF nie jest zgodna z domeną widoczną w polu From. SPF nie potwierdza również, że treść wiadomości nie została zmieniona.
DKIM jako podpis i kontrola integralności
DKIM dodaje do wiadomości podpis kryptograficzny umieszczany w jej nagłówku. Odbiorca pobiera klucz publiczny z DNS domeny wskazanej w podpisie, a następnie sprawdza podpis oraz to, czy podpisana część wiadomości nie została zmieniona. Mechanizm pozwala więc zweryfikować domenę podpisującą i integralność określonej zawartości.
DKIM nie jest szyfrowaniem wiadomości. Nie ukrywa jej treści przed odbiorcą, lecz pomaga sprawdzić autentyczność podpisu i wykryć modyfikację podpisanej części. Jeżeli wiadomość po drodze zmieni bramka, lista mailingowa, reguła transportowa albo inny system, podpis może przestać być poprawny.
DMARC jako kontrola zgodności domen
DMARC odnosi wyniki SPF i DKIM do domeny widocznej w polu From. Sprawdza więc nie tylko, czy SPF lub DKIM zakończyły się powodzeniem, lecz także czy domena uwierzytelniona przez dany mechanizm jest zgodna z domeną przedstawioną odbiorcy. Do uzyskania wyniku DMARC pass wystarczy prawidłowy i zgodny z domeną From wynik SPF albo DKIM.
DMARC pozwala właścicielowi domeny opublikować politykę obsługi wiadomości, które nie spełniają wymagań, oraz odbierać raporty. Nie zastępuje SPF i DKIM, ale wykorzystuje ich wyniki do szerszej oceny. Dzięki raportom można analizować źródła wysyłki, liczbę wiadomości, zastosowaną dyspozycję oraz to, czy mechanizmy przeszły również kontrolę zgodności domen.
Jak sprawdzić konfigurację domeny firmowej
Sprawdzenie domeny nie powinno ograniczać się do potwierdzenia, że w DNS istnieją jakieś rekordy. Sama obecność rekordów nie dowodzi, że wszystkie legalne systemy firmy wysyłają wiadomości prawidłowo. Konfigurację trzeba odnieść do rzeczywistego modelu wysyłki.
Od inwentaryzacji nadawców do analizy raportów
Pierwszym krokiem jest zinwentaryzowanie wszystkich legalnych źródeł poczty. Należy uwzględnić nie tylko podstawową usługę pocztową, lecz także usługi zewnętrzne i systemy używane przez firmę. Wśród nich mogą znajdować się:
- systemy CRM i marketing automation;
- fakturowanie, formularze oraz helpdesk;
- newslettery, urządzenia i zewnętrzne bramki pocztowe.
Następnie trzeba sprawdzić rekord SPF, konfigurację kluczy DKIM oraz rekord DMARC. Wartości zależą od dostawcy poczty, usług zewnętrznych i modelu wysyłki, dlatego nie należy traktować przypadkowego przykładu jako gotowego rekordu do skopiowania.
Kolejnym etapem jest wysłanie wiadomości testowych i analiza pełnego nagłówka Authentication-Results. W nagłówku można znaleźć wyniki spf, dkim i dmarc oraz informacje o domenach użytych do sprawdzenia zgodności. Szczególnie istotne są domeny odpowiadające za smtp.mailfrom, header.d i header.from, ponieważ pozwalają odróżnić sam wynik mechanizmu od zgodności wymaganej przez DMARC.
Trzeba również analizować raporty DMARC. Mogą one wskazywać adresy IP wysyłające wiadomości, ich liczbę, zastosowaną dyspozycję oraz wyniki uwierzytelnienia i zgodności domen. Nieznane źródło może oznaczać nieautoryzowaną wysyłkę, ale może też wskazywać pominiętą usługę używaną legalnie przez firmę. Dlatego każdy wynik wymaga odniesienia do wcześniejszej inwentaryzacji.
Najczęstsze błędy i odrzucenia prawidłowej poczty
Nieprawidłowa konfiguracja może sprawić, że prawidłowa wiadomość zostanie odrzucona albo trafi do kwarantanny. Jedną z typowych przyczyn błędu SPF jest opublikowanie więcej niż jednego rekordu SPF dla tej samej domeny lub subdomeny. Problemem może być również przekroczenie limitu 10 zapytań DNS podczas sprawdzania SPF.
Źródłem kłopotów bywa także uruchomienie nowej usługi zewnętrznej bez uwzględnienia jej w modelu uwierzytelniania. Usługa może nie być objęta SPF albo może nie podpisywać wiadomości DKIM. W takim przypadku podstawowy system pocztowy może działać prawidłowo, a wiadomości z CRM, newslettera czy formularza będą uznawane za niezgodne.
Wynik SPF lub DKIM pass nie zawsze wystarcza do uzyskania DMARC pass. Jeżeli domena użyta w SPF albo domena podpisująca DKIM nie jest zgodna z domeną w polu From, kontrola DMARC może się nie powieść. Przyczyną może być także używanie różnych domen przez firmę i dostawcę zewnętrznego.
Osobną grupę problemów tworzy przekazywanie wiadomości. Przekazanie dalej może złamać zgodność SPF, a zmiana treści przez bramkę, listę mailingową lub regułę transportową może unieważnić podpis DKIM. Przed zmianą DNS lub polityki trzeba więc sprawdzić pełne nagłówki i informacje o odrzuceniu, zamiast zakładać, że winny jest tylko jeden rekord.
Błędna polityka DMARC może powodować kwarantannę albo odrzucanie prawidłowych wiadomości. Szczególnie ryzykowne jest zaostrzenie ustawień przed rozpoznaniem wszystkich legalnych nadawców. Diagnostyka powinna obejmować źródło wysyłki, zgodność domen, przekazywanie i modyfikacje treści.
Wdrażanie DMARC etapami i monitorowanie
Wdrożenie DMARC warto traktować jako proces monitorowania, testowania i porządkowania źródeł wysyłki, a nie jako jednorazową zmianę w DNS. Przed zaostrzeniem polityki trzeba zinwentaryzować legalne systemy, w tym CRM, marketing automation, fakturowanie, formularze, helpdesk, newslettery, urządzenia i zewnętrzne bramki.
Etap monitorowania pozwala porównać raporty DMARC z rzeczywistą listą usług. Polityka p=none może służyć do obserwacji wyników przed zaostrzeniem egzekwowania polityki, ale sama nie oznacza pełnej ochrony. Jej sens zależy od regularnego analizowania raportów i usuwania niezgodności.
Zmiany powinny być testowane etapami i dokumentowane. Warto zapisywać, który system wysyła pocztę, z jakiej domeny korzysta, czy używa SPF lub DKIM oraz jakie wyniki pojawiają się w nagłówkach i raportach. Szczegółowe ustawienia zależą od dostawcy poczty, usług zewnętrznych i modelu wysyłki. Nie ma jednego ustawienia właściwego dla każdej firmy.
Procedura reagowania na fałszywy e-mail
Ochrona domeny powinna być połączona z prostą procedurą dla pracowników. Gdy wiadomość wygląda na fałszywą lub podejrzaną, nie należy klikać zawartych w niej linków ani otwierać załączników. Trzeba zachować wiadomość z pełnymi nagłówkami, ponieważ sam zrzut ekranu często nie wystarcza do analizy.
Procedura powinna wskazywać, gdzie pracownik zgłasza incydent i kto analizuje nagłówki. Administrator lub dostawca poczty może sprawdzić wyniki spf, dkim i dmarc, źródło wysyłki oraz informacje o przekazywaniu. Warto także przeanalizować logowania do konta i reguły przekierowań, zgodnie z procedurami obowiązującymi w organizacji.
Jeżeli istnieje podejrzenie przejęcia konta, sama konfiguracja DNS nie wystarczy. Działania administracyjne mogą obejmować reset poświadczeń, unieważnienie sesji i weryfikację MFA, wykonywane zgodnie z procedurami organizacji. Nie należy jednak traktować tych czynności jako uniwersalnej instrukcji dla każdego środowiska, ponieważ zakres reakcji zależy od używanej usługi i ustaleń wewnętrznych.
Procedura powinna określać również, kiedy informować klientów, dostawców lub innych odbiorców. Ma to znaczenie wtedy, gdy fałszywa wiadomość mogła wywołać skutki biznesowe, na przykład skłonić odbiorcę do płatności albo przekazania danych. Równolegle warto regularnie przeglądać raporty DMARC, monitorować nieznane źródła wysyłki i analizować podejrzane wiadomości.
SPF, DKIM i DMARC pełnią różne, uzupełniające się funkcje: autoryzują źródło, weryfikują podpis i kontrolują zgodność z domeną From. Praktyczna kontrola powinna obejmować inwentaryzację nadawców, sprawdzenie DNS, analizę Authentication-Results, przegląd raportów DMARC oraz etapowe testowanie zmian. Mechanizmy te ograniczają ryzyko podszywania się, ale nie zastępują ochrony kont, MFA, filtrów, szkoleń i procedury incydentowej. Sprawdź inne materiały Łączy nas Biznes i rozwijaj firmę w oparciu o praktyczną, aktualną wiedzę.
