Postfix: не отправляется почта наружу — причины и решение

MAATRIX

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

Первым делом читаем лог

Postfix честно пишет причину отказа. Не гадайте — откройте журнал и найдите строку про ваше письмо.

tail -f /var/log/mail.log        # Debian/Ubuntu
tail -f /var/log/maillog         # CentOS/RHEL
journalctl -u postfix -f         # systemd

Отправьте тестовое письмо и смотрите свежие строки:

echo "test body" | mail -s "test subject" you@gmail.com

Ключевые маркеры: status=deferred — письмо в очереди, отправка откладывается; status=bounced — отбито окончательно; Connection timed out — не достучались до чужого сервера; Relay access denied — отказ на нашей стороне. Дальше решение зависит от того, что именно вы увидели.

Не пропускайте этот шаг в пользу перебора настроек наугад. В девяти случаях из десяти строка лога прямо называет виновника: закрытый порт, недоступный DNS, отклонение принимающей стороной. Правка конфигов без чтения журнала — это лечение вслепую, когда диагноз уже написан в файле. Запомните различие между deferred и bounced: первое означает, что Postfix будет повторять попытки по расписанию (письмо ещё живо), второе — что он сдался и вернул отправителю отчёт о невозможности доставки. От этого зависит, есть ли у вас время на спокойную починку или письма уже теряются.

Заблокирован исходящий порт 25

Самая частая причина, особенно на новых VPS. Хостинги и облака по умолчанию закрывают исходящий TCP 25, чтобы с их адресов не рассылали спам. В логе это выглядит как connect to gmail-smtp-in.l.google.com ... Connection timed out.

Проверьте доступность порта наружу:

nc -vz gmail-smtp-in.l.google.com 25
# или
telnet gmail-smtp-in.l.google.com 25

Если соединение не устанавливается, а другие порты (например 443) открыты — порт 25 режет провайдер. Это не поломка, а осознанная политика: исходящий 25 закрывают почти все облака, потому что именно через него идут массовые спам-рассылки со скомпрометированных машин. Ваш сервер попал под общее правило, даже если рассылать вы ничего не собирались.

Решения два. Первое и правильное — попросить провайдера разблокировать исходящий 25 (у нормального хостинга это делается по тикету, часто после короткой проверки, что вы легитимный отправитель). Второе — отправлять через релей на 587-м порту с аутентификацией; этот путь описан ниже в разделе про смарт-хост и работает даже там, где 25-й закрыт наглухо. Прежде чем винить провайдера, убедитесь, что порт не режет ваш собственный локальный фаервол:

iptables -L OUTPUT -n | grep 25
ufw status

Postfix слушает только localhost

Если демон настроен на loopback, наружу он в принципе не пойдёт. Проверьте inet_interfaces:

postconf inet_interfaces

Значение loopback-only или 127.0.0.1 означает, что сервер принимает и обрабатывает только локальную почту. Для полноценной отправки на внешние адреса это не всегда обязательно (для исходящих важнее маршрутизация), но если сервер должен и принимать почту, поправьте:

inet_interfaces = all
inet_protocols = ipv4

Часто виновата именно строка inet_protocols: если сервер пытается ходить по IPv6, а рабочего IPv6-маршрута нет, соединения молча отваливаются в таймаут. Это коварная поломка, потому что в логе вы видите обычный «Connection timed out» и грешите на порт 25, хотя на самом деле Postfix упрямо выбирает AAAA-запись получателя и стучится по адресу, до которого у сервера нет пути. Принудительный ipv4 лечит это мгновенно и без побочных эффектов, если полноценный IPv6 вам сейчас не нужен. После правки перезапустите демон командой systemctl restart postfix и повторите тестовую отправку — таймауты должны исчезнуть.

DNS и разрешение имён MX

Postfix, чтобы доставить письмо, спрашивает у DNS MX-запись домена получателя. Если резолвинг на сервере сломан, отправка встанет с ошибкой вида Host or domain name not found. Name service error.

Проверьте, что сервер вообще видит DNS:

dig MX gmail.com +short
host -t mx gmail.com
cat /etc/resolv.conf

Пустой ответ или таймаут означает проблему с /etc/resolv.conf (нет рабочего nameserver) или закрытый исходящий порт 53. Пропишите надёжный резолвер:

nameserver 1.1.1.1
nameserver 8.8.8.8

На системах с systemd-resolved правьте не файл напрямую, а конфиг resolved, иначе изменения затрёт. После этого повторите тест отправки.

Письмо уходит, но получатель его отбивает

Порт открыт, DNS работает, письмо ушло — но прилетает 550 с текстом про SPF, PTR или «message not accepted for policy reasons». Это уже не про Postfix, а про репутацию вашего IP и записи домена. Крупные провайдеры отбивают почту с адресов без обратной зоны.

Минимальный набор, чтобы вас принимали:

• PTR (обратная запись). IP сервера должен резолвиться в ваш почтовый хост. Задаётся у владельца IP — то есть у хостинга. Проверка: dig -x ВАШ_IP +short.
• SPF. TXT-запись домена, разрешающая вашему IP отправку: v=spf1 ip4:ВАШ_IP -all.
• DKIM. Подпись писем; настраивается через OpenDKIM и TXT-запись с публичным ключом.
• HELO/hostname. myhostname в Postfix должен быть FQDN и совпадать с PTR.

postconf myhostname
dig -x $(curl -s ifconfig.me) +short

Без корректного PTR ни SPF, ни DKIM не спасут — Gmail и Outlook просто не берут почту с «безымянных» адресов. Порядок настройки здесь важен: сначала добейтесь, чтобы обратная запись резолвилась в ваш FQDN, затем приведите myhostname и HELO к тому же имени, и только потом занимайтесь SPF и DKIM. Если сделать наоборот, вы будете долго ловить отбойники с формулировками про «policy», не понимая, что фундамент — именно PTR. Поэтому для почтового сервера критичен провайдер, который выдаёт обратную запись по запросу и даёт чистый, не засвеченный в спам-листах IP; на дешёвых адресах из «грязных» подсетей репутацию не построить никакими записями.

Отправка через смарт-хост (релей)

Если порт 25 наружу закрыт наглухо и открыть его нельзя, настройте отправку через внешний SMTP-релей по 587 с логином и паролем. Это надёжный обходной путь.

relayhost = [smtp.provider.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Создайте файл с учёткой и захешируйте его:

echo "[smtp.provider.com]:587 user@domain:password" > /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd
chmod 600 /etc/postfix/sasl_passwd*
systemctl reload postfix

Теперь весь исходящий поток идёт через релей, и блокировка 25-го порта на вашей стороне уже не мешает.

Разгребаем застрявшую очередь

Пока чинили, письма копились. Посмотрите, что в очереди, и после исправления протолкните её:

mailq                    # что застряло и почему
postqueue -p             # то же самое
postqueue -f             # попытаться отправить всё сейчас
postcat -q ID_ПИСЬМА     # прочитать конкретное письмо
postsuper -d ALL deferred   # удалить отложенные (осторожно)

Если после postqueue -f письма ушли и в логе появился status=sent — проблема решена. Если снова deferred, вернитесь к логу: причина в нём.

Частые вопросы