MTA-STS и TLSRPT: настраиваем защищённый SMTP и отчётность в Postfix

Инструкции
21 ноя, 2025
Время на чтение: ~18 мин
Автор: AI (GPT 5)

Искусственный интеллект Fastfox

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

Если коротко, MTA-STS отвечает на вопрос «кому и как отправлять нам почту по TLS», а TLSRPT — «как нам узнавать, у кого и почему не получилось доставить нам письма по TLS». В связке эти два стандарта закрывают критичные риски по даунгрейду STARTTLS, прозрачности отказов шифрования и помогают улучшить deliverability в крупных почтовых провайдерах. Ниже — практическое руководство для админов Postfix: от DNS и HTTPS-политики до включения клиентской части через resolver и ежедневного анализа отчётов.

Зачем вам MTA-STS и TLSRPT

Исторически SMTP использует оппортунистический TLS: отправитель пробует STARTTLS, но если на пути встречается злоумышленник, возможен даунгрейд до нешифрованного соединения или подмена MX. Это влияет и на безопасность, и на репутацию домена, а также на доставляемость — крупные провайдеры все активнее учитывают устойчивость к MITM и корректность TLS при оценке риска.

MTA-STS (RFC 8461) позволяет владельцу домена указать список MX и потребовать у отправителей обязательный TLS с верификацией имени в сертификате. Политика публикуется в DNS и по HTTPS. TLSRPT (RFC 8460) дополняет картину: домен указывает почтовые адреса, на которые отправители будут присылать агрегированные отчёты о проблемах с TLS при доставке. Вы видите реальную статистику попыток доставки и причины отказов.

Важно: MTA-STS не заменяет DANE/TLSA с DNSSEC. Если у вас есть DNSSEC и вы готовы вести TLSA-записи, DANE сильнее (криптографически привязывает ключ к домену). Но на практике MTA-STS проще внедрить и уже хорошо поддерживается отправителями.

Как работает MTA-STS на практике

Публикация MTA-STS состоит из двух частей:

DNS TXT-запись _mta-sts.<domain> с версией и идентификатором политики (для инвалидации кеша у отправителей).
Файл политики по HTTPS на поддомене mta-sts.<domain> по пути /.well-known/mta-sts.txt. Сертификат этого HTTPS-хоста должен быть валиден и выдан доверенным УЦ.

Отправитель (MTA) при виде новой или обновлённой политики кеширует её на срок max_age из файла и затем при доставке сверяет MX и требует TLS с проверкой имени в сертификате. Если MX или TLS не соответствуют — письмо в режиме enforce не доставляется, в режиме testing — доставляется, но отправитель пришлёт вам отчёт TLSRPT о несоответствии.

Структура записей и файла политики

В DNS размещается короткая запись:

_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=2025-01-01"

id — любое строковое значение. Меняете политику — меняете id, чтобы отправители сбросили кеш.

Файл политики по HTTPS содержит:

version: STSv1
mode: testing
mx: mx1.example.com
mx: mx2.example.com
mx: *.example.net
max_age: 604800

Пояснения:

mode: none (практически не используется), testing (включите на старте), enforce (обязательное применение и возможные недоставки при несоответствии).
mx: список MX-хостов или масок, допустимых для доставки. Не забывайте, что отправитель будет проверять совпадение имен в TLS-сертификате с целевым MX.
max_age: время кеширования политики (в секундах). На запуске разумное значение — от одного дня до недели.

Файл должен быть доступен по HTTPS без редиректов, с корректной цепочкой до доверенного УЦ. Сертификат должен покрывать имя mta-sts.<domain>. Если сертификата ещё нет, возьмите его из проверенного УЦ — для этого подойдёт покупка через SSL-сертификаты.

Публикация MTA-STS политики по HTTPS на поддомене mta-sts

Готовим домен: DNS и HTTPS под MTA-STS

Шаги внедрения всегда начинаем с низкого риска: сначала DNS и HTTPS, затем режим testing, мониторинг отчётов TLSRPT, и только потом — enforce. Если вы поднимаете отдельный сайт mta-sts.<domain>, удобно отдавать файл политики на своём почтовом хосте или на отдельном сервере — например, в изолированном окружении на облачном VDS.

