Demo
Demo
База знаний PMTA›Блок <domain>›Директива§ 3.3.10.69

bounce-upon-no-mx

<domain>Хаб задаёт сам

Отбивать ли сразу, когда у получателя нет записи MX
в конфигурации это строкаbounce-upon-no-mx falseвнутри блока <domain>
Что делать с доменом, у которого нет почтового сервера в DNS

Домен получателя есть, а записи MX у него нет. Формально почта в такой домен всё равно возможна: почтовые правила разрешают в этом случае обратиться к адресу самого домена — записи A или AAAA. Эта строка решает, стоит ли пробовать.

Значений четыре, а не два. false — вендорское умолчание, письма остаются в очереди и уезжают по общему сроку. true — вся очередь этого получателя отбивается немедленно. Интервал — самый полезный вид: отбиваются только письма, пролежавшие в очереди дольше указанного времени, а до тех пор узел пробует достучаться по адресу домена. never — не отбивать по этой причине никогда.

Строка работает только там, где узел вообще спрашивает MX. Если получателю задан явный список серверов через smtp-hosts, запроса MX не происходит, и решать здесь нечего.

Главная ловушка. true в блоке со звёздочкой — быстрый способ потерять живую почту. Мелкие домены, корпоративные почтовые узлы, наспех поднятые адреса нередко живут на одной записи A без всякого MX. Для крупных почтовиков true безопасно: у gmail.com MX есть всегда, и его отсутствие означает сбой, а не такую конфигурацию.
Что делает Хаб. В шаблоне политик приёмников yes стоит у четырнадцати известных почтовиков, а в общем <domain *> — 30m, как в примере руководства: домен без записи MX полчаса получает попытки по адресной записи и только потом отказ. До 15.09.2026 в общем блоке тоже стояло yes, и такой домен получал отказ сразу.
Рекомендуемые значения

Известным почтовикам — да. У крупного провайдера MX есть всегда; его пропажа означает сбой DNS, а не домен без почтового сервера. Держать письма в очереди трое суток ради такого случая незачем.

Всем остальным — интервал. Полчаса дают узлу время попробовать адрес домена напрямую и при этом не тянут заведомо мёртвую почту весь срок. Это же значение показывает пример руководства для блока со звёздочкой.

true на звёздочке — только если вы точно знаете свою базу. Для рассылки по собранным адресам это гарантированная потеря части живых получателей.

Разделение «известным почтовикам да, остальным интервал» — наше. Из руководства здесь все четыре допустимых значения, умолчание false, пример с 30m и оговорка про smtp-hosts.
Пример в конфигурации
# у крупного почтовика MX есть всегда — его отсутствие это сбой
<domain gmail.com>
    bounce-upon-no-mx yes</domain>

# всем остальным даём полчаса на попытку по адресу домена
<domain *>
    bounce-upon-no-mx 30m</domain>
Второй блок не отменяет первый: значение сливается от общего к частному, и для gmail.com действует именно yes.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается2 ошибки▶

Ставят true в блоке со звёздочкой

§ 3.3.10.69

Чем чреватоДомены, живущие на одной записи A без MX, теряются целиком. Почтовые правила такую доставку разрешают, а узел с этой настройкой даже не пробует.
Как заметитьВ отказах много мелких доменов с пометкой об отсутствии MX, хотя почта туда раньше уходила.
Как правильноВ блоке со звёздочкой ставить интервал — например 30m, а true оставить блокам известных почтовиков.

Задают её получателю с явным списком серверов

§ 3.3.10.69

Чем чреватоПри заданном smtp-hosts запроса MX не происходит, и строка не делает ничего. Настройку считают действующей и ищут причину отказов не там.
Как заметитьСтрока задана, а письма ведут себя так, будто её нет.
Как правильноУбрать её из блоков с явным списком серверов, чтобы не вводить в заблуждение при чтении конфигурации.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
bounce-upon-no-mx ( <boolean> | <time-interval> | never )
Значения
true, false, интервал времени вроде 30m либо слово never
Умолчание
false § 3.3.10.69
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<domain>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Значение сливается по блокам <domain> от общего к частному: побеждает наиболее подходящий блок, а не последний по файлу. Строка не действует там, где задан smtp-hosts: явный список серверов отменяет запрос MX, а с ним и повод для этого решения. Подхватывается по pmta reload; на уже лежащие письма новое значение действует со следующей попытки.
⇄

Связанные директивы

1 связь

Конфликтует

smtp-hosts<domain>Явный список серверов отменяет запрос MX — а без запроса эта строка не срабатывает вовсе. § 3.3.10.69

Сюда ссылаются

bounce-after<domain>Условие, которое отбивает письмо досрочно, не дожидаясь срока. § 3.3.10.69

Как проверить на узле
Значение печатает команда настроек очереди; наличие самой записи проверяется обычным запросом к DNS:
pmta show settings example.com/vmta1 | grep -i bounce-upon-no-mx
dig +short MX example.com
Пустой ответ второй команды при yes означает, что вся очередь этого получателя отобьётся на ближайшей попытке. Хаб отсутствие MX у получателей не отслеживает.
◇

Что ещё почитать

3 статьи

◇Четыре типа значений, на которых написан весь конфигЛогическое, образец домена, регулярное выражение и промежуток времени — определены один раз в § 3.2 и дальше используются всеми директивами.◇Два обработчика входящих отчётов и что с ними делатьОтказы письмом и жалобы разбираются двумя одинаково устроенными блоками; у каждого свой список адресов и своя пара решений о судьбе письма.◇Как складывается политика для приёмникаНастройки собираются от самого общего образца к самому точному; порядок блоков в файле не значит ничего.

В Хабе
Значение
Хаб подбирает сам — темп, стадия прогрева, метрики
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Классификация отказов · Настроить темп под провайдера
Соседние настройки блока <domain>:smtp-pattern-listsmtp-553-means-invalid-mailboxbounce-category-patternsbounce-upon-5xx-greetingbounce-upon-transfer-failureВсе 135 директив блока →