Szyfrowanie e-mail: TLS, end-to-end a RODO

E-maile często porównuje się do pocztówek: kto podsłuchuje po drodze, widzi wszystko. To, czy tak jest naprawdę, rozstrzyga szyfrowanie e-mail. Artykuł opisuje, co dają szyfrowanie transportowe i szyfrowanie end-to-end, co na ten temat powiedziały sądy i organy nadzorcze oraz jaka technika ma w praktyce znaczenie.

Artykuł uwzględnia orzecznictwo, technikę i wymogi dużych dostawców poczty do końca października 2026 r.

Układ artykułu odpowiada drodze wiadomości. Najpierw omówiono miarę oceny i pojęcia, potem orzecznictwo i stanowisko organów nadzorczych. Następnie przechodzimy do techniki: szyfrowania transportowego, sprawdzania nagłówka wiadomości, ochrony przed fałszywymi nadawcami oraz metod end-to-end, takich jak S/MIME i OpenPGP. Na końcu znajduje się pomoc w wyborze, które szyfrowanie pasuje do jakiego rodzaju wiadomości.

Szyfrowanie e-mail a RODO: jaki jest punkt odniesienia

Dane osobowe trzeba przetwarzać w sposób chroniący je przed nieuprawnionym dostępem. Wynika to z art. 5 ust. 1 lit. f RODO. Zgodnie z ust. 2 administrator musi też być w stanie to wykazać. Jak ma wyglądać ochrona w konkretnym przypadku, określa art. 32 RODO: należy stosować środki zgodne ze stanem wiedzy technicznej i odpowiednie do ryzyka. Przepis nie narzuca żadnej konkretnej metody. Szyfrowanie jest tam wymienione jedynie jako możliwy środek.

Szczególne kategorie danych, takie jak dane dotyczące zdrowia, podlegają art. 9 RODO. Zapotrzebowanie na ochronę jest tam od początku wyższe. Ale także pozornie niewinne wiadomości zawierają dane osobowe: wystarczy adres nadawcy z imieniem i nazwiskiem.

Stan prawny w 2026 r. można podsumować tak: nie istnieje ogólny obowiązek stosowania szyfrowania end-to-end dla każdego e-maila. Nie ma też ogólnego przyzwolenia na wiadomości niezaszyfrowane. Liczy się ryzyko dla osób, których dane dotyczą, oraz pytanie, co jest uzasadnione według stanu wiedzy technicznej. Kto wysyła dane osobowe e-mailem, potrzebuje więc umotywowanej decyzji, którą w razie wątpliwości można przedstawić.

Szyfrowanie transportowe, szyfrowanie end-to-end i podpisy: wyraźne rozróżnienie

W codziennym życiu myli się trzy rzeczy, które pełnią różne zadania.

Szyfrowanie transportowe zabezpiecza połączenie między dwoma punktami. Wykorzystuje TLS (Transport Layer Security), następcę SSL. Na każdym odcinku treść jest przesyłana w postaci zaszyfrowanej. Na samym serwerze pocztowym jest jednak przechowywana otwartym tekstem, ponieważ serwer musi wiadomość przetworzyć i zapisać.

Szyfrowanie end-to-end (E2E) szyfruje treść w programie pocztowym nadawcy. Odszyfrować ją może tylko odbiorca. Serwery pośrednie widzą wyłącznie dane, z których nic nie wyczytają. W tym celu upowszechniły się S/MIME i OpenPGP.

Podpis to coś innego: niczego nie szyfruje, lecz dowodzi, od kogo pochodzi wiadomość i że nie została zmieniona po drodze. Odgrywa ważną rolę przy wymianie kluczy, ponieważ klucze publiczne przekazuje się zazwyczaj w podpisanych wiadomościach.

Obie metody mają wspólne ograniczenie: temat, nadawca i odbiorca zazwyczaj pozostają czytelne. Wytyczne niemieckiej Konferencji ds. Ochrony Danych zwracają uwagę, że te okoliczności komunikacji również mogą wymagać ochrony.

Orzecznictwo dotyczące szyfrowania e-mail: kiedy wystarcza szyfrowanie transportowe

Niemieckie sądy wypowiadały się w tej sprawie kilkakrotnie w ostatnich latach, z pozornie sprzecznymi wynikami. Przy bliższym spojrzeniu orzeczenia układają się w jedną linię: im większa potencjalna szkoda, tym wyższe wymagania.

