Генератор TLS-RPT

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

TLS-RPT (SMTP TLS Reporting, RFC 8460) — это способ узнать, как чужие серверы подключаются к вашим. Серверы, которые доставляют почту на ваш домен, раз в сутки присылают сводку: сколько соединений с вашими MX прошло по TLS, сколько сорвалось и почему. Речь о входящей почте, а не об исходящей.

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

Куда публиковать и из чего состоит запись

TXT-записью на имя _smtp._tls.ваш-домен. В поле имени в панели обычно достаточно вписать _smtp._tls. Оба подчёркивания обязательны, и порядок именно такой: запись на _tls._smtp никто искать не будет.

v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://tlsrpt.example.com/report

Тегов два. v=TLSRPTv1 задаёт версию и стоит первым. rua= говорит, куда слать отчёты: mailto: или https: для приёма POST-запросом, несколько адресов через запятую. Отправитель вправе доставить отчёт только на один из них, поэтому главный адрес ставьте первым. Подтверждать чужой домен, как в DMARC, не нужно. RFC 8460 считает риск злоупотребления здесь меньшим.

Запись с v=TLSRPTv1 должна быть одна. Если их две, отправители считают, что TLS-RPT у домена нет. Проверить публикацию можно так:

dig +short TXT _smtp._tls.example.com

Кто присылает отчёты

Отчёты шлют не все. По данным сервиса URIports на август 2024 года, больше всего их отправляют Google, Microsoft, Comcast, Mail.ru и Mimecast. Там же отмечено, что Microsoft доставляет отчёт только на первый адрес из rua, а стандарт такое поведение допускает.

Письмо с отчётом по стандарту подписано DKIM отправителя, и отчёт без подписи получатель должен игнорировать. Доставляется оно даже при сбое TLS, то есть иногда без шифрования, ведь иначе о поломке шифрования некому было бы сообщить.

Что внутри JSON-отчёта

Отчёт охватывает сутки по UTC и приходит с задержкой в несколько часов, обычно сжатым в gzip. Сокращённый пример:

{
  "organization-name": "Example Sender",
  "date-range": {
    "start-datetime": "2026-09-16T00:00:00Z",
    "end-datetime": "2026-09-16T23:59:59Z"
  },
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "example.com" },
    "summary": {
      "total-successful-session-count": 1285,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "sending-mta-ip": "198.51.100.7",
      "receiving-mx-hostname": "mail.example.com",
      "receiving-ip": "203.0.113.10",
      "failed-session-count": 3
    }]
  }]
}

• organization-name называет отправителя отчёта, date-range показывает, за какие он сутки.
• policy-type показывает, по какому правилу проверялось соединение: sts для MTA-STS, tlsa для DANE или no-policy-found, если политики нет.
• total-successful-session-count и total-failure-session-count в блоке summary считают, сколько соединений прошло и сколько сорвалось. Именно их стоит выводить на график.
• failure-details содержит по строке на каждую причину: тип ошибки, IP отправителя, имя и IP вашего MX и число сорвавшихся сессий в failed-session-count.

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

• starttls-not-supported: MX не предложил STARTTLS. Если это резервный сервер, его тоже нужно настроить: при недоступном основном почта пойдёт туда.
• certificate-expired: сертификат на MX просрочен. Обычно это не сработавшее автопродление.
• certificate-host-mismatch: имя в сертификате не совпадает с именем MX. Например, MX указывает на mail.example.com, а сертификат выдан на example.com.
• certificate-not-trusted: сертификат не от доверенного центра, чаще всего самоподписанный.
• validation-failure: общая ошибка, которая не подошла под остальные. Подробности отправитель пишет в failure-reason-code, а посмотреть, что отдаёт сервер, можно в проверке SMTP-сервера.
• sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid: не удалось скачать или разобрать политику MTA-STS, или у сайта с политикой проблемы с сертификатом.
• tlsa-invalid, dnssec-invalid, dane-required относятся к DANE: неверная запись TLSA, невалидный ответ DNSSEC или отсутствие TLSA там, где отправитель требует DANE.

Кратковременные сбои вроде таймаутов стандарт сообщать не обязывает, так что каждая строка в отчёте заслуживает внимания.

На что смотреть в первую очередь

Единичные сбои случаются: сеть, чей-то сломанный релей. Тревожный сигнал выглядит иначе: устойчивая доля отказов у одного отправителя или одновременный рост certificate-expired у всех сразу, и это обычно не обновившийся сертификат на вашем MX.

Ещё по отчётам ловится starttls-not-supported с адресов, которые вы считали защищёнными. Обычно виноват промежуточный шлюз или антиспам-прокси, вырезающий STARTTLS из ответа сервера. И отдельно резервный MX: основной сервер настроен идеально, а запасной годами живёт со старым сертификатом, и ошибки появляются, только когда основной недоступен.

Как разбирать отчёты

Первые недели отчёты удобно смотреть вручную. Команда ниже выводит по каждому отчёту домен, итоговые счётчики и список ошибок:

gunzip -c report.json.gz | jq -c '.policies[] | {
  domain: .policy."policy-domain", summary,
  failures: [."failure-details"[]? | {type: ."result-type",
    mx: ."receiving-mx-hostname", n: ."failed-session-count"}]}'

Дальше отчёты либо отправляют в сервис-анализатор вроде URIports или Mailhardener (его адрес просто ставится в rua), либо настраивают правило: письмо с ненулевым total-failure-session-count идёт в отдельную папку, остальное игнорируется.

Отсутствие отчётов тоже сигнал. Если за неделю не пришло ни одного письма от Google или Microsoft, скорее всего запись опубликована не на том имени или записей оказалось две.

Порядок внедрения защиты канала

TLS-RPT ставится первым, потому что он единственный ничего не ломает. Отчёты собираются, доставка не меняется. Неделя наблюдений показывает базовую картину: сколько соединений вообще идёт по TLS и от кого.

Затем MTA-STS в режиме testing: в отчётах появляются расхождения между политикой и реальностью, и до перехода на enforce видно, какой из MX-серверов не пройдёт проверку. Только после чистой недели идёт enforce, его собирают в генераторе MTA-STS. Обратный порядок приводит к тому, что письма перестают доходить, а данных, чтобы понять почему, нет.