Postfix: deferred и bounce из‑за DNS и TLS — разбор очереди и быстрый план ремонта

О чём говорят deferred и bounce в Postfix

Когда исходящее письмо не удалось доставить с первой попытки, Postfix обычно делает не «фатальную ошибку», а откладывает доставку: в очереди появляется status=deferred. Это нормальная логика MTA: повторные попытки будут выполняться по расписанию (backoff), пока не истечёт срок жизни сообщения.

bounce — другое. Это уже сформированный ответ о недоставке (DSN), который Postfix отправляет обратно отправителю, если считает ошибку окончательной (например, «домена не существует», «550 user unknown») или если истекло время удержания в очереди.

Практически: deferred — шанс «починить и дождаться», bounce — письмо уже не попадёт адресату, нужно разбираться и отправлять повторно.

Быстрый чек-лист: что проверить в первую очередь

Если вы видите рост очереди и жалобы «письма не уходят», начните с пунктов ниже — они закрывают большинство кейсов вокруг DNS/TLS:

• Состояние очереди: сколько писем, какие формулировки ошибок, какие домены «тормозят».
• DNS-резолвинг на сервере: корректный /etc/resolv.conf или настройка systemd-resolved, нет ли таймаутов.
• FQDN/HELO: что Postfix говорит в приветствии и как задан myhostname.
• Наличие A/AAAA для myhostname и обратной зоны rDNS PTR для исходящего IP.
• TLS: ошибки вида tls negotiation failed, проверка сертификата, цепочка CA, совместимость протоколов.

Две частые «минные поля»: недавно поменяли DNS (TTL/пропагация), либо ужесточили исходящую TLS-политику без исключений для отдельных доменов.

Если очередь регулярно раздувается, иногда проблема не в Postfix как таковом, а в ресурсах/сети. В таких случаях удобнее держать почтовый узел на отдельном VDS, чтобы DNS-кеш, сеть и лимиты не конкурировали с веб-приложением и бэкендами.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Как посмотреть postfix queue: mailq, postqueue и чтение причин

Очередь можно смотреть несколькими командами — смысл один: оценить объём и увидеть первичные тексты ошибок. Начните с общего состояния:

mailq
postqueue -p

В выводе обычно важны: queue ID (например, 3F2A012345), домен получателя, возраст письма, а также текст причины у последней попытки.

Чтобы быстрее вытащить типовые причины, фильтруйте вывод очереди:

postqueue -p | grep -i deferred
postqueue -p | grep -i tls
postqueue -p | grep -i "Host or domain name not found"

Повторная попытка доставки: postqueue -f

Если вы уже исправили DNS/TLS и хотите не ждать плановой попытки, форсируйте обработку очереди:

postqueue -f

Если причина не устранена, postqueue -f лишь увеличит нагрузку (DNS/CPU/сеть) и снова заполнит deferred. Поэтому сначала фикс, потом форсирование.

Точечная работа: postsuper

Когда нужно убрать явно ненужные письма (например, «мусор» от тестов или заведомо битые задачи), используйте postsuper. Удаление необратимо:

postsuper -d ALL deferred

Для выборочного удаления по ID:

postsuper -d 3F2A012345

Где искать первопричину: логи Postfix и «связка» с ID письма

Очередь показывает последствия, а причины почти всегда в логах. На большинстве систем Postfix пишет в syslog:

• /var/log/maillog (часто на RHEL-подобных)
• /var/log/mail.log (часто на Debian/Ubuntu)
• либо в journald

Ищите по queue ID из mailq:

grep -F "3F2A012345" /var/log/mail.log
grep -F "3F2A012345" /var/log/maillog

Если логи в journal:

journalctl -u postfix --since "2 hours ago"
journalctl -u postfix | grep -F "3F2A012345"

Для исходящей доставки ключевое — строки postfix/smtp. Смотрите текст после said:, а также ошибки вида connect to ..., status=deferred, упоминания DNS и TLS.

DNS-причины deferred/bounce: типовые ошибки и ремонт

1) Host or domain name not found, Name service error, таймауты DNS

Классика: недоступен резолвер, неправильный /etc/resolv.conf, DNS отвечает медленно или периодически «зависает». Иногда проявляется после смены сети, VPN, внедрения контейнерной инфраструктуры или политики DNSSEC.

Минимальный тест резолвинга (без установки дополнительных утилит):

getent ahosts gmail.com

