TLS-RPT: как узнать, что ваши письма летят без шифрования

SPF, DKIM, DMARC настроены. Письма доходят. Всё хорошо? Почти. Остаётся вопрос, о котором мало кто задумывается: шифруется ли трафик между серверами? И как узнать, если нет? Для этого существует TLS-RPT - протокол отчётности, который покажет, где шифрование ломается.

Что такое TLS-RPT и зачем он нужен

TLS-RPT (Transport Layer Security Reporting) - механизм, описанный в RFC 8460. Суть простая: принимающие серверы присылают вам отчёты о том, удалось ли установить TLS-соединение при доставке ваших писем. Если сервер получателя попытался использовать STARTTLS, но что-то пошло не так - истёк сертификат, не совпало имя хоста, не поддерживается версия протокола - вы получите отчёт с деталями.

Без TLS-RPT вы слепы. Письма могут передаваться открытым текстом между серверами, и вы об этом не узнаете. Логи отправляющего сервера покажут только свою сторону - что он попытался начать TLS. А что произошло на принимающей стороне? Тишина. TLS-RPT закрывает именно этот пробел.

Особенно важен TLS-RPT в связке с MTA-STS (RFC 8461) - политикой, которая говорит отправляющим серверам: «обязательно используйте TLS при доставке на мой домен, иначе не доставляйте вообще». MTA-STS задаёт правило, TLS-RPT показывает, кто это правило нарушает или не может выполнить. Одно без другого - половина картины.

Как работает: от DNS-записи до JSON-отчёта

Механизм состоит из трёх частей. Первая - DNS-запись, которую вы публикуете. Вторая - отправляющие серверы, которые эту запись читают и знают, куда слать отчёты. Третья - сами отчёты в формате JSON, которые приходят раз в сутки.

Когда сервер Gmail или Outlook отправляет письмо на ваш домен, он проверяет DNS на наличие записи _smtp._tls.yourdomain.com. Если находит - запоминает адрес для отчётов. В конце дня собирает статистику по всем попыткам доставки на ваш домен и отправляет сводный отчёт. Успешные TLS-соединения, неудачные попытки, причины сбоев - всё в одном файле.

Настройка DNS-записи

TLS-RPT настраивается одной TXT-записью в DNS. Формат минимальный - по сути, вы указываете только версию протокола и адрес для получения отчётов.

Отчёты на email

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com"

Разбор по частям:

• _smtp._tls - фиксированный префикс. Именно так, с двумя подчёркиваниями. Не путайте с _dmarc - формат другой.
• v=TLSRPTv1 - версия. Единственная на сегодня.
• rua=mailto: - адрес для агрегированных отчётов. Работает аналогично rua в DMARC.

Отчёты через HTTPS

Если не хотите засорять почтовый ящик JSON-файлами, можно указать HTTPS-эндпоинт. Отправляющие серверы будут делать POST-запрос с отчётом.

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=https://tlsrpt.yourdomain.com/report"

Можно указать оба варианта через запятую:

_smtp._tls.yourdomain.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com,https://tlsrpt.yourdomain.com/report"

HTTPS-вариант удобнее для автоматизации: эндпоинт принимает JSON, сразу парсит и складывает в базу. Не нужно разбирать MIME-вложения из писем. Но для начала email-вариант проще - не требует инфраструктуры.

Проверка записи

dig TXT _smtp._tls.yourdomain.com +short

Должна вернуться строка, начинающаяся с v=TLSRPTv1. Если пусто - проверьте имя записи (именно _smtp._tls, не _tls._smtp) и дождитесь пропагации DNS.

Структура JSON-отчёта

Отчёт приходит как gzip-архив (при отправке на email) или как JSON-тело POST-запроса (при HTTPS). Внутри - стандартная структура. Вот реалистичный пример отчёта, в котором часть соединений завершилась успешно, а часть - нет:

{
  "organization-name": "Google Inc.",
  "date-range": {
    "start-datetime": "2026-05-14T00:00:00Z",
    "end-datetime": "2026-05-14T23:59:59Z"
  },
  "contact-info": "smtp-tls-reporting@google.com",
  "report-id": "2026-05-14T00:00:00Z_yourdomain.com",
  "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": 1285,
        "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-ip": "203.0.113.10",
          "failed-session-count": 2
        },
        {
          "result-type": "starttls-not-supported",
          "sending-mta-ip": "209.85.220.42",
          "receiving-mx-hostname": "backup.yourdomain.com",
          "receiving-ip": "203.0.113.11",
          "failed-session-count": 1
        }
      ]
    }
  ]
}

