Brak uwierzytelnienia nadawcy stanowi poważne zagrożenie dla bezpieczeństwa poczty elektronicznej. Jego konsekwencją jest m.in. oznaczanie wysyłanych wiadomości jako spam. Aby poradzić sobie z tym problemem, stosuje się protokoły SPF, DKIM i DMARC. Przyjrzyjmy się, jak one działają.

Protokół SMTP stosowany w poczcie elektronicznej nie wykorzystuje żadnej formy uwierzytelniania nadawcy. Serwer pocztowy nie jest w stanie określić, czy adres i dane nadawcy są ze sobą zgodne. Niesie to ze sobą poważne konsekwencje, związane z wysyłaniem maili phishingowych czy spamowych, podszywających się pod daną domenę.

W związku z tym używane są osobne protokoły do autoryzowania tożsamości nadawcy. Chodzi o SPF, DKIM oraz DMARC – każdy z nich ma trochę inne działanie. Jednak dopiero wykorzystanie tych 3 protokołów jednocześnie jest w stanie umożliwić skuteczną weryfikację i ochronę przed nieautoryzowanymi wiadomościami.

Co to jest uwierzytelnianie i dlaczego jest tak ważne?

Uwierzytelnianie ma na celu potwierdzenie, że nadawca faktycznie jest autorem danej wiadomości e-mail. Dzięki temu odbiorca może bezpiecznie otworzyć wiadomość, bez obaw, że pojawiła się jakakolwiek ingerencja w treść wiadomości.

Bez takiego uwierzytelniania nie ma żadnej pewności, że dana wiadomość została faktycznie napisana i wysłana przez daną osobę. Niezweryfikowane wiadomości:

• mogą mieć na celu phishing – czyli wyłudzanie danych,
• mogą zawierać wirusy lub inne złośliwe oprogramowanie,
• mogą być zwykłym spamem.

Jednak warto mieć świadomość, że brak uwierzytelniania jest zagrożeniem nie tylko dla odbiorcy. Ta kwestia rodzi także poważne konsekwencje dla nadawcy wiadomości. Otóż ochrona antyspamowa serwera może automatycznie zakwalifikować daną wiadomość jako niebezpieczną. W konsekwencji rzeczywiste wiadomości wysłane przez nadawcę będą lądować w folderze spam, zamiast w skrzynce odbiorczej.

Z czego składa się wiadomość?

Każda wiadomość e-mail wysyłana za pośrednictwem SMTP składa się z kilku elementów:

• koperty SMTP – zawierającej informacje o adresie nadawcy (pole MAIL FROM) i odbiorcy (pole RCPT TO). Ta część jest wykorzystywana do komunikacji pomiędzy serwerami i zwykle nie jest dostępna dla użytkowników poczty,
• nagłówków – czyli m.in. danych nadawcy i adresata, daty i tematu wiadomości,
• treści właściwej wiadomości.

Wiadomość składa się z koperty SMTP, nagłówków oraz treści (źródło: mybluelinux.com)

Problemem jest to, że adresy w kopercie SMTP wcale nie muszą zgadzać się z tymi w nagłówku (m.in. ze względu na kwestię obsługi zwrotów przy masowych wysyłkach czy przy forwardowaniu). Sam protokół w żaden sposób ich nie weryfikuje. Bierze za pewnik, że nadawca jest faktycznie osobą, za którą się podaje.

SPF – schemat działania

SPF (Sender Policy Framework) to protokół mający na celu poprawę bezpieczeństwa poczty elektronicznej – zapewniając podstawową weryfikację tożsamości nadawcy (domeny). Właściciel domeny wskazuje w odpowiednio sformatowanym rekordzie DNS typu TXT, nazywanym też „rekordem SPF”, z jakiego adresu (adresów) IP możliwa jest wysyłka wiadomości. 

W przypadku serwera wykorzystującego protokół SPF schemat działania prezentuje się następująco:

