TLS-RPT i MTA-STS: co raporty mówią o bezpieczeństwie

Twoje e-maile mogą być szyfrowane podczas wysyłki — ale skąd wiesz, że szyfrowanie faktycznie działa i nikt po drodze nie próbuje go obejść? Standardy TLS-RPT i MTA-STS odpowiadają dokładnie na to pytanie: pierwszy dostarcza dziennych raportów o połączeniach SMTP, drugi wymusza politykę szyfrowania na poziomie DNS. W tym poradniku przejdziesz przez konfigurację obu mechanizmów krok po kroku i nauczysz się czytać raporty tak, żeby wyciągać z nich realne wnioski bezpieczeństwa.

Czym jest MTA-STS i dlaczego samo TLS nie wystarczy

Protokół SMTP obsługuje szyfrowanie TLS w trybie opportunistic — serwer próbuje nawiązać szyfrowane połączenie, ale jeśli druga strona go nie obsługuje, wiadomość i tak zostaje wysłana w postaci jawnej. To otwiera drzwi dla ataku SMTP downgrade: napastnik w środku sieci może usunąć ogłoszenie o obsłudze STARTTLS i zmusić serwery do komunikacji bez szyfrowania.

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) rozwiązuje ten problem przez publikowanie polityki w DNS i na dedykowanym endpoincie HTTPS. Wysyłający serwer pobiera politykę, zapamiętuje ją (cache), a następnie odmawia dostarczenia wiadomości, jeśli nie może nawiązać prawidłowego, zweryfikowanego połączenia TLS. Nie ma już możliwości cichego downgrade'u.

Trzy tryby polityki MTA-STS

• none — polityka istnieje, ale nie jest egzekwowana (tryb testowy).
• testing — naruszenia są raportowane przez TLS-RPT, ale wiadomości nadal są dostarczane.
• enforce — naruszenia blokują dostarczenie; to jedyny tryb dający realne bezpieczeństwo.

Zalecana ścieżka wdrożenia to kolejno: none → testing → enforce, z co najmniej tygodniowym oknem obserwacji na każdym etapie.

Czym jest TLS-RPT i co zawiera raport TLS

TLS-RPT (TLS Reporting, RFC 8460) to mechanizm, który każe serwerom wysyłającym przesyłać codzienne raporty JSON na wskazany adres e-mail lub endpoint HTTPS. Raport zawiera statystyki wszystkich połączeczeń SMTP do Twojej domeny: ile zakończyło się sukcesem, ile napotkało błędy TLS, a ile zostało zablokowanych przez politykę MTA-STS.

Raport TLS jest wysyłany raz na dobę (domyślnie za poprzedni dzień UTC) przez każdy serwer, który próbował dostarczyć do Twojej domeny. Duże providery — Google, Microsoft, Yahoo — generują raporty regularnie i to właśnie ich dane są najcenniejsze diagnostycznie.

Struktura raportu JSON — kluczowe pola

Konfiguracja MTA-STS krok po kroku

Wdrożenie MTA-STS wymaga trzech elementów: rekordu DNS TXT, pliku polityki dostępnego przez HTTPS oraz (opcjonalnie) rekordu TLS-RPT. Poniżej każdy krok z konkretnymi wartościami.

Krok 1 — Rekord DNS dla MTA-STS

Dodaj rekord TXT dla subdomeny _mta-sts.twojadomena.pl:

v=STSv1; id=20240601T120000Z

Pole id to dowolny ciąg znaków — zmień go za każdym razem, gdy aktualizujesz plik polityki. Serwery buforują politykę na podstawie tego identyfikatora; zmiana id sygnalizuje, że muszą pobrać nową wersję.

Krok 2 — Plik polityki MTA-STS

Opublikuj plik tekstowy pod adresem https://mta-sts.twojadomena.pl/.well-known/mta-sts.txt. Serwer musi odpowiadać na HTTPS z ważnym certyfikatem. Przykładowa treść pliku:

version: STSv1
mode: testing
mx: mail.twojadomena.pl
mx: *.twojadomena.pl
max_age: 604800

Parametr max_age określa czas cache'owania w sekundach (604800 = 7 dni). W trybie enforce możesz zwiększyć go do 31557600 (rok), ale najpierw upewnij się, że wszystko działa poprawnie — cofnięcie polityki z długim TTL może zająć czas.

Krok 3 — Przejście do trybu enforce

Po minimum 7 dniach w trybie testing przeanalizuj raporty TLS-RPT. Jeśli total-failure-session-count wynosi 0 lub błędy dotyczą wyłącznie marginalnych senderów, zmień mode: testing na mode: enforce w pliku polityki i zaktualizuj id w rekordzie DNS.

Konfiguracja TLS-RPT krok po kroku

