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

Зачем это нужно

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

Куда публиковать

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

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

Отчёт приходит JSON-документом, обычно сжатым в gzip. Значимых полей немного:

• policy-type — по какому правилу проверялось соединение: sts для MTA-STS, tlsa для DANE или no-policy-found, если политики нет.
• successful-session-count и failed-session-count — сколько соединений прошло и сколько сорвалось за сутки. Именно их стоит выводить на график.
• failure-details — причина сбоя: certificate-expired, certificate-host-mismatch, starttls-not-supported, validation-failure. Здесь же IP-адрес сервера, на котором не получилось.

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

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

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

Из чего состоит запись

Тегов два. v=TLSRPTv1 — версия, стоит первой. rua= — адрес для отчётов: либо mailto:tls@example.com, либо https://example.com/tlsrpt для приёма POST-запросом. Несколько адресов перечисляются через запятую.

Отдельного подтверждения для внешнего адреса, в отличие от DMARC, не требуется: достаточно, чтобы домен принимал почту. Это упрощает передачу отчётов подрядчику или сервису-анализатору.

Зачем это, если письма и так доходят

TLS-RPT ничего не меняет в доставке, зато он единственный способ увидеть проблемы со стороны отправителей. Изнутри домена не видно ни того, что промежуточный узел вырезает STARTTLS, ни того, что сертификат на одном из резервных MX истёк месяц назад.

Практическая польза появляется в двух ситуациях. Первая это внедрение MTA-STS: в режиме testing отчёты показывают, что именно сломается при переходе на enforce, до того как это сломается. Вторая это смена почтового провайдера, когда часть отправителей ещё ходит по закешированным данным.

Что делать с отчётами дальше

Формат машинный, и разбирать его руками имеет смысл первые недели, пока нужно просто убедиться, что сбоев нет. Дальше отчёты либо заводят в анализатор, либо настраивают простое правило: письмо с ненулевым failed-session-count идёт в отдельную папку, остальное игнорируется.

Отсутствие отчётов тоже сигнал, и его легко пропустить. Если за неделю не пришло ни одного письма от крупных провайдеров, скорее всего запись опубликована не на том имени: _smtp._tls с двумя подчёркиваниями, а не smtp.tls и не в корне домена.

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

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

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