Разберём ключевые поля:

• organization-name - кто прислал отчёт. Google, Microsoft, Yahoo, Mail.ru - крупные провайдеры поддерживают TLS-RPT.
• policy-type - тип политики. Обычно sts (MTA-STS) или no-policy-found, если MTA-STS не настроен.
• total-successful-session-count - количество успешных TLS-соединений за период. В идеале это единственное ненулевое число.
• total-failure-session-count - количество неудачных попыток. Любое значение больше нуля - повод разобраться.
• result-type - тип сбоя. Самые частые: certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure.

Типы ошибок и что с ними делать

Каждый result-type указывает на конкретную проблему. Вот полный список из RFC 8460 с переводом на практический язык:

starttls-not-supported. Принимающий сервер не поддерживает STARTTLS. Если это ваш основной MX - срочно включите TLS. Если резервный (backup MX) - он тоже должен поддерживать шифрование. Атакующие знают, что backup-серверы часто настроены небрежнее.

certificate-expired. Самая частая ошибка. Сертификат на MX-сервере просрочен. Решение очевидное: обновить сертификат. Настройте автообновление через Let's Encrypt или аналог. Certbot с cron - минута работы, которая избавит от этой проблемы навсегда.

certificate-host-mismatch. Имя хоста в сертификате не совпадает с MX-записью. Классика: MX указывает на mail.yourdomain.com, а сертификат выдан на yourdomain.com. Добавьте SAN (Subject Alternative Name) или выпустите отдельный сертификат для MX-хоста.

certificate-not-trusted. Сертификат не от доверенного CA. Self-signed сертификаты на продакшен-сервере - это не экономия, это отсутствие шифрования для строгих отправителей.

validation-failure. Общая ошибка валидации TLS. Может быть связана с неподдерживаемой версией протокола (TLS 1.0 и 1.1 уже считаются устаревшими), слабыми шифрами или проблемами с цепочкой сертификатов. Проверьте конфигурацию через openssl s_client -connect mail.yourdomain.com:25 -starttls smtp.

TLS-RPT + MTA-STS: полная картина

TLS-RPT работает и без MTA-STS - вы будете получать отчёты о TLS-сбоях в любом случае. Но максимальный смысл он приобретает именно в связке. MTA-STS говорит отправителям: «Требуйте TLS. Не fallback на plaintext». TLS-RPT показывает: «Вот кто не смог выполнить это требование и почему».

Для настройки MTA-STS нужны два элемента: DNS-запись и файл политики, доступный по HTTPS.

DNS-запись MTA-STS

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260515001"

Поле id - произвольная строка. Меняйте её при каждом обновлении политики - отправляющие серверы кэшируют политику и проверяют id, чтобы понять, нужно ли перечитать файл.

Файл политики

Должен быть доступен по адресу https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Именно HTTPS, именно этот путь.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: backup.yourdomain.com
max_age: 604800

• mode: testing - начните с этого. Отправители будут сообщать о сбоях через TLS-RPT, но не будут блокировать доставку.
• mode: enforce - после тестирования. Письма без TLS не доставляются.
• max_age - время кэширования политики в секундах. 604800 = одна неделя. Разумный минимум.

MTA-STS в режиме testing + TLS-RPT - безопасная отправная точка. Вы увидите реальную статистику по TLS-сбоям, ничего не сломав. Через две-три недели чистых отчётов переключайте на enforce.

Мониторинг на практике

Получать отчёты - полдела. Их нужно читать и реагировать. Вот три подхода - от простого к серьёзному.

1. Ручной разбор

Отчёты приходят как gzip-вложения. Распаковываете, смотрите JSON. Для домена с небольшим трафиком (до нескольких тысяч писем в день) этого хватает. Быстро проверить из терминала:

# Распаковать и найти ошибки
gunzip -c report.json.gz | python3 -m json.tool | grep -A5 "failure-details"

# Или с jq - компактнее
gunzip -c report.json.gz | jq '.policies[]."failure-details"[]?'

2. Скрипт-агрегатор

Для доменов с серьёзным объёмом стоит автоматизировать разбор. Простой Python-скрипт, который парсит все отчёты из папки и выводит сводку:

import json, gzip, glob, collections

failures = collections.Counter()

for path in glob.glob("reports/*.json.gz"):
    with gzip.open(path, "rt") as f:
        report = json.load(f)
    for policy in report.get("policies", []):
        for detail in policy.get("failure-details", []):
            key = detail["result-type"]
            count = detail["failed-session-count"]
            failures[key] += count

