TLS w mailingu: STARTTLS, MTA-STS i TLS Reporting

Każdego dnia przez serwery SMTP przepływają miliony wiadomości zawierających dane klientów, faktury i hasła resetujące. Czy wiesz, że bez prawidłowej konfiguracji TLS te e-maile mogą wędrować przez internet w postaci czystego tekstu — widoczne dla każdego, kto podsłuchuje ruch sieciowy? Ten poradnik pokazuje krok po kroku, jak działa TLS w mailingu, czym różni się STARTTLS od opportunistic TLS, dlaczego samo „coś tam szyfruje" nie wystarczy oraz jak wdrożyć MTA-STS i TLS Reporting, żeby mieć pewność, że Twoja poczta jest naprawdę bezpieczna.

Czym jest TLS w kontekście e-mail?

TLS (Transport Layer Security) to protokół kryptograficzny, który szyfruje połączenie między dwoma serwerami pocztowymi (lub między klientem a serwerem). Jego poprzednik, SSL, jest dziś uznawany za przestarzały i podatny na ataki — jeśli Twój serwer nadal przyjmuje SSLv3 lub TLS 1.0, czas to zmienić. Aktualne minimalne zalecenie to TLS 1.2, a docelowo TLS 1.3.

Ważne rozróżnienie: TLS chroni transmisję wiadomości między serwerami, a nie treść samej wiadomości w skrzynce odbiorczej. Szyfrowanie end-to-end (S/MIME, PGP) to osobny temat. W kontekście mailingów masowych i transakcyjnych kluczowe jest właśnie szyfrowanie transportu.

STARTTLS — uaktualnienie połączenia w locie

STARTTLS to komenda rozszerzenia SMTP (zdefiniowana w RFC 3207), która pozwala przekształcić niezaszyfrowane połączenie na porcie 25 (lub 587) w zaszyfrowane — bez konieczności otwierania osobnego portu. Serwer najpierw nawiązuje zwykłe połączenie TCP, a następnie „uaktualnia" je do TLS za pomocą polecenia STARTTLS.

Jak przebiega negocjacja STARTTLS?

1. Klient łączy się z serwerem na porcie 25 lub 587.
2. Serwer w odpowiedzi na EHLO zwraca listę obsługiwanych rozszerzeń, w tym STARTTLS.
3. Klient wysyła komendę STARTTLS.
4. Obie strony przeprowadzają handshake TLS — wymieniają certyfikaty i uzgadniają szyfr.
5. Dalsza komunikacja (AUTH, DATA) odbywa się już w zaszyfrowanym tunelu.

Port 465 (SMTPS) działa inaczej — TLS jest tu wymagany od razu, bez fazy „uaktualnienia". W nowoczesnych konfiguracjach port 465 z implicit TLS jest preferowany dla klientów poczty, natomiast port 25 z STARTTLS pozostaje standardem dla komunikacji serwer–serwer (MTA–MTA).

Opportunistic TLS — szyfrowanie, które można ominąć

Opportunistic TLS oznacza, że serwer próbuje nawiązać szyfrowane połączenie, ale jeśli druga strona go nie obsługuje — przesyła wiadomość bez szyfrowania. Brzmi rozsądnie jako mechanizm kompatybilności wstecznej, ale stwarza poważne ryzyko.

Atak downgrade i MITM

Atakujący, który kontroluje ruch sieciowy między serwerami (np. na poziomie BGP hijacking lub skompromitowanego routera), może usunąć z odpowiedzi EHLO informację o obsłudze STARTTLS. Serwer wysyłający, nie widząc tej opcji, wyśle wiadomość w postaci jawnej. Ten atak nosi nazwę STARTTLS downgrade i jest całkowicie transparentny dla nadawcy i odbiorcy.

Właśnie dlatego samo opportunistic TLS — bez dodatkowych mechanizmów weryfikacji — nie spełnia wymogów bezpieczeństwa dla wrażliwych danych. Według art. 32 RODO administrator jest zobowiązany do stosowania „odpowiednich środków technicznych" zapewniających bezpieczeństwo danych. Przesyłanie danych osobowych przez SMTP bez wymuszania szyfrowania może być uznane za naruszenie tego obowiązku.

MTA-STS — wymuszanie szyfrowania przez DNS i HTTPS

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) to mechanizm, który pozwala właścicielowi domeny ogłosić politykę: „moje serwery pocztowe obsługują TLS i nie akceptuj połączeń bez szyfrowania". Serwery wysyłające, które obsługują MTA-STS, pobierają tę politykę i odmawiają dostarczenia wiadomości, jeśli nie uda się nawiązać bezpiecznego połączenia.

Jak działa MTA-STS krok po kroku?

1. Rekord DNS TXT — publikujesz rekord _mta-sts.twojadomena.pl z wartością np. v=STSv1; id=20240601T120000. Pole id zmienia się przy każdej aktualizacji polityki.
2. Plik polityki HTTPS — hostujesz plik tekstowy pod adresem https://mta-sts.twojadomena.pl/.well-known/mta-sts.txt. Musi być dostępny przez HTTPS z ważnym certyfikatem.
3. Zawartość pliku polityki — określasz tryb (enforce lub testing), listę akceptowanych serwerów MX i czas ważności (max_age).
4. Serwer wysyłający — przed dostarczeniem wiadomości pobiera politykę, sprawdza certyfikat TLS serwera odbiorczego i jeśli wszystko się zgadza, nawiązuje szyfrowane połączenie. Jeśli nie — odrzuca dostarczenie (w trybie enforce) lub tylko raportuje problem (w trybie testing).

Przykładowy plik mta-sts.txt