1) Добавляем DNS-запись политики

В зоне домена создайте TXT для _mta-sts.<domain>. На первом этапе задайте небольшой TTL (например, 3600), чтобы удобно было обновлять id.

_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=2025-01-01"

Если нужна систематизация почтовых DNS‑записей (SPF, DKIM, DMARC), загляните в разбор базовых шаблонов: DNS-записи для аутентификации почты.

2) Публикуем HTTPS-политику

На хосте mta-sts.<domain> поднимите любой веб-сервер. Ниже минимальные примеры конфигураций, где файл лежит как обычный статический ресурс.

Пример для Nginx:

server {
    listen 443 ssl http2;
    server_name mta-sts.example.com;

    ssl_certificate /etc/ssl/certs/mta-sts-example-com.crt;
    ssl_certificate_key /etc/ssl/private/mta-sts-example-com.key;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        root /var/www/mta-sts;
        add_header Cache-Control "max-age=300";
    }
}

Пример для Apache:

<VirtualHost *:443>
    ServerName mta-sts.example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/mta-sts-example-com.crt
    SSLCertificateKeyFile /etc/ssl/private/mta-sts-example-com.key

    DocumentRoot /var/www/mta-sts
    <Directory /var/www/mta-sts>
        Require all granted
        Options -Indexes
    </Directory>
</VirtualHost>

Проверьте доступность файла локально и снаружи. Примеры команд проверки:

curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt
openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -brief

Postfix как принимающий сервер: что нужно для корректного TLS

Чтобы у внешних отправителей в режиме enforce всё проходило, ваш MX обязан поддерживать STARTTLS и отдавать валидный сертификат, имя в котором совпадает с именем MX (или его альтернативным именем в SAN). Минимальный набор для main.cf:

smtpd_tls_cert_file = /etc/ssl/certs/mx-example-com.crt
smtpd_tls_key_file = /etc/ssl/private/mx-example-com.key
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_ciphers = high
smtpd_tls_mandatory_protocols = TLSv1.2, TLSv1.3
smtpd_tls_eecdh_grade = strong
smtpd_tls_received_header = yes

Если у вас несколько MX, удостоверьтесь, что на всех хостах сертификаты и TLS-настройки согласованы, а имена в сертификатах соответствуют реальным MX, перечисленным в политике MTA-STS. Для выпуска и продления удобнее использовать централизованный пайплайн и надёжные SSL-сертификаты.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Postfix как отправитель: поддержка MTA-STS клиентом через resolver

Базовый Postfix не реализует MTA-STS-клиент напрямую. На практике используется внешняя служба postfix-mta-sts-resolver, которая динамически подсказывает Postfix политику TLS для домена назначения через smtp_tls_policy_maps. Для лучшей криптографической устойчивости её часто комбинируют с DANE, если у вас есть валидирующий DNSSEC-резолвер.

Установка postfix-mta-sts-resolver

На Debian/Ubuntu пакет обычно доступен из репозитория:

apt update
apt install postfix-mta-sts-resolver

На RHEL/CentOS/AlmaLinux можно установить из pip (желательно в изолированное окружение) и запустить как systemd-сервис из поставляемых unit-файлов проекта:

pip install postfix-mta-sts-resolver

Проверьте конфигурацию, как правило лежит в /etc/postfix/mta-sts-resolver.yml. Базовые параметры: адрес слушателя socketmap, таймауты, кеш и путь к хранилищу политик. Пример:

resolver:
  listen: 127.0.0.1:8460
  cache_ttl: 3600
  max_workers: 4
  log_level: info

В Postfix пропишем политику TLS и подключим socketmap:

smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
smtp_tls_loglevel = 1
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8460

Пояснения:

smtp_tls_security_level = dane — если у вас есть валидирующий DNSSEC-резолвер, Postfix сначала попробует DANE, а если TLSA для домена нет — задействует MTA-STS через resolver. Если DNSSEC нет, используйте may, но тогда у вас не будет преимуществ DANE.
smtp_tls_policy_maps — подключение к resolver, который вернёт для домена назначения требование enforce и соответствия имени в сертификате MX из политики.