Najstarszy przypadek z tej serii pochodzi z 2020 r. W dniu 17 grudnia 2020 r. Sąd Administracyjny w Moguncji rozstrzygał (sygn. 1 K 778/19.MZ), czy adwokat może wysyłać klientom e-maile wyłącznie z szyfrowaniem transportowym. Orzeczenie jest zakwalifikowane na podstawie art. 32 i art. 5 RODO. Zgodnie z tezą orzeczenia szyfrowanie transportowe wystarcza w korespondencji e-mailowej adwokatów. Szyfrowanie end-to-end jest więc konieczne tylko w pojedynczych przypadkach o podwyższonym ryzyku.

Często cytowane, ale mające tylko ograniczone znaczenie jest też postanowienie Federalnego Trybunału Sprawiedliwości z 22 marca 2021 r. (AnwZ (Brfg) 2/20). Dotyczy ono specjalnej elektronicznej skrzynki adwokackiej (beA). Jej architektura bezpieczeństwa opiera się na dedykowanych sprzętowych modułach bezpieczeństwa. Nie przysługuje tam roszczenie o szyfrowanie end-to-end. Do zwykłych e-maili orzeczenie da się zastosować tylko z trudem.

Sprawa przed Wyższym Sądem Krajowym w Karlsruhe pokazuje linię przyjętą w obrocie gospodarczym. Haker przejął konto e-mail dealera samochodowego i wysłał kupującemu zmanipulowaną fakturę z innym numerem rachunku. Kupujący zapłacił na niewłaściwe konto. W dniu 27 lipca 2023 r. sąd orzekł (sygn. 19 U 83/22), że niezbędne środki ochrony zależą od uzasadnionych oczekiwań partnerów handlowych co do bezpieczeństwa. Płatność na rzecz oszusta nie zwolniła kupującego z długu, musiał zapłacić drugi raz. Sąd Okręgowy w Mosbach rozstrzygnął w pierwszej instancji inaczej.

Wyższy Sąd Krajowy w Szlezwiku doszedł w grudniu 2024 r. do innego wyniku. Także w tej sprawie chodziło o zmanipulowaną fakturę, tym razem dla konsumenta i na około 15 000 euro. Według komunikatu prasowego sądu fakturę należało wysłać z szyfrowaniem end-to-end, ponieważ atak hakerski jest przewidywalnym ryzykiem. Klient mógł potrącić roszczenie odszkodowawcze z roszczeniem o zapłatę i nie musiał płacić ponownie. Sąd dopuścił rewizję, ale według komunikatu prasowego wyrok jest mimo to prawomocny. Analiza tych orzeczeń, w tym wyroku Sądu Administracyjnego w Düsseldorfie z 2 kwietnia 2026 r. (29 K 7351/23), znajduje się w artykule Bezpieczeństwo e-maili: ochrona wiadomości przed zagrożeniami.

Jak to do siebie pasuje? Najwyraźniej decydują zapotrzebowanie na ochronę i potencjalna szkoda. Między przedsiębiorstwami sądy dotąd raczej akceptowały standardowe środki. Gdy konsument przelewa dużą kwotę na rachunek podany wyłącznie w niezabezpieczonym e-mailu, wymaga się więcej. Nazwa metody jest drugorzędna. Ważne, by środek rzeczywiście ograniczał konkretne ryzyko. Otwarte pozostaje na przykład, czy wystarczy zgoda odbiorcy na słabsze szyfrowanie. Wiarygodnego orzeczenia w tej kwestii jeszcze nie ma.

Wytyczne DSK i BSI: miara organów nadzorczych

W dniu 27 maja 2021 r. Konferencja Niezależnych Organów Nadzorczych ds. Ochrony Danych Niemiec (DSK) przyjęła wytyczne „Środki ochrony danych osobowych przy przesyłaniu e-mailem”, w wersji z 16 czerwca 2021 r. Bawaria głosowała przeciw. Dokument jest publicznie dostępny (po niemiecku) i wyraźnie rozróżnia przypadki.

Przy normalnym ryzyku wytyczne wymagają obowiązkowego szyfrowania transportowego opartego na wytycznych technicznych BSI TR-03108-1. Przy wysokim ryzyku administratorzy powinni co do zasady stosować szyfrowanie end-to-end wraz z kwalifikowanym szyfrowaniem transportowym, na przykład z DANE lub DNSSEC. Tajemnicę zawodową uznaje się za wskazówkę wysokiego ryzyka, którą trzeba oceniać w każdym przypadku z osobna.

