Bezpłatne narzędzie do sprawdzania TLS-RPT — natychmiast zweryfikuj rekord DNS dotyczący raportowania TLS dla protokołu SMTP swojej domeny, sprawdź jego zgodność z normą RFC 8460, upewnij się, że jest on zgodny z Twoją polityką MTA-STS, oraz potwierdź, że adresy raportowania faktycznie mogą odbierać raporty.
Dlaczego warto sprawdzić swój wpis TLS-RPT
Nawet poprawnie skonfigurowany serwer pocztowy może w sposób niewidoczny nie dostarczyć wiadomości za pośrednictwem protokołu TLS. Jedynym sposobem na wykrycie takiej sytuacji jest rekord TLS-RPT.
Wczesne wykrywanie błędów TLS
Sprawdź dokładnie, kiedy serwery wysyłające pocztę nie mogą nawiązać szyfrowanego połączenia z Twoją domeną, zanim przerodzi się to w problem z dostarczaniem wiadomości.
Sprawdź poprawność konfiguracji MTA-STS
Raporty TLS-RPT ujawniają wszelkie awarie związane z polityką lub połączeniami spowodowane egzekwowaniem MTA-STS — narzędzie to odczytuje aktualną politykę MTA-STS, dzięki czemu można sprawdzić parowanie.
Potwierdź, że mogą napływać zgłoszenia
Adres do przesyłania raportów jest bezużyteczny, jeśli poczta nie może do niego dotrzeć. Sprawdzamy, czy każde miejsce docelowe RUA faktycznie dysponuje lokalizacją, do której można dostarczać raporty.
Jak korzystać z narzędzia TLS-RPT Checker
Wyszukiwanie TLS-RPT trwa zaledwie kilka sekund. Wykonaj te trzy kroki, aby sprawdzić konfigurację raportowania TLS w protokole SMTP.
1
Wpisz swoją domenę. Wpisz swoją domenę główną (np. example.com) – nie trzeba dodawać _smtp._tls przedrostek – zajmujemy się tym automatycznie.
2
Wybierz serwer DNS i sprawdź. Wybierz Google, Cloudflare, OpenDNS lub Quad9, a następnie naciśnij klawisz Enter lub kliknij przycisk „Sprawdź wpis”, aby wysłać zapytanie DNS na żywo z naszego serwera.
3
Przejrzyj wyniki. Sprawdzamy zgodność tagów „version” i „rua” z normą RFC 8460, weryfikujemy powiązaną politykę MTA-STS oraz upewniamy się, że każdy punkt docelowy raportowania jest dostępny.
Czym jest rekord TLS-RPT?
Raportowanie SMTP TLS (TLS-RPT) to standard poczty elektronicznej zdefiniowany w dokumencie RFC 8460, który umożliwia właścicielom domen otrzymywanie raportów dotyczących niepowodzeń w dostarczaniu wiadomości e-mail za pośrednictwem szyfrowanego połączenia TLS. Działa on w połączeniu z protokołem MTA-STS, pozwalając wykrywać problemy — takie jak nieudana weryfikacja certyfikatu, ataki typu „downgrade” czy brak obsługi protokołu STARTTLS — które w przeciwnym razie pozostałyby niezauważone.
Pojedynczy rekord TXT
Opublikowano na stronie _smtp._tls.yourdomain.com, informuje serwery pocztowe odbierające wiadomości, dokąd mają wysyłać zbiorcze raporty dotyczące prób nawiązania połączenia TLS.
Zgłaszanie, a nie egzekwowanie
TLS-RPT sam w sobie niczego nie blokuje ani nie egzekwuje. Jest to wyłącznie kanał informacji zwrotnej – warstwa widoczności, która współdziała z MTA-STS.
Bezpłatne i niewymagające dużego wysiłku
Wystarczą dwa tagi. Nie jest to obowiązkowe, ale stanowi to sprawdzoną praktykę, która nic nie kosztuje i pozwala wyeliminować prawdziwą lukę w widoczności.
_smtp._tls.twojadomena.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]" ; v -> określa, że rekord jest typu TLS-RPT (RFC 8460) ; rua -> miejsce, do którego wysyłane są zbiorcze raporty TLS
TLS-RPT a MTA-STS: jaka jest różnica?
MTA-STS (Mail Transfer Agent Strict Transport Security) to mechanizm egzekwujący – informuje serwery wysyłające pocztę, że dana domena wymaga prawidłowego połączenia szyfrowanego protokołem TLS, oraz blokuje dostarczanie wiadomości przez połączenia nieszyfrowane lub nieprawidłowo skonfigurowane. TLS-RPT to mechanizm raportowania – sam w sobie niczego nie wymusza, ale informuje serwery wysyłające, gdzie mają zgłaszać zarówno udane, jak i nieudane próby nawiązania połączenia TLS, w tym te spowodowane przez politykę MTA-STS użytkownika.
Oba rozwiązania zostały zaprojektowane tak, by działały razem: MTA-STS wymusza szyfrowanie, a TLS-RPT zapewnia pętlę sprzężenia zwrotnego, dzięki której można sprawdzić, czy wymuszanie to nie powoduje problemów z dostarczaniem wiadomości. Dlatego właśnie to narzędzie sprawdza również politykę MTA-STS — pozwala to upewnić się, że obie strony są ze sobą spójne. Możesz dokładniej przyjrzeć się kwestii wymuszania za pomocą naszego narzędzia do sprawdzania rekordów MTA-STS.
Wyjaśnienie tagów TLS-RPT
Każdy rekord TLS-RPT składa się z niewielkiego zestawu znaczników. Oto, co oznacza każdy z nich.
v=
Wersja (wymagane)
Określa ten rekord jako rekord TLS-RPT. Musi to być pierwszy tag i zawsze musi być ustawiony na TLSRPTv1.
rua=
URI zbiorczego raportu (wymagane)
Gdzie wysyłane są zbiorcze raporty TLS. Przyjmuje wartość mailto: adres, a https:// punkt końcowy lub listę obu tych elementów, oddzieloną przecinkami.
Typowe problemy związane z TLS-RPT i sposoby ich rozwiązywania
Oto typowe problemy związane z konfiguracją TLS-RPT oraz wyjaśnienie, co każdy z tych wyników oznacza dla Twojej domeny.
Nie znaleziono żadnego zapisu
Brak wpisów w _smtp._tls
W odpowiednim hoście nie ma rekordu TXT, więc nie otrzymujesz żadnych zgłoszeń o niepowodzeniu dostarczenia przez TLS.
Opublikuj rekord TXT w strefie _smtp._tls.twojadomena.com z prawidłowymi tagami v= i rua=.
Nieprawidłowy tag v=
Nie rozpoznano jako TLS-RPT
Rekord nie zaczyna się od v=TLSRPTv1, więc serwery pocztowe nie potraktują go jako rekordu TLS-RPT.
Ustaw v=TLSRPTv1 jako dokładny, pierwszy znacznik w rekordzie.
Brakujący lub nieprawidłowy parametr „rua=”
Raporty nie mają gdzie trafić
Nie zdefiniowano miejsca docelowego raportu lub adres URI typu „mailto”/„https” jest nieprawidłowy, w związku z czym nie można dostarczyć raportów.
Dodaj co najmniej jeden prawidłowy adres URI w formacie „mailto:” lub „https:” i upewnij się, że odbiorca może go odebrać.
Wiele rekordów
Więcej niż jeden rekord TLS-RPT
RFC 8460 nie zezwala na obecność dwóch lub więcej rekordów TLS-RPT na tym samym hoście, co może powodować błędy walidacji.
Zredukuj do dokładnie jednego rekordu TLS-RPT, w którym wszystkie miejsca docelowe znajdą się w jednym tagu „rua”.
Jak interpretować raporty TLS-RPT
Gdy Twój wpis zostanie opublikowany, serwery odbierające pocztę zaczną wysyłać okresowe raporty zbiorcze na Twój adres RUA. Oto, co się w nich znajduje.
Szczegóły polityki
Rodzaj obowiązującej polityki (np. sts, no-policy-found) dla domeny wysyłającej objętej raportem.
Podsumowanie danych liczbowych
Łączna liczba udanych i nieudanych prób nawiązania połączenia TLS w okresie sprawozdawczym, zazwyczaj trwającym 24 godziny.
Szczegóły błędu
Kategorie błędów – wygasły certyfikat, niezgodność nazwy hosta, brak obsługi protokołu STARTTLS – wraz z przykładowymi adresami IP źródłowymi.
Surowy format JSON raportów jest trudny do odczytania przy dużej liczbie danych, zwłaszcza gdy otrzymujesz je od dziesiątek różnych dostawców poczty. Platforma PowerDMARC automatycznie przetwarza raporty TLS-RPT na czytelny pulpit nawigacyjny, na którym wyświetlane są dane dotyczące DMARC, SPF i MTA-STS.
Jak opublikować wpis TLS-RPT
Zaloguj się do panelu swojego dostawcy usług DNS i dodaj nowy rekord TXT z poniższymi wartościami.
Pełne rozprzestrzenienie się zmian w DNS może potrwać do 48 godzin, choć większość dostawców dokonuje aktualizacji w ciągu kilku godzin. Po wprowadzeniu zmian skorzystaj z powyższego narzędzia do sprawdzania, aby upewnić się, że zostały one opublikowane poprawnie.
Najczęściej zadawane pytania
Czy TLS-RPT to to samo co DMARC?
Nie. Raporty DMARC dotyczą błędów uwierzytelniania (SPF/DKIM) w wiadomościach wysyłanych z Twojej domeny. Raporty TLS-RPT dotyczą konkretnie niepowodzeń w nawiązaniu szyfrowanego połączenia TLS podczas dostarczania poczty do Twojej domeny. Są to standardy uzupełniające się, ale niezależne.
Czy dane dotyczące mojej domeny są przesyłane na wasze serwery?
Wprowadzona przez Ciebie domena jest wysyłana na nasz serwer, który przeprowadza w Twoim imieniu wyszukiwanie DNS za pomocą wybranego przez Ciebie publicznego serwera DNS — jest to to samo zapytanie, jakie każdy mógłby wykonać za pomocą dig polecenie. Nie rejestrujemy ani nie przechowujemy informacji o sprawdzanych domenach ani o zwróconych wpisach.
Czy do korzystania z TLS-RPT potrzebny jest protokół MTA-STS?
Nie, TLS-RPT można wdrożyć samodzielnie. Największą wartość ma jednak w połączeniu z MTA-STS, ponieważ zgłasza wszelkie awarie połączeń lub niepowodzenia związane z polityką, które wynikają z egzekwowania MTA-STS. To narzędzie sprawdzające analizuje również politykę MTA-STS, dzięki czemu można sprawdzić, czy oba rozwiązania są ze sobą zgodne.
Czy TLS-RPT jest obowiązkowe?
Nie, TLS-RPT jest opcjonalne i nie jest wymagane przez żadnego z głównych dostawców usług pocztowych. Jest to bezpłatny i niewymagający dużego nakładu pracy sposób na uzyskanie wglądu w problemy z dostarczaniem wiadomości za pomocą protokołu TLS, które w przeciwnym razie pozostałyby niewidoczne, i jest uważane za najlepszą praktykę obok DMARC, SPF, DKIM i MTA-STS.
Czy mogę korzystać z wielu adresów RUA?
Tak. Można podać wiele miejsc docelowych, oddzielając je przecinkami, i łączyć adresy typu „mailto:” oraz „https:” – na przykład rua=mailto:[email protected],https://reports.example.com/tlsrpt. Narzędzie to weryfikuje każdą z nich i sprawdza, czy adresy e-mailowe rzeczywiście mogą odbierać wiadomości.
Czy raporty mogą być wysyłane na domenę inną niż moja?
Tak. W przeciwieństwie do DMARC, norma RFC 8460 nie definiuje dla protokołu TLS-RPT rekordu autoryzacji dla miejsc docelowych zewnętrznych, więc można skierować parametr „rua” na zewnętrzny serwer przetwarzający (taki jak PowerDMARC) bez konieczności dodatkowej konfiguracji DNS. Narzędzie to oznaczy miejsca docelowe zewnętrzne dla większej przejrzystości, ale są one całkowicie prawidłowe.
Dlaczego mój rekord TLS-RPT jest wyświetlany jako „nie znaleziono”?
Albo wpis nie został jeszcze opublikowany, albo zmiany w DNS nie zostały jeszcze w pełni zaktualizowane, albo wpis został dodany przy niewłaściwym hoście – musi być dokładnie _smtp._tls.yourdomain.com, a nie tylko yourdomain.com.
Czy zamiast adresu e-mail mogę użyć punktu końcowego HTTPS do generowania raportów?
Tak. RFC 8460 obsługuje zarówno adresy URI typu „mailto:”, jak i „https:”. Punkt końcowy https musi akceptować żądania HTTP POST zawierające raport w postaci danych JSON skompresowanych w formacie gzip — rozwiązanie to jest zazwyczaj stosowane przez większe organizacje lub platformy, takie jak PowerDMARC, które przetwarzają raporty automatycznie.
Zautomatyzuj proces uwierzytelniania wiadomości e-mail
PowerDMARC monitoruje Twoje rekordy DMARC, SPF, DKIM, BIMI, MTA-STS i TLS-RPT na jednym pulpicie nawigacyjnym – wysyłając powiadomienia natychmiast po wystąpieniu jakiejkolwiek awarii.
