Инструменты сетевой диагностики
Политика отчётности SMTP TLS
DNS и записи
Поиск DNS Все записи DNS для любого домена Поиск записи A Адреса IPv4 для домена Поиск записи AAAA Адреса IPv6 для домена Поиск MX Почтовые серверы домена Поиск NS Авторитетные серверы имён Поиск TXT Записи TXT, SPF, верификация Поиск CNAME Записи канонического имени (псевдонима) Поиск SOA Запись Start of Authority Поиск SRV Записи расположения сервисов Поиск CAA Какие УЦ могут выпускать сертификаты Обратный DNS (PTR) IP-адрес в имя хоста Проверка DNSSEC Подписан ли домен и проходит ли валидацию? Проверка здоровья DNS Полный отчёт о делегировании и состоянии DNSДоставляемость почты
Проверка SPF Проверьте вашу запись Sender Policy Framework Проверка DMARC Изучите и оцените вашу политику DMARC Проверка DKIM Найдите и проверьте ваш открытый ключ DKIM Проверка чёрных списков Проверьте IP по почтовым блок-листам (DNSBL) Тест SMTP Подключение к почтовому серверу и проверка STARTTLS Проверка MTA-STS Принудительная политика TLS для входящей почты Проверка BIMI Запись логотипа бренда для почты Проверка TLS-RPT Политика отчётности SMTP TLSСеть и веб
Проверка сертификата SSL Изучите сертификат TLS сайта и срок его действия Проверка HTTP-заголовков Изучите заголовки ответа, редиректы и безопасность Пинг (TCP) Доступность и задержка по TCP Проверка портов Какие распространённые порты открытыДомен
Поиск WHOIS Регистрационные данные для доменов, IP и ASNTLS-RPT (SMTP TLS Reporting) позволяет домену получать ежедневные отчёты о сбоях TLS-соединений от отправляющих серверов, чтобы вы могли выявлять почту, доставляемую небезопасно. IPeek читает TXT-запись _smtp._tls и показывает адресаты отчётов. Он дополняет MTA-STS и DANE, давая видимость того, как эти политики работают в реальных условиях.
TLS-RPT публикуется как единственная DNS-запись TXT по адресу _smtp._tls.your-domain. Запись содержит тег версии и тег rua=, перечисляющий, куда следует отправлять отчёты — либо адрес mailto, либо HTTPS-конечную точку. Отправляющие серверы, поддерживающие стандарт, агрегируют результаты своих согласований TLS с вашими хостами MX за сутки и доставляют JSON-отчёт по этим адресам. Каждый отчёт подсчитывает успешные и неудавшиеся сессии и категоризирует сбои, такие как ошибки проверки сертификата или недоступность STARTTLS, давая вам обратную связь о реальной доставке.
IPeek подтверждает, существует ли TXT-запись _smtp._tls, и показывает разобранные адресаты rua. Убедитесь, что версия — TLSRPTv1 и что каждая цель rua — это валидный почтовый ящик или HTTPS-URL, который вы действительно отслеживаете. Сама запись ничего не обеспечивает; она лишь запрашивает отчёты, так что её наличие означает, что отправители знают, куда слать данные о сбоях TLS. Когда отчёты начнут приходить, смотрите на типы сбоев: certificate-expired, ошибки проверки и starttls-not-supported — каждый указывает на конкретное исправление в вашей принимающей инфраструктуре, прежде чем они вызовут скрытые проблемы доставки.
MTA-STS и DANE обеспечивают TLS на входящей почте, но обеспечение безопасно лишь тогда, когда вы видите, как оно влияет на реальный трафик. TLS-RPT даёт эту видимость: когда вы развёртываете MTA-STS в режиме testing, отчёты показывают, какие отправители столкнулись со сбоями TLS, прежде чем вы перейдёте на enforce. То же касается несоответствий DANE TLSA. Воспринимайте TLS-RPT как уровень мониторинга вашей TLS-конфигурации, развёрнутый вместе с механизмами обеспечения, а не вместо них, чтобы рано выявлять проблемы сертификатов и настройки.
Это TXT-запись, публикуемая по адресу _smtp._tls.your-domain, которая запрашивает отчёты о сбоях TLS. Запись содержит тег версии v=TLSRPTv1 и тег rua=, указывающий, куда идут отчёты, — в виде адреса mailto или HTTPS-URL. Отправляющие серверы, поддерживающие TLS-RPT, используют его, чтобы знать, куда доставлять свои ежедневные сводные отчёты о TLS-соединениях с вашим доменом.
Отчёт TLS-RPT — это JSON-документ, подытоживающий сутки согласований TLS между отправляющим сервером и вашими хостами MX. Он подсчитывает успешные и неудавшиеся сессии и разбивает сбои по типам, таким как просроченные сертификаты, ошибки проверки сертификата или недоступность STARTTLS. Это позволяет точно определить, какие принимающие хосты или сертификаты вызывают небезопасные или неудавшиеся доставки.
Нет. TLS-RPT — это исключительно механизм отчётности, и сам по себе он ничего не обеспечивает. Обеспечение исходит от MTA-STS или DANE, которые требуют TLS и могут блокировать небезопасную доставку. TLS-RPT соседствует с этими политиками как уровень мониторинга, давая вам видимость того, как часто TLS проходит или сбоит, чтобы вы могли уверенно развёртывать обеспечение.
Опубликуйте TXT-запись по адресу _smtp._tls.your-domain, содержащую v=TLSRPTv1 и тег rua=, указывающий на почтовый ящик или HTTPS-конечную точку, которые вы отслеживаете, например rua=mailto:tlsrpt@your-domain. Выбирайте адресат, за которым действительно следите, ведь отчёты приходят ежедневно в формате JSON. Сочетайте его с MTA-STS или DANE, чтобы отчёты описывали, как работает ваша обеспеченная политика TLS.
TLS-RPT даёт видимость, которая делает развёртывание MTA-STS безопасным. Когда вы публикуете политику MTA-STS в режиме testing, отправляющие серверы сообщают о любых сбоях TLS через TLS-RPT, так что вы видите, какие отправители были бы заблокированы, прежде чем перейти на enforce. Эти два механизма рассчитаны на совместную работу: MTA-STS задаёт политику, а TLS-RPT сообщает, как она работает на практике.