Ошибки почтового сервера: пошаговый алгоритм диагностики

Сначала определите класс отказа: временный ответ 4xx требует повторной попытки или ожидания, постоянный 5xx указывает на проблему адресации, политики, аутентификации или репутации. Разница принципиальная. Неверная реакция на 451 создаёт очередь и повторные попытки. Повторная отправка после 550 без устранения причины не меняет результат.

Диагностика SMTP строится не по тексту сообщения в клиенте, а по цепочке событий: MSA принял запрос от пользователя, MTA сформировал соединение с сервером получателя, DNS вернул необходимые записи, удалённая сторона ответила кодом, результат записан в maillog. Каждый этап оставляет отдельный след. Ищите его в правильном порядке.

Сначала определите границу сбоя

Почтовая система состоит из нескольких компонентов. Ошибка в одном из них не означает неисправность всей инфраструктуры.

Типовая цепочка выглядит так:

1. Почтовый клиент передаёт сообщение на MSA.

2. MSA проверяет аутентификацию пользователя и принимает письмо.

3. MTA определяет домен получателя.

4. DNS возвращает MX-запись либо другой допустимый маршрут.

5. MTA устанавливает SMTP-соединение с сервером получателя через порт 25.

6. Сервер получателя проверяет отправителя, домен, IP, содержимое и локальную политику.

7. Сообщение принимается, откладывается или отклоняется.

Для клиентской отправки используется порт 587. Это submission-интерфейс для аутентифицированной передачи почты. Порт 25 предназначен для обмена между MTA. Не смешивайте эти сценарии при диагностике. Если пользователь не может отправить письмо из клиента, проверяйте MSA, учётные данные и доступность 587. Если сервер не доставляет почту на внешний домен, переходите к MTA, DNS, TCP-соединению и политике удалённой стороны.

Разделите симптомы

Зафиксируйте, где именно появляется ошибка:

• письмо не уходит из почтового клиента;
• MSA принимает письмо, но оно остаётся в очереди;
• MTA не может определить сервер назначения;
• TCP-соединение с удалённым MTA не устанавливается;
• удалённый сервер отвечает кодом 4xx;
• удалённый сервер отвечает кодом 5xx;
• SMTP-сервер возвращает 250 OK, но письмо не появляется во «Входящих».

Последний случай требует отдельного расследования. Успешный SMTP-ответ означает, что сервер принял сообщение на обработку. Он не гарантирует попадание письма именно во «Входящие». Дальше работают фильтры, антиспам, карантин и внутренняя маршрутизация получателя.

Код SMTP — это результат конкретного этапа протокола, а не универсальное заключение о состоянии письма.

Начните с идентификатора сообщения. Обычно это queue ID, message ID или внутренний идентификатор транспортной системы. Без него поиск по логам превращается в перебор строк за интервал времени. При массовом сбое это неприемлемо.

Как читать трёхзначный SMTP-код

Классические SMTP-ответы состоят из трёх цифр. Первая определяет общий результат операции:

Вторая цифра уточняет категорию ответа. 0 относится к синтаксическим ошибкам, 1 — к информационным ответам, 2 — к ошибкам канала связи, 5 — к статусу почтовой системы.

Третья цифра конкретизирует сценарий. Её нельзя трактовать отдельно от первых двух. Код 550 и код 553 относятся к одному постоянному классу, но могут указывать на разные проблемы: несуществующий ящик, блокировку, ошибку адреса или нарушение политики.

Текст после кода полезен, но вторичен. У разных MTA одинаковый код может сопровождаться разными формулировками. Анализируйте код, расширенный статус, домен назначения, IP отправителя и полную строку из лога.

Временные ошибки 4xx

Код 4xx означает, что удалённая сторона не приняла операцию сейчас. Причина может исчезнуть сама, поэтому MTA должен оставить письмо в очереди и выполнить повторную доставку по своей политике.

Наиболее распространённые варианты:

• 421 — удалённый сервер завершает соединение или временно недоступен;
• 450 — операция отклонена временно, часто на уровне ящика или локальной политики;
• 451 — временная ошибка обработки, greylisting или фильтр;
• 452 — временное ограничение ресурсов, например переполнение квоты или очереди;
• 4.7.x — временное отклонение, связанное с политикой или аутентификацией.

