Інструменти мережевої діагностики
Політика звітності SMTP TLS
DNS та записи
Пошук DNS Усі записи DNS для будь-якого домену Пошук запису A IPv4-адреси домену Пошук запису AAAA IPv6-адреси домену Пошук MX Поштові сервери домену Пошук NS Авторитетні сервери імен Пошук TXT Записи TXT, SPF, верифікація Пошук CNAME Записи канонічного імені (псевдонім) Пошук SOA Запис Start of Authority Пошук SRV Записи розташування сервісів Пошук CAA Які CA можуть видавати сертифікати Зворотний 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 Перевірте заголовки відповіді, перенаправлення та безпеку Ping (TCP) Доступність і затримка через TCP Перевірка портів Які поширені порти відкритіДомен
Пошук WHOIS Реєстраційні дані для доменів, IP та ASNTLS-RPT (SMTP TLS Reporting) дозволяє домену отримувати щоденні звіти про збої з’єднань TLS від серверів-відправників, щоб ви могли виявити пошту, що доставляється незахищено. IPeek читає TXT-запис _smtp._tls і показує адресати звітності. Він доповнює MTA-STS і DANE, даючи видимість того, як ці політики працюють у реальних умовах.
TLS-RPT публікується як єдиний TXT-запис DNS за адресою _smtp._tls.your-domain. Запис містить тег версії й тег rua=, що перелічує, куди надсилати звіти — або адресу mailto, або кінцеву точку HTTPS. Сервери-відправники, що підтримують стандарт, агрегують результати своїх узгоджень TLS із вашими хостами MX за день і доставляють JSON-звіт до цих адресатів. Кожен звіт рахує успішні й невдалі сесії та категоризує збої, як-от помилки перевірки сертифіката чи недоступність STARTTLS, даючи вам зворотний зв’язок про реальну доставку.
IPeek підтверджує, чи існує TXT-запис _smtp._tls, і показує адресатів rua, які він розбирає. Переконайтеся, що версія — TLSRPTv1 і що кожна ціль rua є чинною скринькою чи URL HTTPS, який ви справді відстежуєте. Сам запис нічого не примушує; він лише запитує звіти, тож його наявність означає, що відправники знають, куди надсилати дані про збої 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 або URL HTTPS. Сервери-відправники, що підтримують 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 каже вам, як вона працює на практиці.