Проверка MX обычно удобнее через dig/host (если установлены). Если нет — ориентируйтесь на логи Postfix и факт, что A/AAAA для MX-хостов резолвится стабильно.

Логика проверки всегда одна:

• разрешаются ли A/AAAA целевых доменов без таймаутов;
• разрешаются ли MX и затем A/AAAA для хостов из MX;
• нет ли периодических «провалов» (то работает, то нет).

Что обычно помогает на практике:

• перевести сервер на стабильные рекурсивные DNS (локальный кеширующий резолвер или корректно настроенный systemd-resolved);
• проверить MTU/PMTUD на сервере (крупные ответы, DNSSEC, фрагментация);
• убрать неожиданный DNS из VPN/контейнерных сетей, который подменяет резолвинг.

2) Ошибки вокруг rDNS PTR и HELO/EHLO

Многие принимающие серверы оценивают отправителя по цепочке: исходящий IP → PTR (rDNS) → прямое разрешение имени обратно в IP (FCrDNS) → соответствие тому, что вы говорите в HELO/EHLO. Несовпадение не всегда даёт жёсткий отказ, но часто приводит к deferred из-за антиспам-политик и «серых» проверок.

Проверьте, что:

• myhostname — реальный FQDN (например, mail.example.com);
• на этот FQDN есть A (и при использовании IPv6 — AAAA) запись;
• на исходящий IP настроен rDNS PTR на тот же FQDN;
• этот PTR резолвится обратно в тот же IP (FCrDNS).

Минимально полезный снимок настроек Postfix:

postconf -n | egrep '^(myhostname|mydomain|myorigin|smtp_helo_name)\s*='

Частая ошибка: myhostname оставлен как localhost или «неполное» имя. Тогда удалённая сторона может ругаться на HELO и отдавать временный отказ.

Если вы параллельно наводите порядок в доменной зоне, пригодится материал: перенос домена без потери DNS-записей.

3) Некорректные MX/A/AAAA у домена отправителя

Даже если вы отправляете письма «наружу», часть получателей проверяет, что домен отправителя (в From или envelope-from) имеет валидные DNS-записи, и что ваш MTA не выглядит «случайным». Проблемы с зоной иногда проявляются как deferred у отдельных крупных провайдеров.

Базовый минимум для домена:

• A/AAAA для mail.example.com;
• MX домена указывает на mail.example.com;
• разумные TTL (особенно при миграциях);
• SPF/DKIM/DMARC — отдельная тема, но часто всплывает рядом.

Если домены и зона ещё «в движении», иногда проще централизованно держать их в одном месте: регистрация доменов с понятным управлением DNS снижает шанс случайно сломать MX/AAAA при очередном изменении.

TLS-проблемы: tls negotiation failed и что с этим делать

Ошибка tls negotiation failed в postfix/smtp означает, что при попытке установить защищённый канал (STARTTLS) стороны не смогли согласовать параметры: протокол, шифры, сертификат или проверку цепочки.

1) Проблема на стороне получателя или на вашей

Сначала определите характер отказов:

• Падает доставка на многие домены сразу — чаще всего причина на вашей стороне: время, CA bundle, DNS, политика TLS.
• Падает на один домен/провайдера — вероятна несовместимость политик или временная авария у получателя.

По конкретному домену удобно искать в логах:

grep -i "to=<" /var/log/mail.log | grep -i "example.net"

Если видите «certificate verify failed», «no shared cipher», «wrong version number», «hostname mismatch» — это уже точные маркеры направления ремонта.

2) Проверка STARTTLS до удалённого SMTP через openssl s_client

Чтобы понять, поддерживает ли удалённый сервер STARTTLS и что он предлагает, выполните:

openssl s_client -starttls smtp -connect mx1.example.net:25 -servername mx1.example.net -showcerts

Проверьте, какой протокол согласовался (TLSv1.2/TLSv1.3), нет ли просрочки сертификата и ошибок верификации.

Если верификация падает «везде», первыми действиями обычно будут: проверить системное время и обновить CA-пакет. Дальше уже разбирать тонкости политик Postfix.

3) Настройки Postfix для исходящего TLS: где смотреть

Ключевые параметры обычно лежат в main.cf. Посмотреть активные значения:

postconf -n | egrep '^(smtp_tls|smtp_tls_policy_maps|smtp_tls_security_level|smtp_tls_CAfile|smtp_tls_CApath)\s*='