451 часто появляется при greylisting. Сервер назначения намеренно откладывает первое соединение от неизвестной пары отправитель–получатель или от нового IP. Корректный MTA должен повторить попытку. Если повторов нет, проверяйте настройки очереди и retry-политику.

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

Постоянные ошибки 5xx

Код 5xx означает, что сервер отверг операцию как постоянную. Частые причины:

• адрес получателя не существует;
• домен получателя не обслуживается;
• отправляющий IP находится в DNSBL;
• нарушена политика SPF, DKIM или DMARC;
• сервер отправителя не имеет корректного PTR;
• соединение идёт с запрещённого адреса;
• письмо отклонено локальным антиспамом;
• превышены ограничения, которые удалённая сторона считает постоянными.

Код 550 — не одна конкретная неисправность. Он сообщает о постоянном отказе, но причина определяется расширенным статусом и текстом ответа. Код 550 5.1.1 обычно требует проверки адреса получателя. Код 550 5.7.1 чаще связан с политикой, аутентификацией или блокировкой.

Не удаляйте сообщение из очереди и не запускайте бесконечный retry для 5xx. Это увеличивает шум в логах и может ухудшить репутацию IP. Сначала исправьте причину отказа. Затем отправьте новое сообщение или инициируйте повторную обработку только по контролируемому сценарию.

Расширенные коды RFC 1893 и RFC 3463

Трёхзначного ответа иногда недостаточно. Для детализации применяются Enhanced Mail System Status Codes. Они имеют формат X.Y.Z.

Пример 5.7.1 разбирается так:

• первая цифра 5 — постоянная ошибка;
• вторая цифра 7 — политика, безопасность или аутентификация;
• третья цифра 1 — конкретный вариант отказа в рамках категории.

Первый компонент согласуется с классическим SMTP-кодом. Если строка начинается с 4, перед сервером временная проблема. Если с 5, автоматический повтор без изменений не является решением.

На практике встречаются следующие группы:

Код 5.7.1 нельзя исправить добавлением произвольной DNS-записи. Сначала установите, какая именно проверка провалилась. Удалённый MTA может отклонять письмо из-за SPF, отсутствия DKIM, провала DMARC, плохой репутации IP или комбинации факторов.

Текст ответа и расширенный код анализируйте вместе:

• 550 5.1.1 user unknown — проверяйте адрес и маршрут домена;
• 550 5.7.1 rejected — ищите нарушение политики или блокировку;
• 451 4.7.1 try again later — проверяйте временную политику, greylisting и частоту отправки;
• 452 4.2.2 mailbox full — повторная доставка возможна, но причина находится на стороне ящика получателя.

Не приписывайте удалённому серверу больше информации, чем он сообщил. Формулировка rejected не доказывает конкретную причину. Для вывода нужны DNS, логи, параметры соединения и повторяемость отказа.

Анализ maillog: ищите не сообщение, а последовательность

Логи почтового сервера показывают путь сообщения. Одной строки status=bounced недостаточно. Требуется собрать цепочку:

1. создание сообщения;

2. присвоение идентификатора;

3. постановка в очередь;

4. попытка соединения;

5. ответ удалённого сервера;

6. изменение состояния;

7. окончательная доставка или возврат отправителю.

Формат зависит от MTA. В Postfix часто встречаются поля from=, to=, relay=, status=, delay=, dsn= и queue ID. В Exim структура другая. Не переносите команды и шаблоны поиска между системами без проверки формата.

Минимальный порядок поиска

Получите временной интервал. Затем найдите очередь по адресу получателя или идентификатору сообщения. После этого соберите все строки с тем же queue ID. Не ограничивайтесь последней записью.

Ищите:

• connect to — попытка установить TCP-соединение;
• Connection timed out — истечение времени ожидания;
• Connection refused — порт доступен на уровне маршрута, но сервис отклонил соединение либо фильтр активно отказал;
• Name or service not known — ошибка разрешения имени;
• Host or domain name not found — проблема DNS или маршрута домена;
• deferred — сообщение отложено;
• bounced — доставка окончательно завершилась отказом;
• status=sent — удалённый сервер принял сообщение;
• dsn= — расширенный статус доставки.