version: STSv1
mode: enforce
mx: mail.twojadomena.pl
mx: *.twojadomena.pl
max_age: 86400

Zacznij od trybu testing i obserwuj raporty przez co najmniej 2 tygodnie przed przełączeniem na enforce. Pochopne włączenie trybu wymuszającego bez sprawdzenia konfiguracji MX może spowodować niedostarczanie wiadomości.

Wymagania certyfikatu TLS przy MTA-STS

Certyfikat serwera SMTP musi być wystawiony przez zaufany urząd certyfikacji (nie self-signed), musi obejmować nazwę hosta MX i nie może być wygasły. To częsty błąd — serwery SMTP działają latami z certyfikatami, o których nikt nie pamięta, a które wygasły kilka miesięcy temu.

TLS Reporting — widoczność problemów z szyfrowaniem

TLS Reporting (TLSRPT, RFC 8460) to mechanizm uzupełniający MTA-STS. Pozwala otrzymywać raporty od innych serwerów pocztowych o problemach z nawiązaniem szyfrowanego połączenia z Twoją domeną. Raporty są wysyłane codziennie w formacie JSON na wskazany adres e-mail lub endpoint HTTPS.

Konfiguracja rekordu TLSRPT

Wystarczy dodać jeden rekord DNS TXT dla _smtp._tls.twojadomena.pl:

v=TLSRPTv1; rua=mailto:tls-reports@twojadomena.pl

Możesz też wskazać endpoint HTTPS: rua=https://twojadomena.pl/tls-reports. Raporty zawierają informacje o liczbie udanych i nieudanych połączeń TLS, typach błędów (np. wygasły certyfikat, nieobsługiwana wersja TLS, brak wpisu MX w polityce MTA-STS) oraz adresach IP serwerów, które próbowały się połączyć.

Co znajdziesz w raporcie TLSRPT?

Porównanie mechanizmów: co chronią, a czego nie

Praktyczna checklista wdrożenia TLS w mailingu

Poniższa lista pozwoli Ci systematycznie sprawdzić i poprawić konfigurację TLS dla Twojej domeny pocztowej:

• Sprawdź wersję TLS — upewnij się, że serwer SMTP obsługuje TLS 1.2 i/lub 1.3. Wyłącz SSLv3, TLS 1.0 i TLS 1.1.
• Zweryfikuj certyfikat MX — certyfikat musi być wystawiony przez zaufane CA, obejmować nazwę hosta MX i nie może być wygasły. Ustaw alert na 30 dni przed wygaśnięciem.
• Włącz STARTTLS na porcie 25 — dla komunikacji serwer–serwer. Port 587 z STARTTLS dla klientów wysyłających.
• Opublikuj rekord TLSRPT — najprostszy krok, daje natychmiastową widoczność problemów.
• Wdróż MTA-STS w trybie testing — utwórz subdomenę mta-sts., skonfiguruj HTTPS, opublikuj plik polityki i rekord DNS.
• Analizuj raporty przez 2–4 tygodnie — sprawdź, czy nie ma błędów certificate-expired ani starttls-not-supported.
• Przełącz MTA-STS na tryb enforce — zmień mode: testing na mode: enforce i zaktualizuj pole id w rekordzie DNS.
• Sprawdź konfigurację dostawcy SMTP — jeśli wysyłasz przez zewnętrzny serwer (np. w MailerPRO przez własną skrzynkę SMTP), upewnij się, że połączenie wychodzące również używa TLS 1.2+ i weryfikuje certyfikat serwera.

Najczęstsze błędy i jak je naprawić

Self-signed certyfikat na serwerze MX

Serwery obsługujące MTA-STS odrzucą połączenie, jeśli certyfikat jest self-signed lub wystawiony przez niezaufane CA. Rozwiązanie: certyfikat od publicznego CA (np. Let's Encrypt działa świetnie dla serwerów pocztowych).

Rozbieżność między nazwą MX a certyfikatem

Rekord MX wskazuje na mail.twojadomena.pl, ale certyfikat jest wystawiony dla twojadomena.pl. To powoduje błąd walidacji. Certyfikat musi obejmować dokładną nazwę hosta wskazaną przez rekord MX — albo jako CN, albo jako SAN (Subject Alternative Name).

Plik mta-sts.txt niedostępny przez HTTPS

Częsty problem po migracji serwera lub wygaśnięciu certyfikatu dla subdomeny mta-sts.. Serwery wysyłające, które nie mogą pobrać polityki, traktują to jako brak polityki — i wracają do opportunistic TLS. Monitoruj dostępność tego pliku tak samo jak dostępność strony głównej.

Zapomniana aktualizacja pola id w rekordzie DNS

Serwery wysyłające cachują politykę MTA-STS przez czas określony w max_age. Jeśli zmienisz plik polityki bez aktualizacji pola id w rekordzie DNS TXT, część serwerów będzie korzystać ze starej, zcachowanej wersji. Zawsze zmieniaj id przy każdej modyfikacji polityki — najwygodniej używać znacznika czasu w formacie YYYYMMDDTHHmmss.

Szyfrowanie transportu e-mail to nie opcja dla dużych firm — to podstawowy element bezpieczeństwa każdego wysyłającego, który przetwarza dane osobowe swoich klientów lub kontrahentów. Wdrożenie TLSRPT zajmuje dosłownie 5 minut (jeden rekord DNS), a MTA-STS w trybie testing można uruchomić w godzinę. Zacznij od opublikowania rekordu TLSRPT jeszcze dziś — i sprawdź w raportach, czy Twoje połączenia SMTP rzeczywiście są szyfrowane tak, jak myślisz.