Trzy kontrole w jednej tabeli
| Kontrola | Co sprawdza | Gdzie szuka |
|---|---|---|
| SPF | Czy serwer, który dostarczył wiadomość, jest na liście dozwolonych nadawców domeny? | Rekord DNS domeny użytej w ukrytym adresie nadawcy koperty (Return-Path). |
| DKIM | Czy podpis kryptograficzny wiadomości zgadza się z kluczem publicznym domeny nadawcy i czy wiadomość nie została zmieniona? | Nagłówek DKIM-Signature i klucz publiczny w DNS. |
| DMARC | Czy SPF lub DKIM przeszły i zgadzają się (są zgodne) z domeną widoczną w polu Od? Co zrobić, jeśli nie? | Polityka DMARC w DNS dla domeny z pola Od: none, quarantine albo reject. |
Najważniejsza jest zgodność domen (alignment). SPF i DKIM same w sobie mogą przejść dla dowolnej domeny, którą kontroluje atakujący. DMARC wiąże je z widocznym adresem Od. Google opisuje to tak: żeby przejść DMARC, wiadomość musi przejść co najmniej jedną z kontroli, SPF ze zgodnością SPF albo DKIM ze zgodnością DKIM.
Gdzie zobaczyć wynik
Wyniki są w nagłówku Authentication-Results. Otwórz pełne nagłówki i poszukaj linii takich jak te:
spf=fail [email protected]
dkim=none
dmarc=fail (p=REJECT) header.from=examplebank.com- pass: kontrola się powiodła.
- fail: kontrola się odbyła i nie przeszła. Dla SPF to twarde niepowodzenie. Możesz też zobaczyć softfail (domena mówi „raczej niedozwolony”) albo neutral.
- none: nie było czego sprawdzać, na przykład domena nie publikuje podpisu DKIM ani rekordu DMARC. To brak zabezpieczenia, a nie niepowodzenie.
- temperror / permerror: problem z DNS albo uszkodzony rekord. Mówi to więcej o konfiguracji nadawcy niż o samej wiadomości.
Dlaczego przekazana poczta często ma fail
Prawdziwa poczta oblewa te kontrole częściej, niż się wydaje, a klasyczną przyczyną jest przekazywanie.
- SPF psuje się przy przekazaniu wiadomości. SPF sprawdza adres IP serwera, który przekazał wiadomość. Po przekazaniu jest to serwer przekazującego, a nie pierwotnego nadawcy, więc nie ma go na liście pierwotnej domeny.
- DKIM przeżywa przekazanie, o ile wiadomość nie zostanie zmieniona. Listy dyskusyjne dopisujące stopkę lub zmieniające temat oraz niektóre bramki bezpieczeństwa przepisujące linki unieważniają podpis.
- DMARC kończy się więc failem tylko wtedy, gdy zepsują się oba mechanizmy, albo gdy ten, który przeszedł, nie jest zgodny z domeną z pola Od.
- Inne uprawnione przyczyny: usługa marketingowa lub rozliczeniowa wysyła w imieniu firmy bez wpisania jej do SPF i DKIM, zapomniany rekord DNS po zmianie dostawcy albo literówka w rekordzie.
Kiedy fail wskazuje na podszywanie się
Fail staje się czerwoną flagą, gdy występuje razem z innymi sygnałami. Potraktuj go poważnie, kiedy:
- Domena w polu Od należy do banku, kuriera, urzędu albo firmy, która wyraźnie stosuje ścisłą politykę DMARC, a wiadomość nie przechodzi DMARC.
- SPF przechodzi, ale dla niezwiązanej domeny w Return-Path (wiadomość jest uwierzytelniona, tylko nie jako marka, za którą się podaje).
- Wiadomość prosi o hasło, płatność, kod lub logowanie albo popędza.
- Reply-To lub linki prowadzą do innej domeny niż nadawca.
- Domena nadawcy to sobowtór, na przykład
examp1ebank.comzamiastexamplebank.com. Sobowtóry często przechodzą uwierzytelnienie, bo domena należy do atakującego.
Co zrobić z failem
- Nie klikaj linków i nie otwieraj załączników z wiadomości, dopóki się nie zdecydujesz.
- Sprawdź, czy wiadomość ma sens w kontekście: czy była oczekiwana i czy taka prośba jest normalna dla tego nadawcy?
- Jeśli masz wątpliwości, skontaktuj się z nadawcą kanałem, któremu już ufasz, na przykład przez oficjalną aplikację albo numer ze strony firmy, a nie przez samą wiadomość.
- Przepuść całą wiadomość przez narzędzie, które waży uwierzytelnienie razem z linkami, treścią i załącznikami.
- Jeśli to phishing, zgłoś go.
Jeśli fail dotyczy poczty z Twojej własnej domeny, poprawka leży po stronie DNS: dopisz usługę wysyłającą do rekordu SPF, włącz dla niej podpisywanie DKIM, a potem opublikuj politykę DMARC, przechodząc stopniowo od monitorowania do egzekwowania.