1. Serwer odbiorcy pobiera z wiadomości e-mail domenę podaną w polu MAIL FROM (w kopercie SMTP).
2. Serwer odbiorcy pobiera konfigurację SPF zapisaną w rekordach DNS domeny nadawcy.
3. Następuje weryfikacja, czy adres IP, z którego serwer odbiorcy otrzymał e-mail, może korzystać z danej domeny.

              a) Jeżeli nie może – następuje odrzucenie przychodzącej wiadomości.
              b) Jeżeli może – wiadomość jest przyjęta przez serwer.

Oczywiście wcześniej administrator domeny, z której wysyłana jest poczta, musi ustawić odpowiednie rekordy DNS dotyczące konfiguracji SPF.

Schemat działania protokołu SPF (źródło: cyberpunk.rs)

Rekord SPF dla danej domeny można samodzielnie sprawdzić z poziomu linii poleceń za pomocą polecenia dig domena.tld TXT w przypadku Linuxa i macOS lub nslookup -type=txt domena.tld w Windowsie. Zapytanie to zwróci wszystkie rekordy tekstowe (TXT) dla danej domeny. Rekord SPF rozpoznamy od ciągu „v=spf1” oznaczającego jego wersję (obecnie jest tylko jedna wersja). Dodatkowo powinien być tylko jeden taki rekord. W przypadku gdy jest ich więcej, maile wysłane z danej domeny nie przejdą weryfikacji SPF.

Następnie, po ciągu „v=spf1”, w rekordzie SPF użyty może zostać jeden lub wiele mechanizmów, określających nadawców, którzy mogą (lub nie, w zależności od użytego modyfikatora) wysyłać maile z danej domeny, takich jak:

• a – wskazujący na adres IP podany w rekordzie A serwerów DNS,
• mx – to samo, ale wskazanie na adres IP podany w rekordzie MX,
• ip4 – wskazanie jednego lub więcej adresów IPv4 (np. ip4:123.4.5.6),
• ip6 – to samo, ale z adresem IPv6 (np. ip6:2001:db8:3333:4444:5555:6666:7777:8888),
• include – odwołanie do rekordu SPF innej domeny (np. include:spf.domain.tld).

Rekord SPF zakończony jest najczęściej jednym z 3 oznaczeń:

• ~all – podstawowe ustawienie, które pozwala serwerowi sprawdzającemu wiadomość podjąć decyzję, co zrobić z mailem, który pochodzi z serwerów spoza listy – może je odrzucić lub umieścić w spamie,
• -all – znaczy tyle, co „nie przyjmuj wiadomości od serwerów spoza tej listy”,
• +all – najmniej restrykcyjny i pozwalający przyjmować wiadomości także od serwerów spoza listy z rekordu SPF.

Modyfikatorów ~, - i + można używać także do wspomnianych wcześniej mechanizmów innych niż all (który obowiązkowy nie jest) takich jak include czy mx, tworząc tym samym politykę SPF, która dokładnie określa, jakie serwery mogą, a jakie nie mogę wysyłać maili z danej domeny i jak powinien na nie reagować serwer odbierający e-mail.

Wynik dla zapytania o domenę google.com. Rekord SPF zaznaczony na czerwono

Protokół SPF nie jest oczywiście rozwiązaniem idealnym. Należy pamiętać, że odnosi się on wyłącznie do weryfikacji adresu podanego w polu MAIL FROM w kopercie SMTP. Nie redukuje on ryzyka zmiany adresu w nagłówku wiadomości From widocznym dla użytkownika. A zatem odbiorca w dalszym ciągu nie ma pewności, że nadawca podany w wiadomości e-mail faktycznie jest autorem wiadomości.

DKIM – schemat działania

DKIM (DomainKeys Identified Mails) do weryfikacji domeny i nadawcy stosuje podpis cyfrowy wiadomości e-mail (domyślnie oparty o algorytm rsa-sha256). W praktyce wygląda to w następujący sposób:

1. W rekordach DNS umieszczony jest klucz publiczny dla danej domeny.
2. Do nagłówków wysyłanej wiadomości e-mail dołączany jest jej podpis cyfrowy, utworzony przy użyciu klucza prywatnego.
3. Serwer odbiorcy pobiera rekord DKIM zawierający klucz publiczny danej domeny.
4. Następuje weryfikacja, czy podpis wiadomości jest zgodny z kluczem publicznym

              a) Jeżeli nie jest zgodny – następuje odrzucenie przychodzącej wiadomości.
              b) Jeżeli jest zgodny – wiadomość zostaje przyjęta. 

