Причины и способы устранения ошибки SMTP 550

SMTP 550 — это наиболее распространенный код ошибки доставки электронных писем, но он также является одним из наиболее часто неправильно диагностируемых. Одни и те же три цифры могут означать, что получатель не существует, отправитель не прошел аутентификацию, сообщение попало в спам-фильтр или что-то еще. Gmail и основной объем заказов Yahoo в 2024 году правила отправителя В результате этого варианты ошибки SMTP 550, приводящие к сбою аутентификации, стали встречаться чаще и быть более разнообразными.

Самый быстрый способ устранить ошибку 550 — прочитать полное сообщение, а не только трехзначный код. RFC 5321Ответ 5xx означает, что сбой является необратимым в текущих условиях. Повторная попытка отправки того же сообщения без устранения причины обычно приводит к тому же результату.

Субкоды SMTP 550: краткий справочник

Подкоды соответствуют формату расширенного кода состояния RFC 3463 (обозначение XXX, которое появляется после основного кода 550 в сообщении о возврате). Первая цифра всегда равна 5 для постоянных сбоев, а остальные цифры определяют конкретный класс причины. В этой таблице описаны шесть подкодов, которые вы, скорее всего, увидите:

При получении уведомления о недоставке откройте сообщение полностью, прежде чем предпринимать какие-либо действия. Подкод отображается сразу после 550, за которым следует объяснение принимающего сервера. Используйте эти данные, чтобы определить причину и выбрать первое решение для проверки.

Причины и способы устранения ошибок SMTP 550

Каждая из перечисленных ниже причин соответствует определенному шаблону подкода и тексту сообщения об ошибке. Сначала определите подкод, а затем примените соответствующее исправление.

Неверный или несуществующий адрес получателя

Клинический диагноз: Подкод обычно 5.1.1 или 5.1.0. Текст сообщения об ошибке часто содержит фразы типа «пользователь неизвестен», «пользователя нет», «почтовый ящик не найден» или «адрес отклонен». Это проблема на стороне получателя, то есть почтовый ящик либо никогда не существовал, либо был удален.

Fix: Проверьте правильность написания адреса получателя, как локальной части до символа @, так и доменной части после него. Распространенные причины: перестановка символов (jmith вместо jsmith), неправильное расширение домена (.co вместо .com) и устаревшие адреса контактов, сменивших работу или почтового провайдера.

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

Ошибка аутентификации отправителя (SPF, DKIM или DMARC)

Клинический диагноз: Подкод обычно равен 5.7.1 или 5.7.26. В сообщении об ошибке часто упоминаются «аутентификация», «политика DMARC», «SPF», «DKIM» или содержатся фразы типа «неаутентифицированное электронное письмо не принимается» или «не соответствует требованиям отправителя».

Fix: Подтвердите это SPF, DKIM и DMARC Настроены правильно для домена отправителя и согласованы с доменом заголовка From. Для SPF убедитесь, что отправляющий IP-адрес или служба авторизованы в записи DNS. Для DKIM убедитесь, что подпись присутствует и проходит проверку. Для DMARC убедитесь, что политика опубликована и согласована хотя бы с одним из протоколов: SPF или DKIM.

Распространенный сценарий: Отправка через стороннюю платформу, такую ​​как SendGrid, Mailgun, маркетинговый инструмент или службу поддержки, без добавления этой платформы в SPF-запись домена или включения подписи DKIM для пользовательского домена. Платформа успешно отправляет сообщение со своей собственной инфраструктуры, но принимающий сервер отклоняет сообщение, поскольку домен-отправитель не авторизован для использования этого IP-адреса отправителя.

IP-адрес или домен отправителя в чёрном списке

Клинический диагноз: В сообщении об ошибке упоминаются слова «в черном списке», «заблокирован», «плохая репутация», «внесен в черный список» или указывается конкретный черный список (Spamhaus, Barracuda, SORBS, UCE-Protect). Некоторые принимающие серверы скрывают название черного списка и возвращают только общее сообщение об отказе. В этом случае проверка черного списка с помощью MXToolbox выявит конкретную запись в нем.

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

Расследование первопричин: Внесение адреса в чёрный список не происходит случайно. Распространённые причины включают многократную отправку писем на недействительные адреса, приводящую к жёстким отказам, высокий уровень жалоб на нежелательную электронную почту или взлом почтового ящика или сервера, рассылающего спам. Понимание репутация отправителя электронной почты Сигналы помогают определить, какое именно поведение привело к появлению объявления, чтобы его можно было исправить до запроса на удаление объявления.

Сообщение отклонено контентными фильтрами.

Клинический диагноз: В сообщении об ошибке упоминаются «высокий показатель спама», «контент отклонен», «подозрительный спам», «сообщение отфильтровано» или указывается конкретная система фильтрации (SpamAssassin, Postini, Barracuda). Принимающий сервер принял соединение, но отклонил конкретное сообщение после проверки его содержимого.

