Проблемы с отправкой почты через Sendmail: почему письма уходят медленно и как это чинить по шагам

Sendmail — тот самый “динозавр”, который до сих пор живёт на серверах, потому что однажды его настроили, и он не мешал. А потом внезапно начинает мешать. Самый частый симптом: письмо отправляется не сразу, а “думает” 20–60 секунд (или дольше), как будто SMTP там на модеме 56k.

Ниже — разбор реальных причин, из-за которых Sendmail тормозит именно на отправке, и набор проверок/фиксов, которые обычно возвращают почту к нормальной скорости.

Сначала пойми, где именно задержка: у тебя или у получателя

Не угадывай — посмотри на факты. У Sendmail в логах есть полезные поля: delay=, xdelay=, mailer=, stat=. Они показывают, сколько времени потратили на обработку и на общение с удалённым сервером.

Открой лог в момент отправки проблемного письма:

tail -f /var/log/maillog

Если видишь, что delay растёт ещё до попытки соединения с удалённым MX — чаще всего это DNS/hostname/локальная конфигурация. Если xdelay большой и mailer=esmtp — значит, упираешься в удалённую сторону (greylisting, “подвешивание” соединения, медленные ответы).

Причина №1: DNS тупит, и Sendmail ждёт как в очереди на почте

Sendmail очень любит DNS. Он резолвит MX получателя, он пытается понять каноническое имя хоста, он может делать обратные запросы. Если у тебя DNS работает через раз, “доставка черепахой” почти гарантирована.

Проверка простая: сколько времени занимает резолвинг домена получателя и обратный резолвинг твоего IP.

# MX домена получателя dig +time=2 +tries=1 MX example.com # A/AAAA (иногда тормозит именно IPv6-ветка) dig +time=2 +tries=1 A example.com dig +time=2 +tries=1 AAAA example.com

Если любой из запросов “думает” секунды и иногда падает по таймауту — это уже объясняет задержки.

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

• привести в порядок /etc/resolv.conf (рабочие DNS, без экзотики);
• иметь резервный DNS (два адреса лучше, чем один “сонный”);
• если сервер на systemd-resolved — проверить, что он реально резолвит, а не “всё через 127.0.0.53 и молитву”.

Быстрая диагностика systemd-resolved:

resolvectl status resolvectl query example.com

Причина №2: твой hostname резолвится криво (и Sendmail зависает на собственной идентификации)

Сюрприз, который ловят постоянно: у сервера красивый hostname, но он не резолвится в IP (или резолвится через DNS, который тупит). Sendmail при отправке/обработке сообщений может пытаться получить FQDN, каноническое имя — и терять время на этом.

Проверь, что твой hostname и FQDN находятся мгновенно:

hostname hostname -f getent hosts "$(hostname)" getent hosts "$(hostname -f)"

Если hostname -f зависает или возвращает ерунду — начни с простого: пропиши нормальную связку в /etc/hosts (и не делай там зоопарк из имён). Типичный рабочий вариант:

127.0.0.1 localhost 127.0.1.1 mail.example.com mail

Да, это “олдскул”. Зато перестаёт зависать базовая идентификация хоста, и Sendmail перестаёт думать перед каждым чихом.

Причина №3: обратная DNS (PTR) отсутствует или не совпадает, и удалённые серверы тебя “воспитывают” задержками

Некоторые почтовики не рубят сразу, а делают медленно и больно: принимают соединение, но отвечают с задержками, пока проверяют rDNS, репутацию, соответствие HELO и прочее.

Проверь свой IP:

# подставь внешний IP сервера dig +short -x 203.0.113.10 host 203.0.113.10

Если PTR нет или он ведёт в “random.vps.provider” — это не всегда смертельно, но часто это причина “письмо отправляется долго и печально”. PTR настраивается у провайдера/хостинга. И да, лучше чтобы PTR соответствовал нормальному имени, а имя имело A-запись обратно на этот IP.

