Почему сервер отклоняет письмо с кодом 550

SMTP 550 — постоянный отказ принять конкретную команду или письмо в его текущем виде. Это не диагноз: сервер может отклонить адрес, отправителя, содержимое или отправку по своей политике. Я покажу, как по полному ответу и месту отказа найти причину, проверить логи и выбрать следующий шаг.

Что означает SMTP-код 550

В SMTP первая цифра задает класс ответа: 2 означает успех, 3 — что сервер ждет продолжения, 4 — временный отказ, 5 — постоянный отказ для запроса в его текущем виде. Поэтому 550 нельзя лечить бесконечным повтором той же отправки. Но слово «постоянный» не означает «починить невозможно»: исправьте адрес, авторизацию или политику отправителя — и новая попытка уже будет другим запросом. Это важное различие: код говорит, повторять ли без изменений, а не кто виноват и что именно сломалось. SMTP-ответ появляется в ходе диалога с сервером, но из этого не следует, что соединение было исправным на всех предыдущих или последующих этапах доставки. Если проблема повторяется в корпоративной переписке, мы настраиваем и поддерживаем корпоративную почту как часть рабочей инфраструктуры.

Смотрите на всю строку, а не только на три цифры: например, 550 5.1.1 обычно указывает на недействительный адрес ящика, а 5.7.1 — на запрет по политике или авторизации. Это расширенные коды состояния, и они конкретнее общего ответа 550, но текст после них тоже важен: его формулирует конкретный сервер. Код 552 не является универсальным синонимом переполненного ящика, а 554 не означает всегда один и тот же фильтр; значение выясняют по подкоду, тексту и этапу SMTP. Протокол не выдает телепатию в комплекте.

Отказ мог прийти при MAIL FROM, при проверке получателя RCPT TO или после передачи содержимого на DATA. Эта точка резко сужает круг причин: адрес получателя проверяют, если отказ связан с адресной командой; текст письма и политику фильтра — если сервер отклонил его после передачи данных. Скопируйте полный ответ из отчета о недоставке, включая имя отвечавшего узла, подкод и строку диагностики. Один только скриншот из почтовой программы обычно обрезает самое полезное.

• Сохраните полный ответ, включая подкод и текст.
• Запишите адрес получателя и время попытки.
• Уточните команду SMTP, после которой пришел отказ.

Сначала локализуйте отказ: отправитель, сервер или адресат

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

Если сервер отклоняет отправителя до приема письма, проверяйте адрес MAIL FROM, разрешенные домены и требование SMTP AUTH. Ответы вида relay access denied обычно говорят, что сервер не разрешил пересылку в этом контексте: важны адрес подключения, авторизация и тип порта. Это не доказательство открытого релея и не повод вслепую менять ограничения Postfix. Если отправка проходит через 1С, сверьте SMTP-узел, порт, имя пользователя, пароль и адрес отправителя с параметрами, которые выдал администратор почты; платформа отдельно настраивает параметры почтового сервера и авторизацию. В статье о том, почему 1С не отправляет почту разбираю соседний сценарий на стороне приложения.

Если один и тот же сервер принимает письма для части получателей, но возвращает отказ для других, соберите сравнение по домену назначения, тексту ответа и этапу отказа. Политика принимающей стороны может учитывать и репутацию IP, и настройки аутентификации, и содержимое, но один 550 не доказывает ни одну из этих причин. Если ошибка появилась после смены исходящего сервера, отдельно проверьте, какой узел фактически устанавливает внешнее SMTP-соединение: NAT, шлюз или отдельный релей могут отправлять с другого адреса, чем вы ожидали. Проверка конфигурации без проверки реального маршрута — способ чинить не тот сервер.

Как читать логи Postfix и отчет о недоставке

В Postfix ищите запись по времени отправки, адресу получателя, идентификатору очереди и строке status=bounced или reject. Расположение журнала зависит от дистрибутива и способа настройки системного журнала: на одном сервере записи идут в файл почтового лога, на другом доступны через systemd journal. На системе с соответствующей службой можно начать с journalctl -u postfix --since "30 minutes ago"; если unit называется иначе или журнал отправлен в syslog, сначала определите фактический источник. Команда grep 550 /var/log/mail.log полезна только когда такой файл есть и в нем записан нужный отказ. Не копируйте путь из чужой инструкции как универсальную настройку.

Сопоставьте строку Postfix с отчетом о недоставке (NDR/DSN), который получил отправитель. В отчете важны исходный домен, диагностический текст принимающего узла и расширенный статус вроде 5.1.1 или 5.7.1. Имя службы в локальном логе показывает, какой компонент принял или передал сообщение; оно не всегда совпадает с сервером, который вынес итоговый отказ. Если сообщение попало в очередь и позже получило отказ от удаленного узла, изучайте журнал доставки для того же идентификатора, а не только запись приложения «отправка не удалась».

Не публикуйте логи целиком в открытом чате. В них бывают адреса сотрудников, внутренние имена узлов, IP и фрагменты темы письма. Для разбора оставьте время, подкод, команду SMTP, домен назначения и идентификатор очереди; адреса и технические реквизиты замаскируйте. После исправления отправьте одно тестовое письмо и проверьте новый ответ. Исчезновение всплывающего окна в 1С еще не доказывает доставку: подтверждением служит принятие сообщения следующим сервером и, если задача критична, проверка у получателя.

• Найдите запись по времени и получателю.
• Сверьте queue ID в связанных строках.
• Читайте полный ответ удаленного SMTP-сервера.

SPF, DKIM, DMARC и обратная DNS-запись