Fix: Проверьте содержимое сообщения на наличие шаблонов, которые фильтры контента часто выявляют, например, рекламные формулировки, перемежающиеся фразами, указывающими на срочность, заголовки, написанные заглавными буквами, подозрительные вложения (.exe, .zip от неизвестных отправителей), отображаемые имена, не соответствующие адресу отправителя, или сокращатели URL-адресов, указывающие на ненадежные адреса. Удаление или изменение формулировки содержимого, вызывающего проблему, обычно устраняет отклонение сообщения в версии 5.7.x.

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

Передача не разрешена или отсутствует аутентификация SMTP.

Клинический диагноз: Подкод обычно равен 5.4.1 или 5.7.1, а текст ошибки гласит: «пересылка запрещена», «пересылка запрещена», «пересылка запрещена» или «требуется аутентификация для пересылки». Эта ошибка исходит от исходящего SMTP-сервера, а не от сервера получателя (отправляющий клиент не авторизован для использования пересылки).

Fix: Включите аутентификацию SMTP в почтовом клиенте. В Outlook: Настройки учетной записи → Дополнительные параметры → Сервер исходящей почты → установите флажок «Мой сервер исходящей почты (SMTP) требует аутентификации». В Gmail SMTP: убедитесь, что для отправляющей учетной записи настроен пароль приложения, если включена двухфакторная аутентификация.

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

Почтовый ящик получателя заполнен или отключен

Клинический диагноз: Код ошибки обычно 5.2.1 или 5.2.2, а текст сообщения об ошибке гласит: «почтовый ящик переполнен», «превышен лимит квоты», «превышена квота хранилища», «отключено» или «сообщения не принимаются». Почтовый ящик существует, но не может получать новые письма.

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

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

Как предотвратить ошибки SMTP 550 в будущем

Профилактика эффективнее исправления ошибок по каждой из 550 категорий. Большинство повторяющихся ошибок по 550 связаны с одной из четырех слабых или отсутствующих практик.

• Перед отправкой письма обязательно проверяйте каждый адрес электронной почты: Проверка в режиме реального времени при регистрации и периодическая массовая проверка существующих списков позволяют выявлять недействительные адреса (основную причину ошибок 5.1.1) до того, как они достигнут потока отправителей. Проверка списка адресов электронной почты Помечает недействительные, одноразовые и адреса высокого риска с помощью многоуровневой проверки.
• Обеспечьте соответствие протоколов SPF, DKIM и DMARC для каждого домена и поддомена отправителя: Сбои аутентификации — это быстрорастущая категория причин ошибок, связанных с версией 550. Поддержание актуальности аутентификации, особенно при добавлении новых платформ отправки в стек, предотвращает большую часть ошибок версии 5.7.x до того, как они появятся в отчетах о недоставке.
• Постоянно отслеживайте репутацию отправителя: Угрозы попадания в чёрные списки и всплески жалоб не появляются внезапно. Они формируются на основе закономерностей, которые видны при мониторинге репутации, прежде чем перерасти в прямые отказы. Ежедневный мониторинг с помощью Google Postmaster Tools и регулярные проверки чёрных списков позволяют выявлять проблемы с репутацией доменов и IP-адресов на той стадии, когда их ещё легко исправить.
• Регулярно очищайте список рассылки: Адреса, на которые постоянно поступают ошибки версии 5.2.x, жесткие отказы и адреса хронически неактивных контактов, следует удалить перед следующей кампанией. Очистка списка электронных адресов Использование этих записей позволяет поддерживать низкий уровень отказов и хорошие показатели репутации, снижая частоту ошибок 550, связанных с фильтрами контента и черными списками.

Устранение ошибок SMTP 550 раз и навсегда

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

Пять наиболее распространенных причин можно предотвратить с помощью правильных методов обработки данных на исходном этапе: недействительные получатели выявляются путем проверки списка перед отправкой; сбои аутентификации предотвращаются путем поддержания SPF, DKIM и DMARC на каждом домене отправителя; попадание в черный список предотвращается путем мониторинга репутации и поддержания низкого уровня отказов; отклонения контента предотвращаются за счет использования чистых копий и аутентифицированных доменов; а блокировки ретрансляции устраняются за счет корректных учетных данных SMTP.

С момента вступления в силу требований к отправителям в 2024 году ошибки аутентификации, особенно ответы 5.7.1 и 5.7.26, стали встречаться чаще. Если вы наблюдаете всплеск ошибок 550 от Gmail или Yahoo и давно не проверяли свою систему аутентификации, то это первое, на что следует обратить внимание.

Чтобы устранить наиболее распространенную причину ошибок на стороне сервера, а также проблему аутентификации, загрузите свой список в DeBounce перед следующей кампанией. Удалите недействительные адреса, ответственные за отказы по адресу 5.1.1, и отметьте рискованные адреса, которые влияют на репутационные сигналы, приводящие к отклонениям из-за попадания в черный список.