Phishing najczęściej nie wymaga włamania do systemu, tylko dobrze podszytej wiadomości. DMARC to warstwa, która pomaga odbiorcy sprawdzić, czy e-mail rzeczywiście może uchodzić za wysłany z Twojej domeny, a jeśli nie, mówi, co z nim zrobić. W tym tekście pokazuję, jak ten mechanizm działa, jak go wdrożyć bez psucia dostarczalności i gdzie najczęściej pojawiają się błędy.
Najważniejsze rzeczy, które warto wiedzieć od razu
- To nie jest samodzielna tarcza, tylko warstwa nad SPF i DKIM.
- Decyzja opiera się na zgodności domeny widocznej dla odbiorcy z domeną, która przeszła autoryzację.
- Najbezpieczniej startować od monitoringu, a dopiero potem przechodzić do kwarantanny i odrzucania.
- Raporty pokazują, kto faktycznie wysyła pocztę w imieniu marki.
- Dla nadawców masowych Google i Yahoo wymagają dziś pełnej autoryzacji poczty, więc temat nie jest już opcjonalny.
Dlaczego podszywanie się pod domenę nadal działa
Najprostszy phishing nie wygląda jak atak. Wygląda jak zwykły mail od banku, kuriera, działu księgowości albo szefa, więc ofiara reaguje na autorytet, a nie na techniczne szczegóły wiadomości. Atakujący nie muszą łamać skrzynki odbiorczej, jeśli potrafią sprawić, że wiadomość przejdzie za czyjąś prawdziwą korespondencję.
W praktyce problem nie polega tylko na tym, że ktoś podszywa się pod nazwę nadawcy. Dużo ważniejsze jest to, że bez dodatkowej kontroli odbiorca nie ma prostego sposobu, by odróżnić legalny mail od fałszywki wysłanej z obcej infrastruktury. Ja traktuję to jako klasyczny problem zaufania do domeny, a nie samych treści wiadomości.
Właśnie dlatego ochrona domeny ma sens: ogranicza scenariusz, w którym zewnętrzny serwer próbuje wysłać wiadomość tak, jakby należała do Twojej organizacji. Żeby to działało, trzeba jednak zrozumieć, na czym opiera się decyzja o zaufaniu do nadawcy.
Jak działa sprawdzanie zgodności wiadomości
Mechanizm opiera się na trzech warstwach. SPF mówi, które serwery mogą wysyłać pocztę w imieniu domeny, DKIM dodaje podpis kryptograficzny, a warstwa polityki sprawdza, czy domena widoczna w polu From rzeczywiście zgadza się z tym, co zostało uwierzytelnione. Dopiero połączenie tych elementów daje sensowny wynik.
SPF i DKIM robią pierwszą kontrolę
SPF odpowiada na pytanie, czy dany adres IP ma prawo wysyłać pocztę dla domeny. DKIM sprawdza natomiast, czy wiadomość została podpisana i czy jej treść nie została po drodze naruszona. To dwa różne mechanizmy, więc jeden może przejść, a drugi nie, i to jest normalne.
Przeczytaj również: Jaki przewód do domofonu i bramy - uniknij kosztownych błędów
Zgodność domeny decyduje o wyniku
Tu wchodzi kluczowy warunek: domena widoczna dla odbiorcy musi zgadzać się z domeną, która przeszła autoryzację. Możesz mieć poprawny SPF albo DKIM, ale jeśli podpisana domena nie jest zgodna z tym, co widzi użytkownik w nagłówku From, odbiorca może potraktować wiadomość jak próbę podszycia się.
- Tryb relaxed dopuszcza zgodność z subdomeną, na przykład `mail.example.pl` i `example.pl`.
- Tryb strict wymaga dokładnie tej samej domeny po obu stronach.
Ja traktuję tę różnicę jak ustawienie precyzji. Relaxed jest zwykle bezpieczniejszy na start, strict przydaje się wtedy, gdy masz uporządkowaną infrastrukturę i chcesz mocniej domknąć ryzyko. Gdy rozumiesz już mechanikę zgodności, można przejść do wdrożenia bez rozbijania własnej wysyłki.
Jak wdrożyć ochronę bez ryzyka dla wysyłki
Ja zawsze zaczynam od mapy wszystkich źródeł wysyłki: poczty transakcyjnej, newsletterów, CRM, helpdesku, faktur, systemów kadrowych i narzędzi SaaS, które potrafią wysyłać maile w imieniu domeny. W małej organizacji taki audyt zwykle zamyka się w 1-2 dniach, ale przy wielu integracjach rozsądniej liczyć 4-6 tygodni na porządki i testy.
- Spisz wszystkie domeny i subdomeny, z których wychodzą wiadomości.
- Upewnij się, że SPF i DKIM są poprawnie skonfigurowane dla każdego źródła.
- Opublikuj pierwszy rekord w trybie monitorowania, zwykle zaczynając od
v=DMARC1; p=none; rua=mailto:.... - Sprawdzaj raporty zbiorcze i usuń niespodziewanych nadawców.
- Podnieś politykę do kwarantanny, a później do odrzucania.
Jeśli wysyłasz do dużych skrzynek, temat staje się jeszcze bardziej praktyczny: Google wymaga SPF, DKIM i tej warstwy dla nadawców wysyłających ponad 5000 wiadomości dziennie do Gmaila, a Yahoo oczekuje polityki ochronnej od nadawców masowych. Dlatego wdrożenie robię etapami, nie na skróty. Gdy mapa źródeł jest gotowa, najwięcej sensu ma praca z polityką i raportami.
Jak czytać polityki i raporty, żeby wyciągnąć z nich coś użytecznego
Najkrócej mówiąc, polityka określa reakcję odbiorcy, a raporty pokazują, kto wysyła pocztę i co z tego przechodzi. To właśnie z tych danych wychodzi, czy konfiguracja jest już gotowa na ostrzejsze ustawienia. Bez tego łatwo działać na wyczucie, a przy mailach to zwykle kończy się albo zbyt miękką ochroną, albo niepotrzebnymi blokadami.
| Polityka | Co robi | Kiedy ma sens | Ryzyko |
|---|---|---|---|
p=none |
Monitoruje i zbiera dane, ale nie blokuje wiadomości. | Na starcie wdrożenia i podczas audytu źródeł wysyłki. | Nie zatrzymuje spoofingu, daje tylko widoczność. |
p=quarantine |
Kieruje wiadomości do spamu lub kwarantanny. | Gdy większość legalnych nadawców jest już znana i poprawnie skonfigurowana. | Może złapać źle ustawione integracje i testowe systemy. |
p=reject |
Odrzuca wiadomość na etapie SMTP. | Gdy infrastruktura jest stabilna i dobrze opisana. | Najmniejszy margines błędu, więc wymaga dokładności. |
W praktyce największą wartość mają raporty zbiorcze (`rua`): pokazują źródła, wolumeny i wzorce błędów. Raporty szczegółowe (`ruf`) bywają ograniczane przez dostawców poczty, więc traktuję je raczej jako dodatek niż podstawę całej analizy. Jeśli raporty pokazują nieznane IP albo integracje, których nikt nie kojarzy, masz realny sygnał, że coś wysyła wiadomości w imieniu domeny bez kontroli.
Najczęstsze błędy, które psują skuteczność
Najwięcej problemów widzę wtedy, gdy ktoś chce szybko postawić ochronę, ale nie porządkuje najpierw źródeł wysyłki. Sama zmiana polityki nie naprawi chaosu w systemach, a przy poczcie chaos zawsze wraca jako fałszywe alarmy albo odrzucone maile.
- Za szybkie przejście na reject - jeśli nie znasz wszystkich nadawców, odetniesz legalny ruch zamiast ataku.
- Mylenie SPF pass z pełnym sukcesem - pozytywny wynik SPF nie wystarcza, jeśli domena From nie jest zgodna.
- Ignorowanie forwardingów i list dyskusyjnych - przekierowania potrafią psuć SPF, dlatego w trudniejszych ścieżkach pomaga ARC, czyli mechanizm zachowujący pierwotne wyniki autoryzacji po drodze.
- Brak inwentaryzacji SaaS-ów - narzędzia do faktur, marketingu czy HR często wysyłają wiadomości w Twoim imieniu, choć nikt ich nie uwzględnił w planie.
- Zapomniane subdomeny i domeny parkingowe - jeśli nie są objęte polityką, stają się miękkim punktem ataku.
- Mylenie ochrony domeny z ochroną konta - ten mechanizm nie zabezpiecza przed przejęciem skrzynki pracownika ani przed domenami podobnymi wizualnie do oryginału.
To ważne rozróżnienie: ten standard nie zatrzyma każdej formy oszustwa, ale bardzo dobrze ogranicza klasyczny spoofing. Chroni głównie przed podszywaniem się pod Twoją własną domenę, a właśnie ten scenariusz najczęściej podcina wiarygodność marki. To dobry moment, żeby zamknąć temat planem działania, a nie samą definicją.
Co robię najpierw, gdy porządkuję pocztę w firmie
Jeśli miałbym uruchamiać to od zera, zrobiłbym trzy rzeczy w tej kolejności: uporządkował źródła wysyłki, włączył monitoring, a dopiero potem zaczął zaostrzać politykę. To prostsze niż brzmi, a jednocześnie eliminuje większość fałszywych alarmów. W praktyce właśnie ten porządek robi największą różnicę między bezpieczną konfiguracją a elegancko wyglądającym wpisem w DNS.
- Zacznij od domen, które naprawdę wysyłają wiadomości do klientów i pracowników.
- Włącz raporty zbiorcze i sprawdzaj je regularnie, najlepiej co kilka dni na początku.
- Nie przechodź do kwarantanny, dopóki nie znasz wszystkich legalnych nadawców.
- Po stabilizacji ustaw ścisłą zgodność tam, gdzie ma to sens biznesowy.
Największą różnicę robi nie sam rekord w DNS, tylko dyscyplina operacyjna wokół poczty. Kiedy ta warstwa działa, phishing podszywający się pod domenę staje się wyraźnie trudniejszy, a zespół IT dostaje twarde dane zamiast domysłów.