TLS-RPT konfiguruje się jednym rekordem DNS TXT dla subdomeny _smtp._tls.twojadomena.pl. Standard RFC 8460 obsługuje dwa typy odbiorców raportów: adres e-mail (rua=mailto:) lub endpoint HTTPS (rua=https://).

Krok 1 — Rekord DNS dla TLS-RPT

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

Możesz podać kilka adresów oddzielonych przecinkiem. Jeśli chcesz korzystać z zewnętrznego narzędzia analitycznego, dodaj endpoint HTTPS:

v=TLSRPTv1; rua=mailto:tls-raporty@twojadomena.pl,https://analityka.twojadomena.pl/tls-rpt

Krok 2 — Skrzynka odbiorcza dla raportów

Raporty TLS przychodzą jako załączniki .json.gz (skompresowany JSON). Skonfiguruj dedykowaną skrzynkę — najlepiej z filtrem, który automatycznie przenosi wiadomości z nagłówkiem Report-Type: tlsrpt do osobnego folderu. Przy dużej domenie możesz otrzymywać dziesiątki raportów dziennie.

Jak interpretować raporty TLS — praktyczne przykłady

Surowy JSON jest czytelny, ale wymaga wprawy. Poniżej trzy najczęstsze scenariusze i co z nimi zrobić.

Scenariusz 1: certificate-expired

Błąd certificate-expired w polu result-type oznacza, że certyfikat TLS na jednym z Twoich serwerów MX wygasł. Sprawdź pole receiving-mx-hostname, żeby zidentyfikować, który serwer wymaga odnowienia. Przy automatycznym odnowieniu (Let's Encrypt + certbot) ten błąd nie powinien się pojawiać — jeśli się pojawia, sprawdź harmonogram cron.

Scenariusz 2: starttls-not-supported

Serwer wysyłający zgłasza, że Twój MX nie ogłasza obsługi STARTTLS. Może to oznaczać błąd konfiguracji Postfixa/Exima lub — w rzadszych przypadkach — aktywny atak downgrade. Sprawdź logi SMTP na serwerze i porównaj IP z pola sending-mta-ip z listą znanych senderów.

Scenariusz 3: sts-policy-fetch-error

Serwer wysyłający nie mógł pobrać pliku polityki MTA-STS. Przyczyny to najczęściej: wygasły certyfikat na mta-sts.twojadomena.pl, niedostępność serwera WWW lub błędna ścieżka do pliku mta-sts.txt. W trybie enforce ten błąd powoduje, że wiadomości nie są dostarczane — napraw go priorytetowo.

MTA-STS i TLS-RPT a RODO oraz NIS2

Z perspektywy RODO (rozporządzenie 2016/679) szyfrowanie danych w tranzycie wpisuje się bezpośrednio w wymóg art. 32 ust. 1 lit. a — pseudonimizację i szyfrowanie danych osobowych jako środek techniczny zapewniający odpowiedni poziom bezpieczeństwa. E-maile zawierające dane osobowe klientów powinny być chronione właśnie takimi mechanizmami jak MTA-STS.

Dyrektywa NIS2 (2022/2555/UE), implementowana w Polsce przez nowelizację ustawy o krajowym systemie cyberbezpieczeństwa, nakłada na podmioty kluczowe i ważne obowiązek stosowania odpowiednich środków zarządzania ryzykiem cyberbezpieczeństwa (art. 21 NIS2). Wdrożenie MTA-STS i regularne przeglądanie raportów TLS-RPT to konkretne, udokumentowane działania, które można wykazać podczas audytu jako dowód aktywnego zarządzania ryzykiem w kanale e-mail.

Narzędzia do analizy raportów TLS

Ręczne parsowanie JSON sprawdza się przy kilku raportach tygodniowo. Przy większej skali warto sięgnąć po dedykowane rozwiązania.

• Parsery CLI — skrypty Python (tlsrpt-parser na PyPI) pozwalają zautomatyzować analizę i eksportować dane do CSV lub bazy danych.
• Platformy SaaS — część narzędzi do monitoringu DMARC obsługuje również TLS-RPT; raporty są wizualizowane w dashboardzie bez konieczności ręcznego rozpakowywania plików .gz.
• Własny endpoint HTTPS — jeśli masz zasoby developerskie, możesz wystawić prosty serwis przyjmujący raporty i ładujący je do Elasticsearch lub podobnego systemu.

W MailerPRO, gdzie wysyłka odbywa się przez własne serwery SMTP, warto skonfigurować TLS-RPT już na etapie uruchamiania domeny — raporty od pierwszego dnia pokażą, czy konfiguracja TLS jest poprawna i czy żaden z MX-ów nie sprawia problemów.

Najczęstsze błędy przy wdrożeniu

1. Przejście od razu do trybu enforce — bez okresu testowego ryzykujesz blokadę legalnej poczty, jeśli któryś MX ma problem z certyfikatem.
2. Brak aktualizacji pola id — serwery nie pobiorą nowej polityki, bo uznają ją za niezmienioną.
3. Certyfikat na mta-sts.twojadomena.pl z innej domeny — plik polityki musi być dostępny przez HTTPS z certyfikatem ważnym dla tej konkretnej subdomeny.
4. Ignorowanie raportów — TLS-RPT bez regularnego przeglądu to narzędzie, które tylko generuje ruch na skrzynce. Ustaw przypomnienie raz w tygodniu.
5. Niezgodność mx w polityce z rzeczywistymi rekordami MX — każdy hostname z rekordów MX musi być wymieniony w pliku mta-sts.txt lub pokryty przez wildcard.

TLS-RPT i MTA-STS to razem jeden z najprostszych do wdrożenia, a jednocześnie najbardziej niedocenianych elementów bezpieczeństwa SMTP. Kilka rekordów DNS, jeden plik tekstowy i dedykowana skrzynka na raporty — to wszystko, czego potrzebujesz, żeby mieć twardy dowód, że Twoja poczta jest szyfrowana w tranzycie i żaden serwer po drodze nie próbuje tego obejść. Zacznij od trybu testing, obserwuj raporty przez tydzień i przejdź do enforce. Twoje dane — i dane Twoich klientów — na to zasługują.