Не путайте deferred и bounced. Первое означает, что сообщение осталось в очереди и система планирует повтор. Второе означает окончательный отказ в текущем маршруте.

Пример логической интерпретации:

• status=deferred (host... said: 451...) — не удаляйте сообщение, проверьте retry и повторный ответ;
• status=bounced (host... said: 550 5.1.1...) — проверьте адрес получателя;
• status=bounced (host... said: 550 5.7.1...) — анализируйте политики домена, IP и аутентификацию;
• connect... timed out без SMTP-кода — удалённый MTA не ответил на сетевом уровне, протокольной ошибки ещё нет.

Что считать доказательством

Доказательством причины является согласованность нескольких признаков:

• один и тот же удалённый домен возвращает одинаковый код;
• отказ повторяется с одного исходящего IP;
• DNS-записи домена соответствуют фактической конфигурации;
• лог показывает конкретный этап сбоя;
• ручная проверка сетевого соединения воспроизводит проблему;
• после изменения настройки код меняется предсказуемо.

Не считайте доказательством одиночный текст из пользовательского интерфейса. Клиент может показать только обобщённое сообщение: сервер недоступен, письмо не отправлено, произошла ошибка. Это не диагностика.

Проверка DNS: MX, SPF, DKIM и PTR

Почтовая доставка зависит от нескольких независимых DNS-механизмов. Ошибка в одной записи может не мешать отправке на одни домены и полностью блокировать её на другие.

MX-запись получателя

Для доставки на домен отправляющий MTA должен определить сервер назначения. Начните с MX:

• существует ли MX-запись;
• возвращает ли DNS ожидаемые имена;
• разрешаются ли имена MX в IP;
• доступны ли эти IP по TCP/25;
• нет ли расхождения между доменом и фактическим маршрутом.

Если MX отсутствует, поведение зависит от конфигурации отправляющего MTA и DNS домена. Не делайте вывод по одному клиентскому сообщению. Проверьте ответ DNS с нескольких резолверов и сопоставьте его со временем возникновения сбоя.

SPF

SPF определяет, каким серверам разрешено отправлять почту от имени домена в envelope-from. Проверяйте:

• присутствует ли TXT-запись SPF;
• входит ли фактический исходящий IP в разрешённый механизм;
• не превышена ли сложность DNS-обработки;
• соответствует ли envelope-from домену, который проверяется;
• не опубликовано ли несколько конфликтующих SPF-записей.

SPF не подписывает письмо и не заменяет DKIM. Он проверяет разрешение IP для конкретного домена. Если письмо отправляется через внешний relay, этот relay должен быть отражён в SPF-политике либо доставка должна опираться на корректный DKIM и согласованный DMARC.

DKIM

DKIM связывает сообщение с доменом через криптографическую подпись. На стороне DNS публикуется открытый ключ в TXT-записи селектора. Проверяйте:

• совпадает ли селектор в заголовке DKIM-Signature с DNS-записью;
• доступен ли TXT-ключ;
• не повреждён ли формат записи;
• проходит ли проверка подписи после прохождения через relay;
• не изменяет ли промежуточный шлюз подписываемые заголовки или тело сообщения.

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

DMARC

DMARC оценивает согласованность домена в видимом поле From с результатами SPF и DKIM. Поэтому проверка DMARC требует анализа всего сообщения. Нельзя исправить DMARC, глядя только на TXT-запись политики.

Проверьте:

• домен политики DMARC;
• режим политики;
• наличие валидного SPF;
• наличие DKIM с корректным доменом подписи;
• alignment между From, envelope-from и DKIM d=;
• отчёты и повторяемость отказов.

Код 5.7.1 после публикации строгой DMARC-политики часто означает, что один из легитимных источников отправки не был добавлен в архитектуру домена. Это может быть CRM, сервис рассылок, helpdesk, ERP или отдельный MTA филиала.

PTR и прямая DNS-проверка

