Czym jest raportowanie TLS? W jaki sposób raporty TLS protokołu SMTP wykrywają niepowodzenia w dostarczaniu wiadomości e-mail?
przez
Ostatnia aktualizacja:
6 czas czytania: 2 minuty
Większość błędów związanych z protokołem SMTP TLS występuje niezauważalnie. Certyfikat traci ważność, serwer przestaje obsługiwać protokół STARTTLS lub osoba atakująca wymusza przejście na starszą wersję protokołu, w wyniku czego wiadomość e-mail jest wysyłana w postaci niezaszyfrowanej albo w ogóle nie dociera do adresata, a nie pojawia się żadne powiadomienie wyjaśniające przyczynę. Raportowanie TLS ma na celu wypełnienie tej luki.
Zdefiniowany w dokumencie RFC 8460 protokół SMTP TLS Reporting (TLS-RPT) zapewnia właścicielom domen standardowy sposób sprawdzania, kiedy dochodzi do awarii szyfrowania TLS między serwerami pocztowymi oraz jakie są tego przyczyny. W niniejszym artykule omówiono, jak działa protokół SMTP TLS, dlaczego może dojść do jego awarii, jak wygląda rzeczywisty raport TLS-RPT w podziale na poszczególne pola, a także jakie konkretne rodzaje awarii można napotkać podczas analizowania tych raportów.
Czym jest SMTP TLS i dlaczego występują z nim problemy?
Aby zrozumieć, dlaczego raportowanie TLS ma znaczenie, warto najpierw dowiedzieć się, dlaczego protokół SMTP w ogóle go potrzebował.
Protokół SMTP nie został zaprojektowany z myślą o szyfrowaniu
Protokół SMTP powstał w 1982 roku. W tamtym czasie sieć poczty elektronicznej była niewielką, zaufaną siecią, a protokół ten został zaprojektowany bez warstwy szyfrującej. Wiadomości były domyślnie przesyłane między serwerami w postaci zwykłego tekstu.
Ta luka pozostawała otwarta przez dziesięciolecia. Szyfrowanie dodano później jako opcję, a nie jako wymóg, i właśnie tu zaczyna się kolejny problem.
Protokół STARTTLS sprawił, że szyfrowanie stało się opcjonalne, a nie gwarantowane
Protokół STARTTLS umożliwia serwerowi wysyłającemu zwrócenie się do serwera odbierającego z prośbą o przekształcenie połączenia w trybie zwykłego tekstu w połączenie szyfrowane. Jeśli obie strony obsługują tę funkcję, wiadomość jest przesyłana w postaci zaszyfrowanej. Jeśli którakolwiek ze stron nie obsługuje tej funkcji lub jeśli coś zakłóci proces nawiązywania połączenia, połączenie w sposób niewidoczny dla użytkownika przechodzi z powrotem do trybu zwykłego tekstu, a wiadomość e-mail i tak zostaje dostarczona.
To właśnie ten mechanizm awaryjny stanowi główny problem, który protokół TLS-RPT miał na celu ujawnić. Żadna część standardu SMTP nie informuje, kiedy wiadomość została wysłana w postaci niezaszyfrowanej – niezależnie od tego, czy stało się to z powodu błędnej konfiguracji, czy też dlatego, że ktoś celowo usunął polecenie STARTTLS podczas przesyłania.
Czym jest raportowanie TLS (TLS-RPT)?
TLS-RPT to standard raportowania, zdefiniowany w dokumencie RFC 8460, który umożliwia właścicielom domen otrzymywanie regularnych, uporządkowanych raportów dotyczących błędów połączeń TLS w przypadku wiadomości e-mail wysyłanych do ich domeny. Nie zapobiega on występowaniu błędów. Informuje natomiast, kiedy one wystąpiły, jak często i z jakich przyczyn, dzięki czemu można rozwiązać leżący u ich podstaw problem.
Pełny opis pól raportu zgodnego z RFC 8460 oraz instrukcje dotyczące publikowania rekordu DNS typu TLS-RPT znajdziesz w naszym szczegółowym przewodniku poświęconym protokołowi TLS-RPT.
Związek między TLS-RPT a MTA-STS
TLS-RPT i MTA-STS działają jako para. MTA-STS pełni rolę mechanizmu egzekwującego: informuje serwery wysyłające, że wiadomości e-mail kierowane do Twojej domeny muszą być przesyłane za pośrednictwem zaszyfrowanego i uwierzytelnionego połączenia albo w ogóle nie mogą być wysyłane. TLS-RPT pełni rolę mechanizmu monitorującego: przekazuje informacje o tym, co się stało, gdy nie udało się nawiązać zaszyfrowanego połączenia. Jedno z nich ustanawia regułę, a drugie informuje, kiedy reguła ta zostaje uruchomiona.
Szczegółowe instrukcje dotyczące konfiguracji MTA-STS dla Twojej domeny znajdziesz w naszym przewodniku po wdrażaniu MTA-STS.
Jak działa raportowanie SMTP TLS – krok po kroku
- Właściciel domeny publikuje rekord DNS typu TLS-RPT, który informuje serwery wysyłające pocztę, dokąd mają wysyłać raporty o błędach.
- Serwer wysyłający próbuje dostarczyć wiadomość przy użyciu protokołu TLS, zazwyczaj poprzez STARTTLS.
- Jeśli ta próba zakończy się niepowodzeniem, serwer wysyłający rejestruje przyczynę niepowodzenia.
- Mniej więcej raz na 24 godziny serwer wysyłający zestawia te wyniki w raporcie w formacie JSON i wysyła go – zazwyczaj pocztą elektroniczną lub za pomocą żądania POST przez protokół HTTPS – na adres podany w rekordzie TLS-RPT domeny.
- Właściciel domeny otwiera raport i szuka pewnych wzorców: które serwery ulegają awariom, jak często i z jakich powodów.
Zawartość prawdziwego raportu TLS-RPT
Raporty TLS-RPT są dostarczane w formacie JSON, który nie jest zbyt czytelny dla człowieka. Poniżej znajduje się skrócony, realistyczny przykład oparty na formacie RFC 8460, zawierający podsumowanie sesji zakończonej powodzeniem oraz sesji zakończonej niepowodzeniem, a po nich – opis poszczególnych pól prostym językiem.
JSON
{
"organization-name": "Google Inc.",
"date-range": {
"start-datetime": "2026-07-01T00:00:00Z",
"end-datetime": "2026-07-01T23:59:59Z"
},
"contact-info": "[email protected]",
"report-id": "[email protected]",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: enforce",
"mx: mail.yourdomain.com",
"max_age: 604800"
],
"policy-domain": "yourdomain.com"
},
"summary": {
"total-successful-session-count": 4821,
"total-failure-session-count": 3
},
"failure-details": [
{
"result-type": "certificate-expired",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail.yourdomain.com",
"receiving-mx-helo": "mail.yourdomain.com",
"receiving-ip": "203.0.113.45",
"failed-session-count": 2,
"additional-information": "https://support.google.com/mail/answer/tls-rpt-cert-expired"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "209.85.220.41",
"receiving-mx-hostname": "mail2.yourdomain.com",
"receiving-ip": "203.0.113.46",
"failed-session-count": 1
}
}
}
]
}
Co tak naprawdę oznacza każde z tych pól
- nazwa-organizacji: Kto wysłał zgłoszenie. Zazwyczaj jest to duży dostawca usług pocztowych, taki jak Google, Microsoft czy Yahoo.
- zakres dat: Okres, którego dotyczy raport. Większość nadawców sporządza raporty w cyklu 24-godzinnym.
- dane-kontaktowe / identyfikator-zgłoszenia: Dane kontaktowe nadawcy oraz unikalny identyfikator tego konkretnego zgłoszenia. Przydatne, jeśli chcesz odwołać się do zgłoszenia w zgłoszeniu do pomocy technicznej.
- typ-polityki / ciąg-polityki: Polityka MTA-STS (lub DANE), którą serwer wysyłający odczytał w danym momencie dla Twojej domeny, przedstawiona dokładnie w postaci, w jakiej została pobrana. Pozwala to sprawdzić, czy opublikowana polityka jest zgodna z tym, co faktycznie otrzymują nadawcy.
- liczba-pomyślnych-sesji / liczba-nieudanych-sesji: Najważniejsza liczba. W tym przykładzie 4 821 z 4 824 prób dostarczenia zakończyło się powodzeniem, a 3 zakończyły się niepowodzeniem.
- szczegóły-błędów: Jeden wpis na każdy typ błędu wraz z liczbą wystąpień. To właśnie ta część wymaga podjęcia działań:
– certificate-expired: W przypadku 2 sesji, które zakończyły się niepowodzeniem, certyfikat TLS stracił ważność. Rozwiązanie: odnowić i ponownie zainstalować certyfikat.
– starttls-not-supported: Serwer odbiorczy (mail2.yourdomain.com) w ogóle nie odpowiedział na STARTTLS w przypadku 1 sesji. Rozwiązanie: sprawdź konfigurację TLS serwera, ponieważ może ona brakować lub być nieprawidłowo skonfigurowana.
Typowe rodzaje błędów TLS, które można zauważyć w raportach
Raporty TLS-RPT wykorzystują stały zestaw wartości typów wyników. Poniżej przedstawiono te, które pojawiają się najczęściej, wraz z ich znaczeniem oraz wskazówkami, jak postąpić w poszczególnych przypadkach.
Certyfikat wygasł
Certyfikat TLS serwera odbiorczego stracił ważność. Należy odnowić certyfikat przed upływem terminu jego ważności oraz ustawić przypomnienie z odpowiednim wyprzedzeniem przed kolejnym terminem wygaśnięcia.
Niezgodność nazwy certyfikatu
Przedstawiony certyfikat nie zgadza się z nazwą hosta oczekiwaną przez serwer wysyłający. Zazwyczaj oznacza to nieprawidłową konfigurację certyfikatu lub wpis DNS wskazujący na niewłaściwy host.
Funkcja STARTTLS nie jest obsługiwana
Serwer odbiorczy w ogóle nie odpowiedział na polecenie STARTTLS. Sprawdź, czy protokół TLS jest prawidłowo włączony na tym serwerze pocztowym, i upewnij się, że oprogramowanie serwera faktycznie go obsługuje.
Błąd pobierania zasad MTA-STS
Serwer wysyłający nie mógł pobrać pliku polityki MTA-STS przez protokół HTTPS. Sprawdź, czy plik polityki jest dostępny, ma prawidłowy format i jest udostępniany za pomocą ważnego certyfikatu.
Zbyt stara wersja protokołu TLS
Podczas nawiązywania połączenia podjęto próbę wynegocjowania wersji protokołu TLS, którą serwer wysyłający uznaje za przestarzałą lub niebezpieczną. Zaktualizuj konfigurację protokołu TLS na serwerze pocztowym, aby wyłączyć obsługę starszych wersji protokołu. Jeśli chodzi konkretnie o problemy z weryfikacją certyfikatów, zapoznaj się z naszym przewodnikiem dotyczącym DANE.
Dlaczego raportowanie SMTP TLS ma znaczenie
Raportowanie SMTP TLS jest korzystne z wielu różnych powodów. Poniżej przedstawiono niektóre z nich:
Bezpieczeństwo: Wykrywanie ataków typu „downgrade”
TLS-RPT wykrywa przypadki, w których połączenie zostało przekierowane na kanał niezaszyfrowany, co stanowi dokładnie schemat ataku typu „MITM downgrade”. Bez odpowiedniego zgłoszenia tego rodzaju przechwytywanie może trwać w nieskończoność, a nikt nie będzie o tym wiedział.
Widoczność: Eliminacja martwych punktów
Bez TLS-RPT nie ma pewnego sposobu, by dowiedzieć się, dlaczego wiadomości e-mail wysłane na Twoją domenę nie dotarły do adresata, ani czy zostały dostarczone bez szyfrowania. Raporty pokazują dokładnie, gdzie i dlaczego doszło do zerwania połączenia TLS, dzięki czemu nie musisz już zgadywać.
Wydajność: Szybsze rozwiązywanie problemów
Przeglądanie logów serwera w celu zidentyfikowania przyczyny problemu z dostawą zajmuje sporo czasu. Raporty TLS-RPT wskazują bezpośrednio serwer, na którym wystąpiła awaria, rodzaj awarii oraz częstotliwość jej występowania, co skraca czas rozwiązywania problemów z kilku dni do kilku minut.
Podsumowanie: Jak PowerDMARC ułatwia raportowanie dotyczące protokołu TLS
Raporty TLS-RPT są dostarczane w postaci nieprzetworzonych plików JSON, a ręczne przeglądanie ich z wielu różnych źródeł wysyłki szybko staje się uciążliwe. PowerDMARC automatycznie przekształca te raporty w przejrzyste pulpity nawigacyjne, pogrupowane według typu wyniku i źródła wysyłki, dzięki czemu możesz sprawdzić, co nie działa i gdzie, bez konieczności otwierania ani jednego pliku JSON.
Pomagamy właścicielom domen:
- Automatycznie przetwarza surowe dane JSON na czytelne pulpity nawigacyjne, bez konieczności ręcznego dekodowania plików raportów TLS-RPT.
- Filtruj według dwóch widoków raportu: według źródła wysyłki (tryb polityki, liczba sesji, łączna liczba dostarczeń) oraz według wyników (sesje zakończone powodzeniem u góry, sesje zakończone niepowodzeniem poniżej).
- Brak możliwości szczegółowego przeglądu nieudanej sesji w celu wyświetlenia nazwy hosta serwera odbiorczego, adresu IP, liczby błędów oraz przyczyny, dzięki czemu rozwiązanie problemu jest widoczne na pierwszy rzut oka.
- Przesyłaj pliki w formatach JSON, ZIP lub GZ wraz z historią przesyłania, dzięki czemu w dowolnym momencie można ponownie przejrzeć poprzednie raporty.
- Automatyczne generowanie i sprawdzanie poprawności rekordów CNAME niezbędnych do zapewnienia przepływu raportów dzięki konfiguracji DNS za pomocą jednego kliknięcia, a także możliwość ustawienia adresu, na który mają być wysyłane raporty zbiorcze.
- Eksportuj pliki JSON w formacie surowym, gdy potrzebujesz oryginalnego pliku do zgłoszenia lub dalszej analizy, korzystając ze szczegółowych uprawnień określających, którzy użytkownicy na koncie mogą przesyłać raporty.
Rozpocznij bezpłatny okres próbny lub umów się na prezentację, aby sprawdzić to na danych swojej własnej domeny.
Najczęściej zadawane pytania
1. Do czego służy raportowanie TLS?
Raporty TLS służą do wykrywania i diagnozowania awarii związanych z dostarczaniem zaszyfrowanych wiadomości e-mail, w tym wygasłych certyfikatów, nieprawidłowo skonfigurowanych serwerów oraz ataków typu „downgrade”, poprzez generowanie regularnych raportów dotyczących tego, co poszło nie tak i dlaczego.
2. Czy protokół SMTP TLS to to samo co TLS-RPT?
Tak. Terminy „SMTP TLS reporting” i „TLS-RPT” odnoszą się do tego samego standardu RFC 8460. TLS-RPT to skrócona nazwa tego protokołu.
3. Jak skonfigurować raportowanie TLS dla mojej domeny?
Aby skonfigurować tę funkcję dla swojej domeny, wystarczy opublikować rekord DNS TLS-RPT, określający miejsce, do którego mają być wysyłane raporty. Możesz wygenerować taki rekord za pomocą naszego generatora rekordów TLS-RPT, a następnie sprawdzić, czy działa, korzystając z naszego narzędzia do sprawdzania TLS-RPT.
4. Co się stanie, jeśli nie włączę TLS-RPT?
Jeśli nie włączysz TLS-RPT, serwery pocztowe nadal będą samodzielnie próbowały zastosować szyfrowanie TLS, ale nie będziesz mieć wglądu w ewentualne awarie. Ataki typu „downgrade”, wygasłe certyfikaty i nieprawidłowo skonfigurowane serwery mogą pozostawać niezauważone przez nieograniczony czas.
5. Czy TLS-RPT działa bez MTA-STS?
Tak, TLS-RPT może samodzielnie generować raporty dotyczące awarii protokołu TLS. Najbardziej przydatne jest jednak połączenie go z MTA-STS, ponieważ MTA-STS wymusza dostarczanie wiadomości w formie zaszyfrowanej, a TLS-RPT generuje raporty dotyczące tego, co się stało, gdy wymóg ten zaczął obowiązywać.
6. Jak często wysyłane są raporty SMTP TLS?
Większość nadawców generuje i dostarcza raporty mniej więcej raz na 24 godziny, choć dokładny odstęp czasu może się różnić w zależności od dostawcy.
Ekspert ds. bezpieczeństwa domen i poczty e-mail w PowerDMARC
Ahona jest Marketing Managerem w PowerDMARC, z ponad 5-letnim doświadczeniem w pisaniu na tematy związane z cyberbezpieczeństwem, specjalizującym się w bezpieczeństwie domen i poczty elektronicznej. Ahona posiada dyplom ukończenia studiów podyplomowych w zakresie dziennikarstwa i komunikacji, umacniając swoją karierę w sektorze bezpieczeństwa od 2019 roku.
Latest posts by Ahona Rudra (zobacz wszystkie)
- Czym jest raportowanie TLS? Jak raporty TLS protokołu SMTP wykrywają niepowodzenia w dostarczaniu wiadomości e-mail – 9 lipca 2026 r.
- Najlepsze serwery DMARC MCP w 2026 roku: Połącz sztuczną inteligencję z danymi dotyczącymi uwierzytelniania wiadomości e-mail – 9 lipca 2026 r.
- Studium przypadku DMARC MSP: Firma The Great Geek rozszerza ofertę usług w zakresie bezpieczeństwa poczty elektronicznej dla małych i średnich przedsiębiorstw dzięki PowerDMARC – 25 czerwca 2026 r.