Kary za niezaszyfrowane e-maile zdarzają się rzadko; organy nadzorcze działają mniej przez sankcje, a bardziej przez dokumenty takie jak ten. Mimo to wytyczne mają wagę jako miernik: w sporach o zmanipulowane faktury dyskutowano, czy wytyczne organów można stosować. Wyższy Sąd Krajowy w Karlsruhe uznał je w swojej sprawie za nieistotne. Wytyczne nie są wiążące. Kto od nich odstępuje, powinien jednak umieć to uzasadnić.

W TR-03108 niemiecki Federalny Urząd ds. Bezpieczeństwa Informacji (BSI) opisuje bezpieczny transport poczty e-mail dla dostawców, łącznie z certyfikacją. Dla operatorów serwerów pocztowych jest to techniczny miernik. Ponadto TR-03182 zawiera zalecenie dotyczące uwierzytelniania poczty e-mail.

Prawidłowe wdrożenie szyfrowania transportowego: TLS 1.3, port 465, MTA-STS i DANE

Programy i serwery pocztowe porozumiewają się kilkoma protokołami. SMTP (Simple Mail Transfer Protocol) jest używany od 1982 r. i przesyła wiadomości. ESMTP to wariant rozszerzony. Skróty w nagłówku wiadomości pokazują, co wydarzyło się na każdym odcinku: ESMTPS oznacza, że wynegocjowano TLS. ESMTPSA oznacza dodatkowo, że nadawca zalogował się nazwą użytkownika i hasłem.

Są dwa sposoby negocjacji. Przy niejawnym TLS (implicit TLS) połączenie jest szyfrowane od początku. Dla wysyłania poczty z programu RFC 8314 przewiduje w tym celu port 465, a dla pobierania IMAP na porcie 993 lub POP3 na porcie 995. Przy STARTTLS połączenie zaczyna się bez szyfrowania, a obie strony dopiero potem negocjują przejście na szyfrowane. Atakujący mogą ingerować w ten krok. Badanie „Why TLS is better without STARTTLS” (USENIX Security 2021) opisuje ataki typu downgrade i injection. Niejawne TLS uchodzi więc za lepszy wybór, choć w wielu miejscach równolegle nadal oferuje się port 587 ze STARTTLS.

Co do wersji: TLS 1.0 i 1.1 są oficjalnie wycofane od RFC 8996 (marzec 2021 r.). TLS 1.2 to minimum, TLS 1.3 to cel, o czym mówią także wytyczne techniczne BSI TR-02102-2.

Między serwerami pozostaje jeden problem. Szyfrowanie odbywa się tam zazwyczaj przez STARTTLS i często jest tylko oportunistyczne: jeśli się nie powiedzie, połączenie wraca do postaci niezaszyfrowanej. Wiele serwerów pocztowych oferuje tryb, który odrzuca dostarczenie, jeśli nie nawiązano połączenia TLS. Również ten tryb działa zwykle przez STARTTLS, a nie przez niejawne TLS.

Lukę zamykają dwie metody:

• MTA-STS (RFC 8461): domena odbiorcy publikuje politykę, że TLS z ważnym certyfikatem jest obowiązkowe. Serwery wysyłające się do niej stosują. DNSSEC nie jest wymagany. Istnieją tryby testing i enforce. Raporty o problemach dostarcza TLS-RPT.
• DANE: rekord TLSA w DNS określa, jakiego certyfikatu używa serwer odbiorcy. Wymaga to DNSSEC. DANE zabezpiecza autentyczność serwera odbiorcy przed atakami downgrade i man-in-the-middle.

Według Microsoftu przychodzący SMTP z DANE jest ogólnie dostępny w Exchange Online od 22 października 2024 r., ale domyślnie wyłączony. MTA-STS jest obsługiwany według dokumentacji Microsoftu. Narzędzia online mogą sprawdzić, czy własna domena publikuje takie polityki; więcej o tym w następnej części.

Sprawdzanie szyfrowania e-mail: odczyt nagłówka i test serwera odbiorcy

To, czy wiadomość rzeczywiście dotarła zaszyfrowana, pokazuje nagłówek. W klasycznych wersjach Outlooka należy dwukrotnie kliknąć wiadomość, potem Plik, Właściwości i spojrzeć w pole Nagłówki internetowe. W nowym Outlooku i w poczcie przez przeglądarkę droga jest inna. Menu zmieniają się z wersji na wersję, warto więc zajrzeć do pomocy danego programu.