• smtp_tls_security_level задаёт политику для исходящих соединений (например, opportunistic/verify/secure).
• Если включить жёсткую проверку для всех доменов, любой «кривой» сертификат у получателя станет причиной deferred или отказов.
• Более гибкий подход — использовать smtp_tls_policy_maps, чтобы точечно усиливать или ослаблять требования для отдельных доменов.

Не лечите массовые deferred из-за одного проблемного домена отключением TLS «везде». Сначала отделите частные случаи (policy map) от системных проблем (CA, время, DNS).

4) SNI и несоответствие имени сертификата

Некоторые MX-хосты обслуживают много доменов и отдают правильный сертификат только при наличии SNI. В openssl s_client это решается ключом -servername. В Postfix SNI поддерживается в современных версиях, но проблемы чаще возникают из-за проверки имени: когда имя, по которому вы верифицируете сертификат, не совпадает с тем, что реально в сертификате удалённого MX.

Если у вас строгий режим и в логах «hostname mismatch», проверьте, к какому имени Postfix привязывает проверку (MX-имя из DNS против CNAME/балансера). В некоторых сценариях помогает доставка именно на MX-имя из DNS, а не на «переименованный» хост.

Если вы используете строгую проверку сертификатов для исходящего TLS или вам важно корректно закрыть цепочку доверия на SMTP/IMAP, держите под рукой рабочие SSL-сертификаты (с валидной цепочкой CA): это экономит время при отладке «verify error» и проблем совместимости.

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

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

Подробнее

Как отличить временную проблему от постоянной и не устроить self-DoS

Когда Postfix держит много писем в deferred, легко усугубить ситуацию: форсируете очередь, растёт число исходящих соединений, DNS и сеть получают всплеск, и таймаутов становится ещё больше.

Рабочая последовательность такая:

1. Стабилизировать базу: DNS-резолвинг, системное время, CA, очевидные ошибки TLS/сертификатов.
2. По логам определить «тяжёлые» домены и причины (что именно и где ломается).
3. Только после этого аккуратно запускать повторную доставку: сначала точечно, затем при необходимости postqueue -f.

Мини-runbook: от симптома к решению (deferred/bounce по DNS/TLS)

Шаг 1. Оценить масштаб и тип ошибки

postqueue -p
postqueue -p | grep -i deferred | head

Выпишите 2–3 типовые формулировки ошибок и 2–3 домена, куда не уходит.

Шаг 2. Привязать ошибку к логам

grep -F "QUEUEID" /var/log/mail.log | tail -n 50

Ищите postfix/smtp и упоминания DNS/TLS.

Шаг 3. Проверить DNS-резолвинг и PTR/FCrDNS

getent ahosts mx1.example.net

Если подозрение на репутацию/идентификацию по DNS — проверьте PTR/FCrDNS и соответствие FQDN с HELO (через myhostname и smtp_helo_name).

Шаг 4. Проверить TLS к проблемному домену

openssl s_client -starttls smtp -connect mx1.example.net:25 -servername mx1.example.net

Если «verify error» — проверьте CA bundle и время. Если «no shared cipher» — вопрос совместимости шифров/протоколов (или слишком жёсткой вашей политики).

Шаг 5. После исправлений аккуратно разгрузить очередь

postqueue -f

Если отложенных слишком много и часть гарантированно не нужна — удаляйте точечно через postsuper, а не «всё подряд».

Частые вопросы админов

Почему часть писем сразу bounce, а часть deferred?

Потому что SMTP-коды различаются. 4xx обычно означает временную проблему (deferred), 5xx — постоянную (bounce). Ещё bounce возникает, когда истёк срок удержания письма в очереди.

Можно ли просто очистить очередь и «всё починится»?

Очистка лечит симптомы (перестанет расти диск и нагрузка), но не первопричину. Если это DNS или TLS, после очистки новые письма начнут копиться снова.

Какие ошибки DNS/TLS самые критичные для доставки?

Из DNS — сломанный резолвинг, отсутствие или неверный rDNS PTR у исходящего IP, несоответствие HELO имени. Из TLS — неверное системное время, битый CA bundle, слишком жёсткая политика в smtp_tls_security_level без исключений для проблемных доменов.

Итог

Когда вы видите status=deferred в Postfix, не начинайте с «магических» перезапусков. Сначала разберите очередь через mailq или postqueue -p, привяжите проблему к логам, затем проверьте DNS (включая rDNS PTR и HELO), и только после этого разбирайте TLS через openssl s_client и параметры smtp_tls_*. Такой порядок обычно даёт самый быстрый ремонт без потери писем и без лишней нагрузки от повторных прогонов.