Причина №4: таймауты соединения и попытки по IPv6

Бывает так: у домена получателя есть AAAA-запись, твой сервер пытается сходить по IPv6, а реального IPv6 у тебя нет или маршрут кривой. В итоге — секунд 20–30 тишины, потом fallback на IPv4. Снаружи выглядит как “Sendmail тормозит”.

Как проверить быстро

Посмотри, есть ли у получателя AAAA, и попробуй открыть SMTP-соединение на его MX по IPv6/IPv4:

dig +short MX example.com dig +short AAAA example.com # тест соединения (замени mx на реальный MX) nc -vz mx.example.com 25

Если у тебя IPv6 “как бы есть”, но на деле он ломается — либо чини IPv6, либо не давай сервисам пытаться ходить туда, где ничего не работает. В почте это часто экономит десятки секунд на каждом письме.

Причина №5: задержки у получателя (greylisting, антиспам, чёрные списки)

Иногда проблема не у тебя. Некоторые сервера намеренно отвечают медленно или временно отклоняют первое соединение (greylisting). Sendmail в таком случае честно кладёт письмо в очередь и пробует ещё раз позже.

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

mailq sendmail -bp

Для ручного прогона очереди (и чтобы увидеть, где именно зависает):

sendmail -q -v

Если в ответах видно 451/421 и “try again later” — это уже не “тормоза Sendmail”, а политика принимающей стороны. Тут лечится репутацией, правильным rDNS/HELO, SPF/DKIM, и иногда просто временем.

Что можно подкрутить в Sendmail, чтобы он меньше ждал

Если у тебя всё норм с DNS/hostname, но ты всё равно ловишь долгие попытки подключения к части хостов, разумно снизить таймауты соединения. Начни с confTO_CONNECT в sendmail.mc.

define(`confTO_CONNECT', `5s')dnl

5 секунд — нормальная “диагностическая” настройка: сразу видно, кто недоступен. Если у тебя сеть неидеальная, можно поставить 10–15 секунд. Делать 1–2 секунды обычно вредно: начнутся ложные недоставки.

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

cd /etc/mail m4 sendmail.mc > sendmail.cf # дальше перезапуск (название сервиса зависит от дистрибутива) systemctl restart sendmail || service sendmail restart

Ещё полезная привычка: не крутить всё подряд, а менять один параметр, отправлять тестовое письмо, смотреть лог, фиксировать результат. Иначе потом сам себе устроишь расследование на ровном месте.

Очередь mqueue: когда она становится твоим тайным врагом

Если в /var/spool/mqueue лежит гора старых писем, Sendmail будет тратить время на попытки их доставить, и свежая почта может выглядеть как “почему всё долго”. Проверь очередь и причины, почему сообщения не уходят.

mailq sendmail -bp

Если там застряли письма на несуществующие домены или вечно недоступные хосты — лучше разобраться, почему они туда попали, и аккуратно почистить “мертвяк”, чем кормить Sendmail бесконечными ретраями.

Быстрый чек-лист, который реально экономит время

• hostname -f должен отрабатывать мгновенно.
• dig MX и dig -x не должны “думать” по 5–10 секунд.
• PTR для внешнего IP лучше иметь, и чтобы он выглядел прилично.
• Посмотри delay/xdelay в логах — это быстрее любых догадок.
• Если половина доменов тормозит только на первом письме — это часто greylisting.

Заключение

Медленная отправка через Sendmail почти всегда сводится к двум вещам: DNS/hostname на твоей стороне или “воспитательные” задержки на стороне получателя. Начни с логов и простых проверок резолвинга — это даёт ответ быстрее, чем бесконечные правки sendmail.cf “наугад”.

А если Sendmail уже давно держится на честном слове и исторической памяти — Postfix часто оказывается более спокойным вариантом. Не потому что “моднее”, а потому что в 2026 году хочется, чтобы почта работала как сервис, а не как археологический экспонат.