Sprawdzanie rekordu TLS-RPT
Sprawdza rekord _smtp._tls, który mówi serwerom nadawców, gdzie zgłaszać problemy z TLS przy łączeniu z Twoimi serwerami poczty — to informacja zwrotna dla MTA-STS i DANE.
- DNS na żywo
- RFC 8460
Jak działa to sprawdzenie
Odpytujemy rekord TXT _smtp._tls.<domena>. Rekordy, które nie zaczynają się od „v=TLSRPTv1;”, są pomijane, a pozostać musi dokładnie jeden (RFC 8460, sekcja 3).
Pole rua może zawierać kilka adresów rozdzielonych przecinkami. Dozwolone są tylko mailto: i https:; sprawdzamy każdy adres i nazwę hosta.
Ograniczenia
- Nie wiemy, czy raporty faktycznie docierają i czy skrzynka lub serwer je przyjmuje.
- TLS-RPT tylko raportuje problemy; nie zmienia sposobu dostarczania poczty.
- Nie zapisujemy ani nie logujemy sprawdzanych domen.
Najczęstsze pytania
Co zawiera raport TLS?
Dzienne podsumowanie w formacie JSON od organizacji nadawcy: ile sesji wynegocjowało TLS, ile się nie udało i dlaczego — na przykład z powodu certyfikatu lub polityki, której nie dało się pobrać (RFC 8460, sekcja 4).
Czy TLS-RPT ma sens bez MTA-STS?
Najbardziej przydaje się razem z MTA-STS lub DANE, bo wtedy błędy TLS oznaczają niedostarczoną pocztę. Bez nich raporty i tak pokażą nadawców, którzy nie zdołali wynegocjować TLS.
Czy raporty mogą trafiać do innej domeny?
Tak. W odróżnieniu od DMARC, TLS-RPT nie wymaga rekordu autoryzującego zewnętrzne adresy; zadziała każdy poprawny adres mailto: lub https:.
Dlaczego nie dostaję jeszcze raportów?
Raport obejmuje pełną dobę i przychodzi tylko od nadawców obsługujących TLS-RPT, którzy tego dnia wysyłali do Ciebie pocztę. Pierwszego raportu spodziewaj się dzień lub dwa po opublikowaniu rekordu.