Исходящий IP должен иметь корректное обратное имя PTR. Затем имя должно согласованно разрешаться обратно в тот же IP либо соответствовать принятой политике провайдера. Формальное наличие PTR не гарантирует приём. Но отсутствие или несогласованность reverse DNS часто ухудшает оценку сервера.

Проверьте также:

• не меняется ли исходящий IP из-за NAT или балансировщика;
• какой IP реально видит удалённый MTA;
• совпадает ли он с IP, указанным в SPF;
• не используется ли динамический адрес;
• не занесён ли IP в DNSBL.

Проверка DNSBL не заменяет анализ ответа удалённого сервера. Список блокировок может быть устаревшим, а удалённый провайдер может использовать собственную репутационную базу.

Для сопоставления технических ограничений с внешними факторами инфраструктуры можно отдельно изучить материалы о новых поручениях по кадрам и инфраструктуре в туризме, но не используйте подобные публикации как источник для вывода о состоянии конкретного почтового IP или DNS-зоны.

Сетевой уровень: когда SMTP-кода ещё нет

Если в логе нет ответа 220, 4xx или 5xx, проблема может находиться до SMTP. Удалённый сервер не ответил на установление TCP-сессии или имя назначения не разрешилось.

Разделяйте четыре ситуации:

1. DNS не вернул адрес.

Проверяйте MX, A/AAAA, локальный resolver, DNSSEC при его использовании и доступность авторитетных серверов.

2. TCP-соединение не устанавливается.

Проверяйте маршрут, firewall, security group, NAT, ACL и блокировку исходящего порта 25 у хостинг-провайдера.

3. Соединение установлено, но удалённый сервер закрывает его.

Анализируйте лимиты, reverse DNS, репутацию IP и политику удалённой стороны.

4. SMTP-диалог начинается, затем прерывается.

Смотрите порядок команд, TLS, размер сообщения, тайм-ауты и ответ после MAIL FROM, RCPT TO или DATA.

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

Проверьте доступность порта с того же узла, где работает MTA. Проверка с ноутбука администратора не заменяет проверку с сервера отправки. Между ними могут отличаться маршрут, внешний IP, firewall и ограничения провайдера.

Почему не отправляются письма с сервера: типовые сценарии

Сценарий 1. MSA отклоняет учётные данные

Симптом: клиент не может отправить письмо через порт 587. В логах нет попытки доставки на внешний домен.

Порядок проверки:

1. Убедитесь, что клиент подключается к правильному hostname.

2. Проверьте порт 587 и режим TLS.

3. Проверьте имя пользователя в формате, который ожидает MSA.

4. Найдите в логе результат AUTH.

5. Убедитесь, что пользователь имеет право отправки через данный MSA.

6. Проверьте лимиты и блокировки учётной записи.

Не переносите проблему в DNS домена получателя. На этом этапе сообщение ещё не покинуло MSA.

Сценарий 2. Очередь растёт, удалённые домены не отвечают

Симптом: сообщения переходят в deferred, в логах тайм-ауты или ошибки соединения.

Проверьте:

• разрешение MX;
• маршрут до адреса назначения;
• исходящий TCP/25;
• локальный firewall;
• блокировку порта у хостинг-провайдера;
• очередь сообщений и скорость retry;
• нагрузку на MTA.

Если проблема появилась сразу для многих доменов, ищите общую причину: сеть, DNS, исходящий IP, firewall или отказ локального MTA. Если затронут один домен, не меняйте глобальную конфигурацию. Исследуйте его MX и ответы конкретных серверов.

Сценарий 3. Один домен возвращает 451

Симптом: доставка на другие домены работает, конкретный сервер отвечает 451.

Порядок действий:

1. Сохраните полный SMTP-ответ.

2. Проверьте, повторяет ли MTA доставку.

3. Сопоставьте IP отправителя и hostname.

4. Проверьте PTR и прямое разрешение имени.

5. Проверьте репутацию IP.

6. Посмотрите частоту соединений и объём отправки.

7. Убедитесь, что SPF и DKIM проходят.

8. Дождитесь следующей попытки и сравните ответ.

Не отключайте retry и не меняйте сразу содержимое письма. При greylisting это не устраняет причину. Если сервер получателя использует rate limit, уменьшите параллельность и проверьте локальную политику очереди.

