SPF, DKIM i DMARC: kontrole, polityki i ograniczenia

Widoczny adres nadawcy wiadomości e-mail można sfałszować. SPF, DKIM i DMARC pomagają sprawdzić użyte domeny. Poprawne uwierzytelnienie nie dowodzi jednak bezpieczeństwa treści ani tożsamości konkretnej osoby.

SPF sprawdza uprawnienie adresu IP do wysyłki, DKIM sprawdza podpis cyfrowy, a DMARC dodatkowo powiązanie z widoczną domeną nadawcy. O przyjęciu, filtrowaniu lub odrzuceniu wiadomości decyduje system odbiorczy. Wynik SPF fail może uzasadniać odrzucenie również bez DMARC.

SPF: czy adres IP pasuje do domeny koperty?

SMTP używa technicznego adresu koperty (MAIL FROM) obok widocznego nagłówka From. SPF zwykle sprawdza domenę koperty; przy pustym nadawcy koperty podstawą jest domena HELO. Sam wynik SPF pass nie uwierzytelnia więc widocznej domeny From.

Rekord DNS opisuje dozwolone źródła wysyłki. Dla pozostałych źródeł -all daje wynik fail, a ~all wynik softfail. Fail oznacza brak uprawnienia według danej reguły SPF, a nie pewny dowód fałszerstwa: także legalne przekazanie poczty może spowodować błąd SPF. Istnieją również wyniki neutral, none oraz błędy tymczasowe i trwałe.

Limit dziesięciu dotyczy ocenianych elementów SPF

Łącznie można ocenić najwyżej dziesięć elementów wywołujących zapytania DNS: include, a, mx, ptr, exists i redirect, wraz z zagnieżdżonymi sprawdzeniami. Nie jest to ogólny limit dziesięciu pakietów DNS. Dla niektórych zapytań obowiązują dodatkowe ograniczenia.

ip4, ip6 i all nie zużywają tego limitu. Wcześniejsze dopasowanie kończy ocenę, więc późniejsze odwołania nie są liczone. Przekroczenie limitu daje permerror dla konkretnego sprawdzenia. Zmiana u zewnętrznego dostawcy wysyłki może wywołać taki błąd, ale nie musi unieważniać każdej możliwej ścieżki oceny.

DKIM chroni podpisane części, nie każdy bajt

System wysyłający podpisuje wiadomość kluczem prywatnym. Odbiorca sprawdza podpis publicznym kluczem z DNS. Ochrona obejmuje podpisane nagłówki i objętą podpisem treść po określonej normalizacji. Wybrane reguły mogą pomijać niektóre różnice formatowania, na przykład zmiany części odstępów. Podpis może obejmować nawet tylko część treści. DKIM pass nie oznacza zatem, że każdy znak całej wiadomości pozostał niezmieniony.

Dla RSA dokument RFC 8301 wymaga co najmniej 1024 bitów i zaleca co najmniej 2048 bitów. Klucz 1024-bitowy nie jest według tej normy automatycznie nieważny, ale dla nowych konfiguracji RSA lepszą podstawą jest 2048 bitów. Ed25519 używa innych długości kluczy; bezpośrednie porównanie liczb z RSA byłoby mylące.

Długi klucz może zajmować jeden rekord TXT zawierający kilka ciągów po najwyżej 255 bajtów. Kilka ciągów w jednym rekordzie nie oznacza kilku osobnych rekordów TXT. Interfejs dostawcy DNS może automatycznie obsłużyć ten podział.

Właściwy selektor znajduje się jako s= w rzeczywistym nagłówku DKIM-Signature; d= wskazuje domenę podpisującą. Nazwa DNS ma postać selektor._domainkey.domena. Zgadywanie popularnych selektorów nie zastępuje tego sprawdzenia. Brak wyniku oznacza wyłącznie brak klucza pod sprawdzonymi nazwami.

DMARC wiąże uwierzytelnienie z widoczną domeną From

DMARC przechodzi, gdy co najmniej jeden poprawny wynik SPF lub DKIM jest zgodny z widoczną domeną From. Ta zgodność to alignment. Tryb ścisły wymaga identycznych domen; tryb łagodny wymaga tej samej domeny organizacyjnej zgodnie z zasadami wykrywania domen DMARC. Podobieństwo nazw domen nie wystarcza.

• p=none: brak żądania szczególnego traktowania na podstawie opublikowanej polityki DMARC.
• p=quarantine: wiadomości z niepoprawnym wynikiem DMARC powinny być traktowane jako podejrzane.
• p=reject: żądanie odrzucenia takich wiadomości.

Żadne ustawienie nie gwarantuje dostarczenia ani odrzucenia. Decydują lokalne reguły filtrowania. Żądanie raportów zbiorczych wymaga odpowiedniego adresu rua; samo p=none nie konfiguruje odbioru raportów. Nawet poprawny adres nie gwarantuje raportów od każdego systemu odbiorczego.

Rozsądne wdrożenie zaczyna się od spisu usług wysyłkowych oraz reprezentatywnych testów i raportów. Dotyczy to również faktur miesięcznych i rzadko używanych ścieżek. Następnie można dobrać bardziej rygorystyczną politykę. Protokół nie narzuca konkretnej liczby tygodni ani obowiązkowego etapu quarantine.

Co rzeczywiście pokazuje sprawdzenie DNS?

Kontroler uwierzytelniania poczty przedstawia stan rekordów DNS. Obecny licznik SPF analizuje odwołania statycznie zamiast symulować konkretną wiadomość i wysyłający adres IP. Rekordy MX nie dowodzą dostępności SMTP. Dla subdomeny może obowiązywać nadrzędna polityka DMARC, dlatego brak bezpośredniego rekordu nie dowodzi braku polityki.

Wiarygodny test wysyłki wymaga dodatkowo wiadomości z każdego legalnego systemu oraz wyników uwierzytelnienia w zaufanym systemie odbiorczym. Jednorazowy odczyt DNS nie przewidzi, czy każda sfałszowana wiadomość zostanie odrzucona.