Генератор MTA-STS

Что такое MTA-STS и от чего он защищает

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) защищает входящую почту вашего домена от перехвата по дороге. STARTTLS устроен так, что шифрование запрашивается уже внутри открытого соединения. Промежуточный узел может вырезать из ответа сервера строку с предложением STARTTLS, и отправитель, не увидев поддержки шифрования, отправит письмо открытым текстом. Обе стороны при этом уверены, что всё в порядке. Это downgrade-атака, и изнутри её не заметить.

MTA-STS убирает такой сценарий: политика лежит по https и говорит отправителю, что домен принимает почту только по TLS с действительным сертификатом на перечисленных серверах. Сама политика приходит по другому каналу, в обход SMTP-сессии. Не сошлось имя в сертификате или сервер не предложил TLS, в режиме enforce письмо не уходит вовсе. RFC при этом требует от серверов с MTA-STS поддержки TLS 1.2 или 1.3.

Что нужно сделать помимо записи

1. Поднимите поддомен mta-sts.ваш-домен и выпустите для него сертификат. Подойдёт обычный от Let's Encrypt.
2. Выложите файл политики по пути /.well-known/mta-sts.txt с типом text/plain.
3. Опубликуйте TXT-запись на имя _mta-sts.
4. Настройте TLS-RPT, чтобы видеть отчёты о неудачных попытках соединения. В режиме testing вы узнаете о сбоях только из них.

Файл политики и TXT-запись

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mx.example.net
max_age: 86400

• version: пока только STSv1.
• mode: testing, enforce или none, о них ниже.
• mx: по строке на каждый почтовый сервер. Звёздочка заменяет только крайнюю левую часть имени: *.mx.example.net подходит для a.mx.example.net, но не для b.a.mx.example.net.
• max_age: сколько секунд отправитель хранит политику, не больше 31557600 (год). RFC советует держать недели и больше.

Рядом нужны две DNS-записи: адрес для поддомена политики и сама TXT-запись. В ней два тега: v=STSv1 и id. В id пишут строку до 32 латинских букв и цифр и меняют её при каждой правке файла.

mta-sts.example.com.  IN A    203.0.113.10
_mta-sts.example.com. IN TXT  "v=STSv1; id=20260917T120000"

Список MX для Google Workspace и Microsoft 365

Имена в политике сверяются с MX-записями домена и с сертификатом принимающего сервера. Если в файле перечислены не все MX или указаны устаревшие имена, в режиме enforce часть отправителей не доставит письмо. Где взять правильный список? Удобнее всего подсмотреть у самих провайдеров. 16 октября 2026 года в политике google.com стояло:

mx: smtp.google.com
mx: aspmx.l.google.com
mx: *.aspmx.l.google.com

У microsoft.com в тот же день была одна строка, она же подходит для доменов на Microsoft 365, чьи MX смотрят на mail.protection.outlook.com:

mx: *.mail.protection.outlook.com

Перед публикацией сверьте список с тем, что отдаёт проверка MX-записей для вашего домена. Переезжая к другому провайдеру, сначала впишите в политику его серверы, а MX-записи меняйте потом. Кстати, Google держит в своей политике max_age: 86400, то есть сутки, хотя режим у него enforce.

Как раздать файл политики

Файл должен открываться ровно по адресу https://mta-sts.example.com/.well-known/mta-sts.txt с кодом 200. Отправитель принимает только прямой ответ, без перенаправлений, и только сертификат от доверенного центра сертификации. Если свой веб-сервер есть, хватит такого блока nginx:

server {
    listen 443 ssl;
    server_name mta-sts.example.com;
    ssl_certificate     /etc/letsencrypt/live/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        root /var/www/mta-sts;
        default_type text/plain;
    }
    location / {
        return 404;
    }
}

Если отдельного сервера нет, файл можно положить на статический хостинг со своим доменом, например GitHub Pages или Cloudflare Pages: достаточно, чтобы поддомен mta-sts отдавал файл по https с действительным сертификатом. Проверить результат:

dig +short TXT _mta-sts.example.com
curl -sI https://mta-sts.example.com/.well-known/mta-sts.txt

В ответе curl должны быть код 200 и content-type: text/plain.

Три режима и порядок внедрения

• testing: отправитель проверяет политику, но при несовпадении всё равно доставляет письмо и присылает отчёт. С него начинают всегда.
• enforce: при несовпадении доставка отменяется.
• none: способ корректно выключить MTA-STS. Просто удалить файл нельзя, отправители будут помнить прежнюю политику до истечения max_age.

Разумный порядок: сначала TLS-RPT, затем testing с небольшим max_age, сутки-двое. Неделю смотрите отчёты: в них видно, все ли ваши MX проходят проверку и не забыт ли какой-нибудь резервный сервер. Только когда неделя проходит без сбоев, переключайте на enforce и, если конфигурация устоялась, поднимайте max_age. Большое значение защищает от подмены политики, но и ошибку отправители будут помнить столько же.

Чтобы отказаться от MTA-STS, RFC 8461 предлагает три шага: опубликовать политику с mode: none и маленьким max_age, сменить id в TXT-записи и только после истечения всех прежних max_age удалить запись и файл.

Где это ломается

• Файл отдаётся не как text/plain. Сервер ставит text/html или отдаёт страницу-обёртку, и политика считается нечитаемой.
• Сертификат на mta-sts.example.com просрочен. Поддомен с политикой живёт отдельно от основного сайта, и про его автопродление забывают. Политика становится недоступна, а в режиме enforce отправители продолжают требовать TLS по прежней, закешированной.
• Значение id не изменили. Отправители перечитывают файл, когда меняется id или истекает max_age. Правка политики без нового идентификатора может не действовать неделями.
• Редирект на www или на любой другой адрес. По RFC 8461 отправитель не следует ни одному ответу 3xx, и политика для него недоступна.
• В mx вписан сам домен. Строка mx: example.com вместо имён почтовых серверов. Отправитель сверяет с политикой хост из MX-записи, например aspmx.l.google.com, совпадения нет, и в режиме enforce письмо не уходит.
• Забытый резервный MX. Основной сервер в списке и с хорошим сертификатом, а запасной нет. Ошибки появятся, когда основной станет недоступен.

Проверка MTA-STS при отправке: Postfix и mta-sts-daemon

Всё выше защищает почту, которая приходит к вам. Если у вас свой почтовый сервер, он тоже может соблюдать чужие политики при отправке. Postfix сам MTA-STS не проверяет, для этого есть пакет postfix-mta-sts-resolver. Он ставится командой python3 -m pip install postfix-mta-sts-resolver, запускает демон mta-sts-daemon на порту 8461, и Postfix спрашивает у него политику для каждого домена получателя:

# /etc/mta-sts-daemon.yml
host: 127.0.0.1
port: 8461
cache:
  type: sqlite
  options:
    filename: "/var/lib/mta-sts/cache.db"
default_zone:
  strict_testing: false
  timeout: 4

# /etc/postfix/main.cf
smtp_tls_policy_maps = socketmap:inet:127.0.0.1:8461:postfix

После перезапуска демона и перезагрузки Postfix письма на домены с mode: enforce уходят только по TLS с проверкой сертификата.

MTA-STS и DANE

Обе технологии решают одну задачу, но по-разному. DANE публикует данные сертификата в DNS и требует работающего DNSSEC. MTA-STS обходится обычным DNS и https-сертификатом, поэтому внедряется проще. Слабое место у него одно: злоумышленник, который перехватывает DNS, может скрыть политику при самом первом обращении, пока её нет в кэше отправителя. Поэтому RFC и советует длинный max_age.

Вместе они уживаются. RFC 8461 прямо запрещает отправителю считать письмо защищённым по MTA-STS, если проверка DANE для того же сервера провалилась, так что при наличии обеих DANE главнее. Подробнее о нём в статье о DANE для почты.