После изменений перезапустите службы:

systemctl restart postfix
systemctl enable --now postfix-mta-sts-resolver

Проверьте логи и убедитесь, что resolver отвечает на запросы, а Postfix учитывает политику при доставке.

Включаем TLSRPT: получаем отчёты об ошибках TLS

Чтобы получать агрегированные отчёты, добавьте в DNS TXT-запись _smtp._tls.<domain>. В ней указываются версия и адрес(а) для отчётов (как правило, mailto:). Пример:

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

Рекомендуется выделить отдельный ящик или алиас (например, tlsrpt@) и фильтровать вложения. Отчёты обычно приходят раз в день от крупных отправителей с JSON-вложением. Размеры могут быть значительными, если трафик большой.

Как выглядят отчёты и что в них

Внутри — перечень доменов назначения, период, агрегированные события по MX, типам ошибок и числу попыток. Типичные причины:

starttls-not-supported — ваш MX не объявил STARTTLS;
certificate-expired — истёк срок действия сертификата на MX;
certificate-name-mismatch — имя MX не совпадает с именем в сертификате;
sts-policy-invalid — файл политики невалиден или недоступен по HTTPS;
mx-mismatch — MX не входит в список mx: политики.

Примерные команды для первичного разбора JSON:

# распакуйте вложение и прогоните через jq
jq '.reports[] | {policy: .policy_domain, result: .summary.result_type, count: .summary.total_failure_count}' report.json

# агрегируйте по типам
jq -r '.reports[].summary.result_type' report.json | sort | uniq -c | sort -nr

Если отчёты стабильно показывают certificate-name-mismatch — проверьте, что в политике MTA-STS вы перечисляете именно те имена MX, которые фигурируют в сертификатах (или наоборот, SAN ваших сертификатов покрывает все имена из политики). Для starttls-not-supported проверьте 25-й порт и объявление STARTTLS в баннере. Для sts-policy-invalid проверьте сертификат и доступность файла без редиректов.

Пример отчётов TLSRPT и первичный разбор JSON через jq

План внедрения без рисков

Рекомендуемая последовательность действий:

Подготовьте сертификаты и включите корректный STARTTLS на всех MX вашего домена.
Опубликуйте HTTPS-политику с mode: testing и небольшой max_age (от суток до недели). Создайте _mta-sts с новым id.
Включите TLSRPT через _smtp._tls и начните собирать отчёты минимум 7–14 дней.
Настройте Postfix как отправителя с postfix-mta-sts-resolver, чтобы соблюдать чужие политики при исходящей почте.
Проанализируйте отчёты: устраните причины отказов (сертификаты, список MX, доступность HTTPS-политики).
Увеличьте max_age, переведите политику в mode: enforce, обновите id в DNS.
Оставьте TLSRPT включённым постоянно — это ваш ранний индикатор деградации TLS.

Частые ошибки и как их диагностировать

Полезные проверки руками и глазами:

Проверка STARTTLS и имени: openssl s_client -starttls smtp -connect mx1.example.com:25 -servername mx1.example.com -verify_return_error -brief.
Проверка файла политики: curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt.
Проверка MX на соответствие политике: выпишите текущие MX из DNS и сравните со строками mx: в политике. Если используете маску *.example.net, удостоверьтесь, что реальный MX совпадает по шаблону и его сертификат содержит точное имя.
Кеширование: помните, что отправители кешируют политику на max_age. Меняете список MX — меняйте id в _mta-sts, иначе эффект наступит нескоро.
Редиректы: не используйте редиректы для /.well-known/mta-sts.txt, многие реализации их не следуют.

Совместимость с DANE и выбор стратегии

Идеальная картина для исходящей почты с Postfix — включить DANE при наличии валидирующего DNSSEC-резолвера и добавить MTA-STS через resolver как «вторую линию». Тогда для доменов с TLSA вы получите криптографически сильную привязку, а для остальных — политику по HTTPS. Если DNSSEC недоступен, используйте MTA-STS, но отслеживайте отчёты TLSRPT и своевременно реагируйте на ошибки.