Schemat działania protokołu DKIM (źródło: chronicbit.blogspot.com)

Podobnie jak w SPF, tak i rekord DKIM można sprawdzić samodzielnie. Wystarczy znać tzw. selector, czyli identyfikator klucza publicznego (każda domena może mieć ich wiele), który dołączany jest wraz z podpisem cyfrowym do nagłówków wysłanych wiadomości e-mail. Można znaleźć go w nagłówku DKIM-Signature podpisanej wiadomości e-mail jako s (np. s=nazwa_selectora).

Rekord DKIM możemy sprawdzić poleceniem dig txt selector._domainkey.domena.tld (w przypadku Linuxa i macOS) lub nslookup set q=txt selector._domainkey.domena.tld (w Windowsie). Zapytanie zwróci klucz publiczny z rekordu DNS.

Wynik zapytania o selektor 20161025 dla domeny google.com

Kryptograficzne zabezpieczenie DKIM zapewnia ochronę przed podszyciem się kogoś pod nadawcę wiadomości – tylko nadawca dysponujący kluczem prywatnym, który zgodny jest z kluczem publicznym wpisanym w DNS, jest w stanie cyfrowo podpisać wiadomość. W tym przypadku weryfikowane jest to, czy nadawca wiadomości dysponując kluczem prywatnym, jest w stanie podpisać wysłaną wiadomość (zarówno nagłówki, jak i jej treść). Wiadomość zostanie odrzucona, gdy podpis cyfrowy nie będzie pasował do klucza publicznego, a więc znacząco maleje ryzyko podszycia się pod domenę.

DMARC – schemat działania

DMARC (Domain-based Message Authentication, Reporting and Conformance) to rozwiązanie, które opiera się na dwóch wcześniejszych protokołach. Tak naprawdę DMARC określa politykę serwerów oraz udostępnia informacje dotyczące tego, w jaki sposób ma zadziałać serwer w przypadku otrzymania nieautoryzowanej wiadomości (takiej, która nie przeszła pozytywnej weryfikacji poprzez SPF i DKIM).

Schemat działania protokołu DMARC (źródło: returnpath.com)

Podobnie jak w przypadku SPF i DKIM, możemy sprawdzić obecność (i zapisy) polityki DMARC z poziomu wiersza poleceń, wykorzystując polecenie dig txt _dmarc.domena.tld dla macOS i Linuxa oraz nslookup -type=txt _dmarc.domena.tld dla Windowsa.

Wynik zapytania o DMARC domeny google.com

DMARC daje także wskazówki dla serwera odbiorcy, w jaki sposób ma działać podczas błędów weryfikacji wspomnianych wcześniej SPF i DKIM – np. czy wiadomość ma zostać skierowana do spamu, czy też powinna zostać od razu usunięta. Dzięki połączeniu dwóch protokołów zabezpieczających – możliwe jest wyeliminowanie słabych punktów każdego z nich. Tym samym DMARC przyczynia się do lepszego wyłapywania maili spamowych oraz większej dostarczalności poprawnych wiadomości. W nazwie protokołu znajduje się także raportowanie, dzięki któremu otrzymamy podsumowującą informację zwrotną w przypadku nieautoryzowanego działania.

O czym należy pamiętać?

Zgodnie z danymi za 2019 r. 80% skrzynek poczty elektronicznej obsługuje DMARC, jednak zaledwie 17% z nich jest poprawnie skonfigurowanych*, czyli takich, które zawierają ustaloną politykę postępowania dla serwera odbiorczego. Sama obsługa tych protokołów przez serwer nie będzie pełnić swoich funkcji przed ich włączeniem czy wprowadzeniem ustawień.

Wiele dostawców usług hostingowych, oferujących ochronę poczty e-mail, z automatu generuje rekordy SPF, DKIM i DMARC oraz publikuje je na serwerach DNS. W przeciwnym wypadku należy wpisać je samodzielnie.