Сценарий 4. Постоянный 550 5.1.1

Симптом: удалённый MTA сообщает, что получатель не существует.

Проверьте адрес после нормализации:

• лишние пробелы;
• неправильный домен;
• Unicode-символы;
• ошибочный алиас;
• устаревшая запись в адресной книге;
• рассинхронизация каталога и почтового сервера.

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

Сценарий 5. Постоянный 550 5.7.1

Симптом: сообщение отклоняется из-за политики или безопасности.

Проверьте в следующем порядке:

1. Реальный исходящий IP.

2. PTR и hostname в SMTP-приветствии.

3. SPF для envelope-from.

4. DKIM-подпись и DNS-ключ.

5. DMARC alignment для видимого From.

6. Наличие IP в DNSBL.

7. Полный ответ удалённого сервера.

8. Заголовки сообщения и путь через relay.

Если отправка идёт через сторонний сервис, проверяйте его IP, DKIM-селектор и envelope-from. Публикация SPF только для собственного сервера не разрешает отправку сервису рассылок. Аналогично, DKIM на одном узле не исправляет отсутствие подписи на другом.

Что менять после диагностики

Изменяйте одну переменную за раз. Иначе невозможно определить, какое изменение устранило отказ, а какое создало новый.

При проблеме DNS

Исправьте запись и дождитесь обновления кэшей в пределах TTL. После этого проверяйте результат с самого MTA и с независимого резолвера. Не ограничивайтесь панелью регистратора: она может показывать опубликованную зону, отличную от той, которую видит почтовый сервер.

При проблеме аутентификации

Разделите AUTH и транспорт. Пользователь может успешно пройти аутентификацию на 587, но MTA всё равно не сможет доставить письмо через 25. Исправление пароля не решает проблему DNS или репутации IP.

При проблеме очереди

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

При блокировке IP

Сначала подтвердите блокировку по ответу удалённого MTA или по его политике. Затем проверьте исходящий трафик: компрометированные учётные записи, открытый relay, массовые рассылки, ошибочные retry и неизвестные приложения, использующие SMTP. Запрос на разблокировку без устранения источника трафика обычно не даёт устойчивого результата.

При сбое DKIM

Проверьте соответствие селектора и ключа, длину TXT-записи, корректность DNS и момент подписания. Если письмо проходит через несколько MTA, установите, на каком узле подпись появляется и на каком становится недействительной.

Финальный алгоритм диагностики

Используйте последовательность, а не набор разрозненных проверок:

1. Зафиксируйте адрес отправителя, получателя, время и queue ID.

2. Определите точку отказа: MSA, MTA, DNS, TCP или удалённая политика.

3. Найдите все строки сообщения в maillog.

4. Извлеките полный SMTP-код и расширенный статус.

5. Разделите ответ на 4xx и 5xx.

6. Для 4xx проверьте очередь, retry, greylisting и rate limit.

7. Для 5xx проверьте адрес, политику, DNSBL и аутентификацию.

8. Проверьте MX домена назначения.

9. Проверьте фактический исходящий IP, PTR, SPF, DKIM и DMARC.

10. Проверьте TCP/25 с узла отправки.

11. Измените одну настройку.

12. Сравните новый ответ с исходным.

13. Закройте инцидент только после подтверждённой доставки либо понятного контролируемого отказа.

Полезный набор консольных операций зависит от MTA и ОС, но принцип одинаков: найдите запись DNS, проверьте маршрут, извлеките строки из журнала, сопоставьте их с идентификатором очереди. Для систем с типичным maillog применяются grep, awk, tail, dig, host, ss и штатные утилиты управления очередью. Запускайте их с ограничением по времени и домену. Вывод за весь журнал без фильтра создаёт массив данных, но не диагноз.

Ошибки почтового сервера диагностируются по цепочке фактов. Код 4xx требует контроля повторной доставки. Код 5xx требует исправления причины. Отсутствие SMTP-кода указывает на DNS или сеть. 250 OK подтверждает приём сервером, но не положение письма во «Входящих». Эта граница определяет корректный порядок действий и не позволяет подменять анализ повторными попытками.