1. Установите SMTP-сеанс и команду
Сохраните полный ответ сервера, имя peer, время, локальный идентификатор сеанса или очереди и команду, на которую дан отказ. 550 — код SMTP, не HTTP и не самостоятельное имя угрозы. Версию и настройки конкретного MTA нужно установить отдельно. Различайте envelope-получателя в RCPT TO и адрес из видимого заголовка письма.
2. Отберите сохранённый диалог
Найдите журнал уже выполненной отправки, не создавая тестовое письмо с реальными адресами. Сопоставьте RCPT TO и ответ того же соединения, затем прочитайте соседние строки. Для нескольких получателей составьте отдельный список исходов; отказ одному адресу не описывает судьбу остальных. Сохраните полный многострочный ответ, если он был, вместе с расширенным кодом при наличии.
3. Прочитайте пример
Иллюстрация показывает отказ 550 на RCPT TO для demo@example.invalid. Текст про локальную политику придумали для примера; его нельзя считать стандартным кодом причины. Ответ относится к данной команде и получателю. Он не подтверждает, что не существует весь домен, что вложение вредоносно или что письмо никогда не было доставлено иным маршрутом.
4. Разделите код и причину
550 относится к постоянному отрицательному завершению текущей команды. Конкретный смысл уточняют этап и текст peer: отказ может касаться адресата, доступа или политики. Не заменяйте это списком универсальных причин для любого MTA. Если есть расширенный status code, разберите его в собственном пространстве. Самостоятельно обходить ограничения релея или менять права получателя из этой карточки не требуется.
5. Проверьте дальнейшую судьбу
Сопоставьте локальный queue ID с решением отправляющего MTA, результатами остальных envelope-получателей и сформированным уведомлением о недоставке. Проверьте, не было ли другого успешного сеанса или изменения адреса в цепочке пересылки. В заключении укажите, какой сервер отказал, на каком этапе и кому; отдельно опишите подтверждённый конечный исход сообщения.
6. Если нужного ответа нет
Проверьте узел отправки, временной интервал, лог-ротацию и посредника, который реально общался с peer. В приложении может сохраниться только краткая ошибка без SMTP-диалога; тогда не приписывайте ей конкретную причину 550. Если доступен лишь bounce, сохраняйте его безопасные технические детали. Отсутствие строки в одном MTA не доказывает отсутствие передачи через другую очередь.