Rekordy DNS można wyedytować najczęściej poprzez panel hostingowy. W zależności od konkretnego dostawcy usług taka opcja może być umieszczona w różnych miejscach. Najczęściej będą to pola typu „Zabezpieczenia domeny” czy „Edytor stref DNS”. Na przykład podczas dodawania rekordu DMARC można podać adres e-mail oraz dokonać konfiguracji, wskazując m.in.:

• jak ma się zachować serwer odbiorcy w przypadku niezgodności z SPF i DKIM,
• na jaki adres mają przychodzić raporty bezpieczeństwa poczty e-mail.

Jak to w praktyce zrobić?

Treść rekordu jest zazwyczaj krótka, ale zawiera kilka istotnych elementów. Pierwszy z nich (v=DMARC1) określa – tak jak i w poprzednich przykładach – rekord DMARC i jego wersję. Co jednak mamy dalej?

p – ten tag określa, co serwer odbierający ma zrobić z wiadomościami, którym nie uda się przejść uwierzytelnienia SPF i DKIM. Może on przyjmować wartości:

• none – wobec wiadomości nie jest podejmowane żadne działanie, a e-mail zostaje poprawnie dostarczony do skrzynki odbiorczej,
• quarantine – wiadomość trafia do folderu spam,
• reject – wiadomość zostaje odrzucona przez serwer odbiorczy. 

rua – w tym tagu może zostać podany adres e-mail, na który mają być wysyłane raporty o działaniach mechanizmu DMARC w danej domenie (np. informacje o odrzuconych wiadomościach)

Gotowy, poprawny rekord DKIM, uwzględniający wszystkie te opcje może wyglądać tak:

v=DMARC1; p=reject; rua=mailto:mail@domena.tld;

Znaczy on tyle, co:

• odrzucaj wszystkie wiadomości niespełniające wymagań tej polityki (p=reject),
• wysyłaj raporty na wskazany adres e-mail (rua=mailto:mail@domena.tld).

Dokładny sposób działania mechanizmu oraz opis wszystkich tagów (także tych nieobowiązkowych i rzadko stosowanych) można znaleźć na oficjalnej stronie dmarc.org.

Aby zweryfikować zawartość (i poprawność) rekordów SPF, DKIM i DMARC, można oprócz komend z wiersza poleceń skorzystać także z internetowych narzędzi takich jak mxtoolbox.com, dmarcmonitor.net, lub wysyłając testowy e-mail na adres wygenerowany na stronie mail-tester.com.

Protokoły SPF, DKIM oraz DMARC stają się coraz bardziej popularne. Badania pokazują jednak, że temat bezpieczeństwa poczty elektronicznej w dalszym ciągu nie jest traktowany z należytą powagą. Należy pamiętać, że dobrze skonfigurowane serwery sprawią, iż poprawne wiadomości nie będą wpadać do spamu, a jednocześnie te niebezpieczne (nieautoryzowane) treści będą skutecznie odsiewane. Poprawna konfiguracja nie obroni nas jednak w pełni przed złośliwym oprogramowaniem wysyłanym pocztą czy też przed phishingiem. Dodatkowo sam podpis DKIM dołączony do wiadomości nie jest też w żadnym wypadku równoważny z szyfrowaniem wiadomości e-mail. Sama wiadomość nadal jest wysyłana, odbierana i przechowywana jawnym tekstem na serwerach operatorów pocztowych. Mimo wszystko wykorzystywanie omówionych protokołów to dobry krok do zwiększenia bezpieczeństwa poczty, na który warto się zdecydować.

* https://www.valimail.com/blog/just-17-of-domains-with-dmarc-are-actually-protected-heres-why/

O autorze: Mateusz Mazurek. Przedsiębiorca internetowy i autor projektu „Jak Wybrać Hosting”, w ramach którego testuje i recenzuje oferty polskich hostingów współdzielonych. Twórca poradnika dot. hostingu poczty e-mail, w ramach którego radzi, na co zwrócić uwagę, wybierając gotowy hosting dla skrzynek e-mail.