W nagłówkach interesujące są linie Received. Każdy serwer, który przekazuje wiadomość dalej, dodaje jedną. Nowoczesne serwery wpisują tam wersję protokołu i szyfr, na przykład TLSv1.3 i TLS_AES_256_GCM_SHA384. Poniższy fragment jest zrekonstruowany, z symbolami zastępczymi zamiast prawdziwych adresów.

Nagłówek nie jest jednak pełnym dowodem w rozumieniu art. 5 ust. 2. Obejmuje tylko odcinki, na których serwer dodał linię. Tam, gdzie występuje przekazywanie lub bramy, pozostaje luka. Mimo to jest przydatny jako jeden z elementów dokumentacji.

Przed wysłaniem można sprawdzić, co obsługuje serwer odbiorcy. CheckTLS odpytuje możliwości bez wysyłania wiadomości i pokazuje między innymi, czy oferowane jest TLS i czy istnieje rekord TLSA dla DANE. Wynik „no TLSA” jest częsty w wielu domenach. Usługa internet.nl sprawdza STARTTLS, DANE, a także SPF, DKIM i DMARC. Według jej dokumentacji MTA-STS nie wchodzi w zakres oceny.

Jeśli wynik TLS jest negatywny, pomaga powiadomienie odbiorcy. Alternatywnie można użyć portalu lub zaszyfrowanego załącznika; o tym niżej. Dla własnej strony internetowej i jej środków ochrony wstępne wskazówki daje kontrola strony pod kątem RODO. Kontrole bezpieczeństwa domen, w tym uwierzytelniania poczty e-mail, są dostępne w Web Security Checks.

SPF, DKIM i DMARC: ochrona przed fałszywymi nadawcami

Szyfrowanie chroni przed podsłuchem, nie przed fałszerstwem. Właśnie o to chodziło w sprawach o faktury: atakujący wysyła wiadomość, która wygląda, jakby pochodziła od prawdziwego nadawcy, albo korzysta z przejętej skrzynki. Przed fałszywymi nadawcami pomagają trzy współpracujące metody.

Ostatnio presję na ich wprowadzenie wywierają więksi dostawcy. Od 1 lutego 2024 r. Google i Yahoo wymagają od wszystkich nadawców między innymi SPF lub DKIM, TLS i niskiego odsetka spamu. Kto wysyła dziennie ponad 5000 wiadomości na adresy Gmaila, potrzebuje SPF, DKIM i co najmniej polityki DMARC. Microsoft wprowadził podobne wymogi dla nadawców masowych do Outlook.com, Hotmail i Live od 5 maja 2025 r. Szczegółowe zasady znajdują się w dokumentacji Google.

Wytyczne DSK przewidują, że DKIM i DMARC są sprawdzane przy odbiorze. Rysuje się tu trend, którego administratorzy lepiej nie powinni ignorować. Więcej tła o fałszywych wiadomościach znajduje się w artykule E-maile, phishing i autentyczność wiadomości elektronicznych (po niemiecku). O postępowaniu z nieznanymi nadawcami i załącznikami jest osobny artykuł (po niemiecku).

Szyfrowanie end-to-end z S/MIME i OpenPGP: stan na 2026 r.

Kto chce lub musi wyjść poza szyfrowanie transportowe, ma do dyspozycji dwie ugruntowane metody. Obie szyfrują treść w programie pocztowym. Obie wymagają uprzedniej wymiany kluczy. Wytyczne DSK nazywają szyfrowanie end-to-end „najdalej idącą ochroną”, ponieważ chroni także dane w spoczynku.

S/MIME

S/MIME działa na certyfikatach wydawanych przez urząd certyfikacji. Można ich używać bezpośrednio w Outlooku, Apple Mail i wielu innych programach. Klucz publiczny odbiorcy nadawca zazwyczaj uzyskuje z podpisanej wiadomości, z której można zaimportować certyfikat.

Od 2021 r. wiele się zmieniło w kwestii certyfikatów. Dawniej powszechne klasy od 1 do 4 są przestarzałe. Od 1 września 2023 r. obowiązują Baseline Requirements forum CA/Browser, z czterema typami różniącymi się zakresem weryfikacji: mailbox-, organization-, sponsor- i individual-validated. Aktualną wersję wymagań publikuje samo forum.

OpenPGP

