Klient widzi w polu „Od” nazwę firmy i podejmuje decyzję w kilka sekund. SPF, DKIM i DMARC pomagają odbiorcy ocenić, czy wiadomość używająca domeny firmy przeszła uzgodnione kontrole. Nie potwierdzają, że faktura jest prawdziwa, nadawca działa uczciwie ani treść jest bezpieczna.
To ważne przy oszustwie na fakturę z użyciem głosu AI: poprawny DMARC nie zatrzyma wiadomości wysłanej z podobnej domeny, przejętej prawdziwej skrzynki albo legalnej platformy użytej przez oszusta. Chroni konkretną domenę przed częścią podszyć, nie proces akceptacji płatności.
Trzy mechanizmy, trzy różne pytania
SPF publikuje w DNS, które serwery mogą wysyłać pocztę dla domeny użytej w technicznym adresie zwrotnym. Pomaga odbiorcy ocenić ścieżkę wysyłki. Nie podpisuje treści, nie potwierdza widocznego pola „Od” i bywa łamany przez przekazywanie poczty.
DKIM dodaje podpis wybranych nagłówków i treści przy użyciu klucza domeny. Odbiorca może sprawdzić, czy podpis pasuje i czy podpisane elementy nie zmieniły się po drodze. Poprawny podpis nie mówi, że autor wiadomości jest uczciwy; mówi, że operator domeny klucza podpisał tę postać wiadomości.
DMARC porównuje widoczną domenę „Od” z domeną, która przeszła SPF albo DKIM. Wiadomość przechodzi DMARC, gdy SPF lub DKIM jednocześnie przechodzi weryfikację i jest wyrównany z widoczną domeną „Od”. Opublikowana polityka dotyczy wiadomości, dla których żadna z tych dwóch ścieżek nie spełnia obu warunków. DMARC dostarcza też raporty o tym, kto wysyła, używając domeny.
SPF i DKIM mogą przejść, a DMARC nadal nie — jeśli domeny nie są wyrównane z widocznym „Od”. To nie błąd DMARC; to właśnie pytanie, na które ma odpowiedzieć.
Najpierw raporty, potem egzekwowanie
Rozsądne wdrożenie zaczyna się od inwentaryzacji wszystkich legalnych źródeł: głównej poczty, systemu faktur, CRM, newslettera, formularzy, helpdesku i urządzeń wysyłających alerty. Następnie:
- uporządkuj SPF i podpisy DKIM u każdego nadawcy
- opublikuj DMARC z polityką monitorującą
p=nonei adresem na raporty zbiorcze - obserwuj pełny cykl biznesowy, w tym wysyłki miesięczne i kampanie
- popraw legalne źródła, zamiast dodawać szerokie wyjątki
- przechodź etapami do
quarantine, a potemreject, jeśli dane potwierdzają gotowość
p=none nie blokuje podszyć. Jest etapem zbierania danych. Zbyt szybkie p=reject może odrzucić prawdziwe faktury lub powiadomienia, których nikt nie wpisał do inwentaryzacji.
Jak czytać raport zbiorczy
Raport XML podaje liczby wiadomości pogrupowane przede wszystkim według źródłowego IP i wyniku oceny polityki; zawiera też domeny oraz wyniki SPF i DKIM. Nie jest kopią skrzynki ani dowodem, że każde źródłowe IP jest napastnikiem.
Przy każdym większym źródle odpowiedz:
- czy to znany dostawca firmy
- jaka domena przeszła SPF
- jaki selektor i domena przeszły DKIM
- czy któraś domena jest wyrównana z widocznym „Od”
- ile wiadomości dotyczy wynik
- czy odbiorca zastosował opublikowaną politykę, czy lokalne odstępstwo
Trend i właściciel źródła są ważniejsze niż pojedynczy czerwony wiersz. Nowe legalne źródło bez właściciela jest problemem operacyjnym, nawet jeśli dostarczalność jeszcze działa.
Typowe błędy
- więcej niż jeden rekord SPF dla tej samej nazwy
- zbyt wiele zapytań DNS przez łańcuchy
include - pozostawione źródła po zmianie dostawcy
- DKIM włączony, ale dla innej domeny niż widoczne „Od”
- przejęty, błędnie opublikowany, zbyt długo używany albo przedwcześnie usunięty klucz DKIM
- raporty wysyłane do skrzynki, której nikt nie monitoruje
- przejście do
rejectbez sprawdzenia systemów okresowych - brak ochrony nieużywanych subdomen i domen podobnych należących do firmy
Zmiany DNS mają opóźnienie i wpływ na dostarczanie poczty. Każda powinna mieć właściciela, plan wycofania i test z kilku rzeczywistych ścieżek. Po wdrożeniu nadal potrzebne są MFA, ochrona kont, procedura zmiany rachunku i drugi kanał potwierdzenia płatności. SPF, DKIM i DMARC utrudniają część podszyć; nie kończą phishingu.