Регистрация доменов от 99 руб.

Каждый проект заслуживает идеального доменного имени, выберите один из сотни, чтобы начать работу!

Зарегистрировать домен

Многодоменные сценарии и балансировка

Для каждого домена требуется свой поддомен mta-sts.<domain> и свой файл политики. Если у вас общий пул MX для нескольких доменов, это удобно: одна и та же группа имен MX может фигурировать в политике разных доменов, главное — чтобы сертификаты на MX покрывали эти имена. При балансировке по нескольким MX не забывайте про идентичность TLS-настроек и сроки сертификатов на всех узлах. Если регистрируете новые зоны под почтовую инфраструктуру, держите под рукой удобный сервис для регистрации доменов.

Операционные практики

Автоматизируйте выпуск и продление сертификатов на MX. Любая просадка — и отчёты TLSRPT завалят вас certificate-expired и certificate-revoked. Если используете DNS‑01 и wildcard, пригодится наш разбор: автоматизация wildcard‑SSL по DNS‑01.
Ведите версионирование файла политики и автоматический bump поля id в _mta-sts при каждом релизе.
Собирайте и храните отчёты TLSRPT централизованно. Минимум — фильтр в MTA и парсинг вложений скриптом с jq. Лучше — отдельная база и дешборд с трендами по типам ошибок.
Алёрты: если в отчётах растёт доля starttls-not-supported или sts-policy-invalid, это сигнал, что MX или хост с политикой недоступен либо сертификат сломан.

Контроль доставляемости: что реально меняется

После включения MTA-STS ваша почта для отправителей, которые уважают стандарт, становится предсказуемее: они знают допустимые MX и что вы требуете TLS. Для крупных провайдеров это фактор доверия. TLSRPT — ваш объективный мониторинг: вместо «иногда кто-то жалуется на недоставку» вы получаете машинно читаемые агрегаты с причинами. Хорошая операционная гигиена (сертификаты в срок, стабильный HTTPS-паблишер, аккуратные MX) прямо коррелирует с лучшей deliverability.

Чек-лист перед включением enforce

Все MX доступны и отдают STARTTLS.
Сертификаты валидны, SAN покрывают имена MX, алгоритмы и протоколы не устаревшие.
Файл политики отдаётся по HTTPS без редиректов и с корректной цепочкой УЦ.
В TLSRPT за последние 7–14 дней нет массовых ошибок по вашим MX.
В _мta-sts выставлен новый id, max_age увеличен до недель/месяцев.

FAQ для Postfix-админа

Нужно ли менять что-то в Dovecot/IMAP? Нет, MTA-STS касается только SMTP-трафика для входящей доставки и клиентского поведения исходящих MTA. IMAP/POP не задействованы.

Можно ли использовать wildcard в mx:? Да, но аккуратно. Маска должна соответствовать реальным именам MX, и сертификаты этих MX должны содержать точные имена, а не только маску.

Если мой MX — это внешний сервис (relay), а я владею доменом? Согласуйте список MX и сертификаты с провайдером. Политика MTA-STS должна отражать реальные конечные MX, на которые придёт внешняя доставка.

Где хранить отчёты TLSRPT? Минимум — отдельный ящик и регулярная очистка. Лучше — складывать вложения в объектное хранилище и строить регулярный парсинг.

Нужно ли добавлять несколько адресов в rua? Можно перечислить несколько mailto:, разделив запятой. Это удобно для разделения операционных и аналитических потоков.

Итоги

MTA-STS и TLSRPT — быстрые в запуске и крайне полезные кирпичики для безопасности и доставляемости SMTP. На стороне домена — публикуем политику и принимаем отчёты; на стороне Postfix как отправителя — добавляем resolver, чтобы уважать чужие политики. После недели-другой в режиме testing и безошибочных отчётов можно смело идти в enforce. Дальше это лишь операционная дисциплина: сертификаты в срок, аккуратные изменения MX с bump id, мониторинг TLSRPT — и ваша почта станет предсказуемее, а репутация домена — устойчивее.

Поделиться статьей