OpenPGP działa bez centralnego urzędu certyfikacji. Każdy generuje własną parę kluczy. Autentyczność sprawdza się za pomocą odcisków palców lub poświadczeń osób trzecich. DSK wyraźnie zwraca uwagę, że samo opublikowanie klucza na serwerze kluczy nie świadczy o jego autentyczności. Praktyczny jest Web Key Directory, które pozwala domenie samodzielnie udostępniać swoje klucze. Wprowadzenie do podpisywania znajduje się w artykule Podpisywanie i wysyłanie e-maili za pomocą PGP.

Standard się zmienił: RFC 9580 (lipiec 2024 r.) zastępuje RFC 4880. Wprowadza nowe formaty kluczy, nowoczesne algorytmy takie jak X25519 i Ed25519 oraz szyfrowanie uwierzytelnione. Równolegle projekt GnuPG rozwija odmienną linię o nazwie LibrePGP. Komplikuje to sprawę. Thunderbird zamiast GnuPG używa własnej biblioteki RNP, a Mozilla dokumentuje problemy z kluczami o cechach nieobsługiwanych przez RNP. Klucze nie zawsze więc przenoszą się bezproblemowo między programami.

W praktyce z Outlookiem i Thunderbirdem

W praktyce często jest różnica między używaniem jednego konta a kilku. Wtyczkę GpgOL z pakietu Gpg4win można skonfigurować w Outlooku i działa z jednym kontem. Przy kilku kontach przy każdym wysyłaniu pojawia się jednak zapytanie, a przypisanie kluczy może się pomylić. W środowiskach z wieloma kontami jest to przeszkoda.

Gpg4win jest obecnie dostępny w wersji 5.1.1 (wydanej 23 września 2026 r.), jak pokazuje strona projektu. GpgOL działa w klasycznym Outlooku. Czy i kiedy będzie obsługiwać nowego Outlooka, jest według wpisu na forum GnuPG kwestią otwartą. OpenPGP jest wbudowane w Thunderbirda od wersji 78, nie potrzeba więc dodatku. Konfiguruje się je w ustawieniach konta w sekcji szyfrowanie end-to-end. Kto używa tylko jednego konta, szybko do tego dojdzie.

W grudniu 2025 r. BSI zbadał dwanaście bezpłatnych programów pocztowych. Według jego komunikatu prasowego (po niemiecku) programy różnią się obsługą szyfrowania end-to-end. Funkcje bezpieczeństwa często nie są domyślnie włączone.

Kwestią poboczną jest atak Efail z 2018 r. Wykorzystywał aktywną zawartość HTML w wiadomościach do wycieku odszyfrowanych tekstów. Środkami zaradczymi są aktualne programy i wyłączenie renderowania HTML dla zaszyfrowanych wiadomości. Wyjaśnienie podaje strona efail.de. Nie ma powodu do paniki, ale przykład pokazuje, że nawet dobra kryptografia może zawieść z powodu implementacji.

Portale, bramy i szyfrowanie Microsoftu jako alternatywy

Największą przeszkodą dla szyfrowania end-to-end jest wymiana kluczy z każdym korespondentem. Dlatego wiele organizacji stawia na rozwiązania, w których wysiłek leży po stronie nadawcy.

• Szyfrowanie przez bramę: serwer wewnątrz firmy obsługuje S/MIME lub PGP. Ochrona sięga wtedy do bramy odbiorcy. W zależności od konfiguracji wiadomość jest zapisana w skrzynce w postaci odszyfrowanej. Pytanie o zaufanie przesuwa się na operatora bramy.
• Portal: e-mail zawiera tylko powiadomienie. Wiadomość odbiera się w przeglądarce po zalogowaniu. Wytyczne DSK wymieniają portal internetowy także jako kanał komunikacji z osobami, których dane dotyczą.
• Microsoft Purview Message Encryption: możliwe do użycia w nowym Outlooku z odpowiednią licencją. Odbiorcy spoza Microsoftu otrzymują instrukcję otwarcia wiadomości. Nie można go łączyć z S/MIME w tej samej wiadomości.
• Załącznik chroniony hasłem: archiwum z AES-256, utworzone na przykład w 7-Zip, służy jako koperta. Hasło przesyła się innym kanałem, na przykład telefonicznie (rozdzielenie kanałów). SMS jako kanał budzi kontrowersje i należy go stosować tylko z zastrzeżeniami.