print("TLS failure summary:")
for error, count in failures.most_common():
    print(f"  {error}: {count}")

3. Сторонние сервисы

Если не хотите писать парсеры - есть готовые решения. Report-URI, Postmark, URIports принимают TLS-RPT (и DMARC заодно), парсят, визуализируют и шлют алерты. Указываете их адрес в rua - и дальше смотрите дашборд вместо JSON. Для большинства доменов с умеренным трафиком - оптимальный вариант.

Частые ошибки при настройке

• Перепутан порядок в имени записи. Правильно: _smtp._tls. Неправильно: _tls._smtp. Ошибка встречается часто, потому что интуитивно кажется, что сначала протокол, потом транспорт. В RFC записано наоборот.
• Почтовый ящик для отчётов переполнен. TLS-RPT от крупных провайдеров может генерировать десятки писем в день на загруженном домене. Используйте отдельный ящик или HTTPS-эндпоинт.
• Нет MTA-STS, но ожидают failure-details. Без MTA-STS отчёты будут приходить, но с policy-type: no-policy-found. Информативность ниже - нет данных о нарушении конкретной политики.
• Забыли про backup MX. Основной сервер настроен идеально: свежий сертификат, TLS 1.3, правильные шифры. А backup MX до сих пор на TLS 1.0 с self-signed сертификатом. Когда основной сервер недоступен, письма идут на backup - и TLS-RPT покажет поток ошибок.
• Не обновили id в MTA-STS после смены политики. Отправители кэшируют политику. Если поменяли файл, но не обновили id в DNS - серверы продолжат использовать старую версию до истечения max_age.

Кто отправляет TLS-RPT-отчёты

Не все провайдеры одинаково дисциплинированы. По состоянию на 2026 год: Google присылает отчёты стабильно и подробно. Microsoft (Outlook, Hotmail) - тоже, хотя формат иногда отличается мелочами. Yahoo поддерживает. Mail.ru и Yandex отправляют TLS-RPT, но с меньшей детализацией. Мелкие хостинги и корпоративные серверы - как повезёт.

На практике 80-90% входящего трафика среднего домена идёт от крупных провайдеров. Их отчётов достаточно, чтобы увидеть системные проблемы с TLS.

Чеклист: настройка за 15 минут

1. Убедитесь, что на всех MX-серверах (включая backup) установлены валидные TLS-сертификаты. Проверьте: openssl s_client -connect mail.yourdomain.com:25 -starttls smtp.
2. Добавьте TLS-RPT DNS-запись: _smtp._tls.yourdomain.com TXT "v=TLSRPTv1; rua=mailto:tlsrpt@yourdomain.com".
3. Создайте файл MTA-STS политики на https://mta-sts.yourdomain.com/.well-known/mta-sts.txt с mode: testing.
4. Добавьте MTA-STS DNS-запись: _mta-sts.yourdomain.com TXT "v=STSv1; id=20260515001".
5. Подождите 24-48 часов. Первые отчёты начнут приходить.
6. Проанализируйте failure-details. Исправьте проблемы с сертификатами и конфигурацией TLS.
7. Когда failure-count стабильно нулевой - переключите MTA-STS на mode: enforce и обновите id в DNS.

Зачем вкладываться в TLS-мониторинг

Шифрование email-трафика - не про галочку в чеклисте. Оппортунистический STARTTLS (когда серверы шифруют, если могут, но не настаивают) уязвим к downgrade-атакам. Злоумышленник между вашим сервером и получателем может подавить STARTTLS-объявление, и письмо уйдёт открытым текстом. MTA-STS + TLS-RPT - защита от этого сценария: вы декларируете обязательность шифрования и видите, когда оно не срабатывает.

Для доменов, которые отправляют конфиденциальные данные - финансовые уведомления, медицинскую информацию, юридические документы - это не опция, а необходимость. Регуляторы в ЕС (GDPR) и в России (ФЗ-152) требуют «адекватных мер защиты при передаче персональных данных». TLS-мониторинг - одна из таких мер.

И ещё один аспект: репутация домена. Почтовые провайдеры учитывают использование TLS как сигнал. Google прямо пишет в рекомендациях для отправителей: поддерживайте TLS 1.2+ на принимающих серверах. Это не решающий фактор для доставляемости, но в совокупности с SPF, DKIM, DMARC и чистой базой - формирует полную картину добросовестного отправителя.