Проверяйте почтовую аутентификацию, если полный ответ указывает на политику или если отказ начался после смены домена, исходящего IP либо релея. SPF — DNS TXT-политика, перечисляющая разрешенные способы отправки от домена envelope sender; DKIM добавляет криптографическую подпись, которую получатель проверяет по открытому ключу в DNS. Эти механизмы отвечают на разные вопросы. Наличие записи SPF не гарантирует прием письма, а DKIM-подпись может перестать проходить после изменения подписанных заголовков или содержимого промежуточным сервисом. Проверяйте фактический IP отправителя, домен конверта, селектор DKIM и результат проверки именно в отчете конкретного получателя.

DMARC проверяет не просто наличие SPF и DKIM: результат должен пройти выравнивание с доменом в видимом поле From. Политика p=reject просит получателя отклонить сообщения, провалившие проверку DMARC; она не означает автоматический отказ при любой отдельной ошибке SPF или DKIM, если другой механизм прошел с нужным выравниванием. Перед включением строгой политики разберите отчеты и все законные источники исходящей почты: сайт, бухгалтерскую систему, рассылку и сервис уведомлений. Иначе можно собственноручно отрезать письма своей же организации. Настраивать следует домен отправителя и реальные потоки, а не копировать чужую TXT-строку.

PTR — обратная DNS-запись, которую обычно настраивает владелец адресного диапазона или хостинг-провайдер. Для исходящей почты проверьте, какой PTR возвращается для фактического публичного IP, и согласуйте его с именем почтового узла и прямой записью этого имени. Отсутствующий или несогласованный PTR может ухудшить прием у отдельных систем, но сам по себе не доказывает причину каждого 550 и не гарантирует мгновенный отказ у всех получателей. После правок DNS учитывайте TTL уже закэшированных ответов; обещать одинаковое «распространение за 48 часов» нельзя. Для смены MX и сохранения писем пригодится отдельная инструкция о проверке после переноса почты.

• SPF: разрешен ли фактический исходящий узел?
• DKIM: проходит ли подпись и совпадает ли селектор?
• DMARC: есть ли выравнивание с доменом From?
• PTR: кто обслуживает обратную запись IP?

Порты и авторизация почтового клиента

Порты 587 и 465 относятся к отправке почты клиентом на сервер отправки, но режим TLS у них различается: на 587 обычно начинается SMTP с переходом на TLS через STARTTLS, а на 465 используется TLS с начала соединения. Это не «SSL против TLS» и не универсальный рецепт для любого сервера: следуйте параметрам администратора вашей почты. Межсерверная доставка обычно использует порт 25. Если клиент не может открыть соединение или завершить TLS-согласование, чаще вы увидите ошибку подключения, а не ответ SMTP 550. Если же сервер вернул 550 после SMTP-команды, фиксируйте текст отказа и не лечите его переключением шифрования наугад.

Для сообщения relay access denied проверьте, что клиент подключен к submission-сервису, включена требуемая авторизация и учетная запись имеет право отправить письмо с указанным адресом. В некоторых системах логин может отличаться от адреса отправителя, а отправлять разрешено только от имени закрепленного ящика. Уточните эти правила у администратора. Не ослабляйте mynetworks, не разрешайте релей «для всех» и не редактируйте ограничения Postfix, пока журнал не показывает, что отказ сформировал именно ваш сервер: иначе можно открыть нежелательную пересылку и при этом не устранить исходную ошибку.

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

• 587: уточните, требуется ли STARTTLS.
• 465: уточните режим TLS с начала соединения.
• 25: проверьте маршрут межсерверной доставки.

Фильтрация и репутация: что делать с 5.7.1

Если сервер отвечает 5.7.1 или в тексте явно указаны политика, спам-фильтр либо блокировка, попросите администратора получателя сообщить основание отказа и точное время события. Проверьте IP, с которого реально ушло письмо, затем посмотрите статус этого адреса в тех списках, на которые ссылается получатель. Наличие IP в одном DNSBL/RBL не означает, что все почтовые системы блокируют его одинаково; отсутствие в известном списке тоже не доказывает чистую репутацию. Учитывайте только список или правило, названное в ответе, и не подавайте заявку на исключение до выяснения причины попадания.

Если отправка массовая, проверьте происхождение адресов, жалобы, отписку и скорость отправки. Устраните скомпрометированную учетную запись или форму на сайте, остановите нежелательный поток и только потом обращайтесь к оператору списка либо получателю с фактами. Внутренний фильтр тоже может вернуть 550, если отклонил письмо на входе; тогда изучайте правила и журнал именно принимающей системы. Снижать порог фильтра или добавлять исключение на весь домен ради одной жалобы — удобный способ превратить точечный симптом в широкую дыру.

Условный разбор для компании «Юпитер» выглядит так: после переезда тестовое письмо получает 550 5.7.1, а в диагностике удаленного узла явно упомянуто несоответствие домена. Мы не объявляем PTR причиной по умолчанию и не обещаем исправить доставку за сорок минут. Сначала сверяем внешний IP исходящего узла, SPF, DKIM и выравнивание DMARC; затем исправляем только найденное расхождение и повторяем тест к тому же получателю. Если ответ не называет причину, запрашиваем подробности у принимающей стороны. Так в кейсе есть проверяемая последовательность, а не магическое совпадение «добавили DNS — заработало».

• Сохраните точную причину из ответа принимающей стороны.
• Проверьте фактический исходящий IP и нужный список.
• Устраните источник нежелательной отправки до запроса на исключение.

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