Kto prowadzi bramę lub portal przez usługodawcę, zawiera zwykle umowę powierzenia przetwarzania na podstawie art. 28 RODO. Zagrożenia dla samego konta związane z Microsoft 365 opisuje artykuł o token sprayingu.

Rachunek jest trzeźwy: kto unika zarządzania kluczami, dostaje w portalu lub bramie praktyczną drogę pośrednią. Oznacza ona kompromisy w porównaniu z prawdziwym szyfrowaniem end-to-end, ale jest znacznie lepsza niż e-mail otwartym tekstem z wrażliwą treścią.

Kryptografia postkwantowa w poczcie e-mail: co liczy się już dziś

Szyfrowanie end-to-end ma cechę, którą często się pomija: z założenia nie zapewnia doskonałej poufności w przód (perfect forward secrecy). DSK pisze, że przechwycone wiadomości można zapisać i odszyfrować później, jeśli klucz prywatny zostanie ujawniony. Przy przyszłych komputerach kwantowych taki scenariusz mógłby wystąpić także bez utraty klucza.

Standaryzacja trwa. Wraz z RFC 9936 (marzec 2026 r.) istnieje standard dla ML-KEM w CMS, podstawy S/MIME. Dla TLS 1.3 BSI TR-02102-2 przewiduje metody hybrydowe łączące algorytmy klasyczne i postkwantowe. W codziennym użyciu nie wynika z tego potrzeba działania. Kto wysyła treści, które muszą pozostać poufne za 15 lat, powinien jednak śledzić ten temat.

Błędnie adresowane e-maile, naruszenia ochrony danych i faks: granice szyfrowania

Jedna wada szyfrowania transportowego obowiązuje do dziś: jest bezużyteczne, gdy adres odbiorcy jest błędny. Wiadomość dociera zaszyfrowana na niewłaściwy serwer i zostaje tam zapisana otwartym tekstem. Inaczej jest przy szyfrowaniu end-to-end, o ile zaadresowano je do właściwego odbiorcy. DSK wyraźnie wymienia indywidualne adresowanie jako środek.

Dlatego ważna jest strona organizacyjna. Należy do niej wyłączenie autouzupełniania dla wrażliwych odbiorców, zasada czterech oczu przy delikatnych treściach i sprawdzenie adresu przed wysłaniem. To, czy błędnie zaadresowany e-mail trzeba zgłosić jako naruszenie ochrony danych, zależy od ryzyka i należy do osobnej procedury.

W tej debacie pojawia się też faks. Komisarz krajowy ds. ochrony danych i wolności informacji w Bremie porównał faks z niezaszyfrowanymi e-mailami na stronie z wytycznymi (po niemiecku). W orzeczeniu z 2020 r. (11 LA 104/19) Wyższy Sąd Administracyjny w Lüneburgu uznał, że przy szczególnie wrażliwych danych konieczna jest indywidualna ocena.

Które szyfrowanie do jakiego e-maila: pomoc w wyborze

Z orzeczeń i wytycznych można wyprowadzić praktyczną regułę. Im większa potencjalna szkoda i potrzeba poufności, tym bardziej należy rozważyć szyfrowanie end-to-end lub portal. Dla faktur obowiązuje dodatkowa zasada: zmianę danych bankowych potwierdza się drugim kanałem, na przykład telefonicznie.

Tabela ma służyć jako orientacja i nie jest poradą prawną. Ocena ryzyka należy do administratora i powinna być udokumentowana. Pomaga krótka kontrola: jaka byłaby najgorsza realistyczna szkoda dla osób, których dane dotyczą? Jak jest prawdopodobna? Jaki środek zauważalnie ją zmniejsza?

Podsumowanie

Szyfrowanie transportowe jest obowiązkowe i według DSK oraz orzecznictwa zazwyczaj wystarcza przy normalnym ryzyku, o ile jest wdrożone konsekwentnie i zgodnie ze stanem wiedzy technicznej. Należą do tego TLS 1.2 lub, lepiej, 1.3, niejawne TLS w programie pocztowym oraz MTA-STS lub DANE po stronie serwera. Przy wysokim ryzyku oczekuje się szyfrowania end-to-end lub równoważnego rozwiązania.

Szyfrowanie e-mail pozostaje tematem kompromisów. Zarządzanie kluczami jest żmudne, portale to pragmatyczna droga pośrednia, a przeciw oszustwom SPF, DKIM, DMARC i drugi kanał dla danych płatniczych pomagają co najmniej tak samo jak kryptografia.