Мониторинг сайтов · 5 мин · обновлено 2026-11-02

MTA-STS и почта: как найти ошибку в политике MX и TLS

Письма задерживаются после смены почтового провайдера? Проверьте соответствие MX политике MTA-STS, TLS почтовых узлов и кэш отправителей.

Если после смены почтового провайдера письма перестали доходить только от части отправителей, проверьте MTA-STS. Эта политика сообщает отправляющему серверу, какие почтовые узлы допустимы и как защищать соединение с ними. При режиме enforce несовпадение MX или ошибка TLS могут остановить доставку.

Начните с причины отказа в почтовом журнале, затем сопоставьте MX домена получателя, опубликованную политику и сертификаты почтовых серверов. Исправление SPF наугад здесь не поможет: сначала нужно определить, на каком этапе остановилось письмо.

1. Подтвердите, что отказ связан с MTA-STS

Сохраните время сбоя с часовым поясом, домен получателя и техническую причину из уведомления о недоставке либо журнала отправляющего сервера. Для передачи специалисту удалите адреса людей, содержимое писем и другие персональные данные.

Ищите упоминания MTA-STS, несоответствия MX или проверки сертификата. Например, Exchange Online различает ошибки 5.4.8 для MX и 5.7.5 для сертификата; у другого отправителя формулировки могут отличаться. Поддержка MTA-STS у отправителей различается, поэтому успешное письмо из одного сервиса не опровергает сбой из другого. Описание ошибок Microsoft.

Если письмо вообще не появилось в очереди отправки, начните с проверки формы и SMTP. Если почтовый сервер уже принял письмо, а оно оказалось в спаме, нужна отдельная проверка фильтрации.

2. Проверьте DNS и адрес политики

Для обычной доставки через MX проверяется домен получателя, а не домен сайта-отправителя. В примерах ниже example.com — условный домен: замените его своим.

dig +short MX example.com
dig +short TXT _mta-sts.example.com
curl --max-time 20 -i https://mta-sts.example.com/.well-known/mta-sts.txt

В TXT ожидается запись вида v=STSv1; id=policy1;. Сам текст политики загружается по HTTPS: нужен ответ 200, корректный сертификат для mta-sts.example.com и текст политики, а не HTML-заглушка.

Не добавляйте к проверке curl параметры -L или -k: первый скроет редирект, второй отключит проверку сертификата. MTA-STS не допускает переход по HTTP-редиректу при загрузке политики. Правила получения политики — RFC 8461, раздел 3.3.

Если браузер показывает файл, а команда возвращает 301, проверьте правила перенаправления. При 200 с HTML проверьте маршрутизацию CMS, защитную страницу CDN и обработку пути /.well-known/. Один доступный URL ещё не подтверждает исправность почтового TLS.

3. Сопоставьте все MX с содержимым файла

В политике должны быть version: STSv1, режим mode, срок кэширования max_age в секундах и разрешённые имена mx. Для режимов testing и enforce сопоставьте каждую MX-запись DNS с отдельной строкой mx: или подходящим шаблоном.

В mx: указывают имя сервера, без приоритета DNS, протокола и пути.
Шаблон *.example.com подходит для mail.example.com, но не для example.com или mail.eu.example.com.
Проверьте резервные MX: ошибка на запасном узле может проявиться только при переключении.

Например, DNS уже ведёт на нового провайдера, а файл разрешает только прежний сервер. Это конкретное расхождение маршрута и политики; смена пароля ящика его не устранит. Формат и режимы описаны в инструкции Google по созданию MTA-STS.

4. Отдельно проверьте TLS почтовых серверов

Попросите администратора или провайдера проверить STARTTLS на каждом MX для входящей межсерверной доставки. Нужны действующий сертификат, доверенная цепочка и совпадение имени сертификата с именем MX.

Это другая проверка, чем HTTPS файла политики: сертификат сайта может быть исправен, а SMTP-сервер — отдавать просроченный или чужой сертификат. Результат подключения должен включать имя проверенного узла и конкретную ошибку проверки, а не только отметку «порт открыт».

В режиме testing само нарушение MTA-STS не должно блокировать доставку; в enforce оно препятствует отправке на неподходящий узел. Но тестовый режим не исправляет сетевые сбои и другие причины отказа почты. Требования к серверу и режимам.

5. Учтите кэш перед исправлением и переездом

При обновлении сначала опубликуйте исправный файл политики, затем измените id в TXT. Один новый файл без смены идентификатора может оставить отправителей со старой версией до истечения её срока. Обновление политики у Microsoft.

Удаление TXT не является мгновенным отключением: отправитель может продолжить применять действующую кэшированную политику. Недоступность HTTPS-файла тоже не всегда объясняет отказ — важно, есть ли у отправителя сохранённая политика. Кэш и применение политики — RFC 8461.

При плановом переезде заранее согласуйте период, когда политика разрешает старые и новые MX. Не выключайте старый маршрут, пока не учтены срок прежней политики и DNS-кэш; простое уменьшение max_age сейчас не переписывает уже сохранённые копии.

Как проверить результат

Сопоставьте повторную попытку доставки с журналом: прежняя ошибка исчезла, письмо принято нужным сервером и дошло в контролируемый ящик. Не очищайте очередь вслепую и не запускайте массовую повторную отправку.

Если настроен TLS-RPT, отчёты помогают увидеть ошибки TLS и политики со стороны участвующих отправителей. Это отдельный механизм отчётности, не мгновенный тест доставки и не DMARC-отчёт. Отсутствие отчёта само по себе не доказывает исправность. SMTP TLS Reporting — RFC 8460.

Если расхождение найдено, но доступ к DNS, файлу политики и почтовым узлам разделён между подрядчиками, можно отправить заявку на профессиональную поддержку через Web-Puls. Укажите публичный домен, время сбоя, недавние изменения и обезличенную причину отказа — это поможет определить объём диагностики без передачи паролей и писем клиентов.