Проблема
Когда вы, находясь вне дома, отправляете сообщение электронной почты с помощью домашней почтовой учетной записи, это сообщение может вернуться с ошибкой 550, 553 или ошибкой ретрансляции. То же самое может произойти, когда вы, находясь вне офиса, пытаетесь отправить сообщение электронной почты с помощью рабочей почтовой учетной записи.
Описание
Ретрансляция происходит, когда почтовое сообщение отправлено на адрес электронной почты, домен которого (имя после символа @, например adatum.com) не обрабатывается протоколом SMTP или сервером исходящей почты, получающим от отправителя запрос на доставку сообщения. SMTP-серверу необходимо подключиться к другому SMTP-серверу, чтобы ретранслировать сообщение.
Если при отправке почтового сообщения возникает ошибка ретрансляции, ваш SMTP-сервер (исходящей почты) может вернуть ваше сообщение вместе с сообщением об ошибке, например, такого вида:
-
«Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <proverka@example.com>. Тема: <тест>, учетная запись: <тест>, сервер: <smtp.example.com>, протокол: SMTP, ответ сервера: «550 <proverka@example.com>… Ретрансляция запрещена», порт: 25, защита (SSL): нет, ошибка сервера: 550, номер ошибки: 0x800CCC79″.
-
«Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <адрес эл. почты>. Тема: <тест>, учетная запись: <тест>, сервер: <smtp.example.com>, протокол: SMTP, ответ сервера: «553 к сожалению, этого домена нет в моем списке разрешенных узлов (#5.7.1)», порт: 25, защита (SSL): нет, ошибка сервера: 553, номер ошибки: 0x800CCC79″.
Точный текст сообщения об ошибке будет зависеть от вашего поставщика интернет-услуг. Некоторые поставщики не возвращают сообщение об ошибке, когда определяют исходящие сообщения как нежелательную рекламу. В этих случаях все выглядит так, как будто ваше сообщение отправляется в обычном режиме (в Outlook остается в папке Исходящие и появляется в папке Отправленные), но получателю оно не доставляется.
Ваше сообщение отклонено, поскольку SMTP-сервер (исходящей почты) не распознал вас как полномочного пользователя.
SMTP — это протокол (стандарты, используемые компьютерами для взаимодействия), который используется на большинстве серверов электронной почты для отправки сообщений в Интернете. Если вы используете почтовую программу (например, Outlook), которая позволяет хранить сообщения на компьютере, вам необходим доступ к SMTP-серверу для отправки сообщений.
Примечание: Веб-системы электронной почты (например, Windows Live Mail или Yahoo! Mail) работают иначе и не рассматриваются в этой статье.
Нежелательная почта и открытые ретрансляции
Нежелательные коммерческие сообщения иногда называют нежелательной почтой или спамом. Основной причиной увеличения объема нежелательной почты является то, что она стоит того, кто отправляет ее практически ничего не отправляемого; на самом деле отправителям даже не нужно отправлять нежела ту же почту через SMTP-сервер (исходятую почту) собственного isP.
При создании базовой структуры Интернета никто не предвидел, к каким последствиям приведет возможность отправлять миллионы нежелательных сообщений за ничтожно малую плату. Благодаря способности SMTP-серверов к ретрансляции отправители нежелательной почты маскируют ее подлинный источник, передавая ее через сторонние серверы, на которых разрешены такие открытые ретрансляции. В результате нежелательная почта как бы приходит с сайта, который ретранслирует сообщение и скрывает личность настоящего отправителя.
До недавнего времени большинство почтовых SMTP-серверов работали на основе доверительной открытой системы. В такой системе кто угодно откуда угодно может передать почтовое сообщение SMTP-серверу, а сервер должен принять его и переслать получателю или другому почтовому серверу, на котором находится почтовый ящик получателя. При такой открытой ретрансляции нет ограничений, запрещающих кому-либо отправлять почту через SMTP-сервер.
Ограничения поставщика интернет-услуг на ретрансляцию почтовых сообщений
По мере увеличения объемов нежелательной почты администраторы сети (люди, отвечающие за управление серверами поставщика интернет-услуг) начали вводить ограничения на своих почтовых SMTP-серверах. Эти ограничения не позволяют использовать почтовый сервер всем подряд. Представьте, что в вестибюле вашей организации есть телефон, доступный для всех, в том числе для тех, кто не является сотрудником организации. Теперь телефоном разрешено пользоваться только сотрудникам.
На сегодняшний день используются ограничения нескольких типов.
-
Требуется проверка подлинности SMTP. Так же как вы используете имя пользователя и пароль для доступа к POP3-серверу (входящей почты) и своим почтовым сообщениям, вам требуется ввести имя пользователя и пароль для отправки почтовых сообщений через SMTP-сервер. Обычно это те же имя пользователя и пароль, что и для POP3-сервера, но могут быть и уникальные.
-
Требуется сначала подключиться к POP3-серверу (входящей почты) поставщика интернет-услуг. Чтобы получить свои новые почтовые сообщения, вы обычно подключаетесь к POP3-серверу (входящей почты). Для доступа к почтовому ящику вам нужно ввести имя пользователя и пароль. Администратор сети может настроить сервер таким образом, что если вы сначала подключаетесь к POP3-серверу входящей почты и проходите проверку подлинности, он будет утверждать все запросы на отправку почтовых сообщений через SMTP-сервер исходящей почты, на котором в ином случае эта возможность будет ограничена.
-
Требуется подключение из авторизованного расположения в сети. Если вы из дома подключаетесь к поставщику интернет-услуг по телефонной линии, с помощью кабеля или через DSL-модем, подключение идет напрямую к сети поставщика. Вы заслуживаете доверия, поскольку у вас есть учетная запись с именем пользователя и паролем, которые предоставил поставщик интернет-услуг. Вам как клиенту разрешается использовать SMTP-сервер для отправки почтовых сообщений.
-
Требуется подключение с определенного IP-адреса или диапазона IP-адресов. Ваш поставщик интернет-услуг может разрешить доступ к SMTP-серверу людям, не подключенным к сети напрямую. Например, это может быть удаленный пользователь в офисе. Основная проблема состоит в том, что во многих местах используются динамические IP-адреса. При этом вы не можете быть уверены в том, что при каждом подключении у вас один и тот же IP-адрес. У некоторых организаций может быть зарезервирован блок или диапазон IP-адресов. Поставщик интернет-услуг может считать тех, кто подключается с этих IP-адресов, проверенными пользователями. Он может предоставить дополнительные сведения.
Возможных сценариев ретрансляции очень много. Ниже приведены самые распространенные ситуации. Возможно, одна из них похожа на вашу.
|
Ситуация |
Это ретрансляция? |
|---|---|
|
Вы дома, и у вас есть учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com, с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в первой ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, но она не блокируется. Вы подключаетесь напрямую к поставщику интернет-услуг и тем самым получаете полномочия для отправки почты через его SMTP-сервер (исходящей почты) на любые адреса, независимо от расположения почтового ящика получателя. |
|
Вы на работе. Ваш рабочий почтовый адрес оканчивается на @thephone-company.com, и у вас есть домашняя учетная запись поставщика интернет-услуг, адрес которой оканчивается на @proseware.com и с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
|
Вы остановились в гостинице или воспользовались в аэропорту интернет-терминалом, предоставляющим доступ в Интернет. У вас есть домашняя учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com, с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com. |
Нет. Ваша почта обрабатывается обычным способом. |
|
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com. |
Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя. |
Решения
Если ваша ситуация рассматривается как ретрансляция, вы должны отправить сообщение через сервер, к которому сейчас подключаетесь. То есть, если вы на работе или вне дома и не используете своего поставщика интернет-услуг для подключения к Интернету, но хотите отправить сообщение из своей домашней учетной записи, предоставленной этим поставщиком, вам нужно изменить параметры почтовой учетной записи, указав тот SMTP-сервер, который вы используете там, где находитесь (например, рабочий SMTP-сервер). Пошаговые инструкции см. в статье Изменение параметров учетной записи электронной почты.
Если это не работает или вы предпочитаете использовать домашнюю учетную запись, вам нужно связаться со своим поставщиком интернет-услуг и спросить, доступны ли вам описанные ранее параметры. Что касается первых двух ограничений (требуется проверка подлинности SMTP и требуется сначала подключение к POP3-серверу входящей почты поставщика интернет-услуг), вы можете внести изменения в Параметры учетной записи в Outlook. Инструкции см. в статье Изменение параметров учетной записи электронной почты.
Сообщения по-прежнему не отправляются?
Вы изменили параметры SMTP в Outlook или нашли параметр, который разрешит вам отправлять почтовые сообщения. Но вы по-прежнему не можете отправить почту и получаете сообщение об ошибке.
Возможно, вы все сделали правильно, но администраторы сети используют еще какую-то функцию системы безопасности для предотвращения спуфинга удостоверений. Спуфинг удостоверений — это просто способ отправки почтового сообщения, при котором вы скрываете, кто вы.
В Outlook, как и в большинстве почтовых программ, можно указать «отображаемое имя» и обратный почтовый адрес, который появляется при ответе на ваше сообщение. В нежелательной почте эти поля почти всегда содержат ложную информацию. Вы правда верите, что сообщения о том, как быстро разбогатеть, пришли от супермодели или мирового лидера?
Чтобы предотвратить спуфинг удостоверений, некоторые поставщики интернет-услуг ограничивают возможность вставки ложной информации в поле адреса в ответах. Например, если доменное имя вашего поставщика интернет-услуг оканчивается на proseware.com, поставщик может запретить вам указывать обратный адрес ivan@contoso.com. Это ограничение используется не так широко, как описанные ранее, но может применяться ко всем пользователям независимо от их местонахождения и способа подключения. В этом случае альтернативы нет. Если администратор сервера использует этот способ, вы должны указывать в обратном адресе домен, соответствующий вашему текущему подключению.
Есть почтовый сервер. CentOS+VestCP(exim+dovecot).
В принципе все гуляет хорошо, Настроено все, dkim, ptr, etc..
Но есть один ящик, на который не доходят письма..
Вот возврат этого письма:
*получатель*
SMTP error from remote mail server after RCPT TO:<*получатель*>:
host relay2.itsinternet.net [213.133.164.24]:
550 relay not permittedС других почтовиков на него все прекрасно уходит. Например с яндекса.
Прошу помочь с поиском решения, или понять происходящее для самостоятельного решения.
Прошу прощения. Писал много, и часть случайно удалил, и не заметил.
Письма отсылаются с нашего сервера на чужой сервер.
[root@mx ~]# exim -bt *получатель*
*получатель*
router = dnslookup, transport = remote_smtp
host relay.itsinternet.net [213.133.164.36] MX=5
host relay2.itsinternet.net [213.133.164.24] MX=10[root@mx exim]# cat /var/log/exim/main.log | grep *часть домена получателя*
2015-03-30 14:02:21 1YcXS2-0000Uk-Hn SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-03-30 14:02:46 1YcXS2-0000Uk-Hn == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-03-30 14:06:47 1YcXS2-0000Uk-Hn == *получатель(чужой)* routing defer (-51): retry time not reached
2015-03-30 15:07:13 1YcXS2-0000Uk-Hn SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-03-30 15:07:38 1YcXS2-0000Uk-Hn == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-03-30 16:07:13 1YcXS2-0000Uk-Hn SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-03-30 16:07:38 1YcXS2-0000Uk-Hn == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-03-30 17:06:47 1YcXS2-0000Uk-Hn == *получатель(чужой)* routing defer (-51): retry time not reached
2015-03-30 18:07:13 1YcXS2-0000Uk-Hn SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-03-30 18:07:37 1YcXS2-0000Uk-Hn ** *получатель(чужой)* R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 550 relay not permitted
2015-04-02 14:04:18 1Ydcv2-000116-I7 <= *получатель(чужой)* H=mail.itplus.kiev.ua [91.224.156.250] P=esmtps X=TLSv1:AES256-SHA:256 S=34035 id=E147CA6FDAEC464E8DE722F2CEC1A55A@Comp
2015-04-02 16:55:47 1Ydfaa-0003pE-2z SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 16:56:09 1Ydfaa-0003pE-2z ** *получатель(чужой)* R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 550 relay not permitted
2015-04-02 16:59:40 1YdfeM-0003qW-IO SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 17:00:05 1YdfeM-0003qW-IO == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-04-02 17:06:50 1YdfeM-0003qW-IO == *получатель(чужой)* routing defer (-51): retry time not reached
2015-04-02 18:07:16 1YdfeM-0003qW-IO SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 18:07:41 1YdfeM-0003qW-IO == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-04-02 19:07:16 1YdfeM-0003qW-IO SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 19:07:42 1YdfeM-0003qW-IO == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-04-02 20:06:50 1YdfeM-0003qW-IO == *получатель(чужой)* routing defer (-51): retry time not reached
2015-04-02 21:07:16 1YdfeM-0003qW-IO SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 21:07:42 1YdfeM-0003qW-IO == *получатель(чужой)* R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 451 Could not complete sender verify callout
2015-04-02 22:06:50 1YdfeM-0003qW-IO == *получатель(чужой)* routing defer (-51): retry time not reached
2015-04-02 23:07:16 1YdfeM-0003qW-IO SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay.itsinternet.net [213.133.164.36]: 451 Could not complete sender verify callout
2015-04-02 23:07:33 1YdfeM-0003qW-IO ** *получатель(чужой)* R=dnslookup T=remote_smtp: SMTP error from remote mail server after RCPT TO:<*получатель(чужой)*>: host relay2.itsinternet.net [213.133.164.24]: 550 relay not permittedTo send messages back and forth, email servers and clients rely on the simple mail transport protocol (SMTP). The protocol, which is part of the internet protocol family and specified in the RFC 5321 works with the popular mail protocols POP3 or IMAP. These have the exclusive function of collecting electronic mail in the inbox upon being received.
According to typical protocol, the server sends status codes via SMTP during communication to confirm the connection or dispatch, request additional information, or to notify of the termination of the connection. There are also codes that are used in the case of an error: temporary errors are assigned codes in the 4XX series, while serious errors associated with the failure of the request are identified by 5XX series status codes. For example, the outgoing mail server responds with SMTP 500 (including an optional message such as “Relay not permitted”) if an e-mail couldn’t be delivered to the desired address. What exactly does this error message mean, and how can you fix the SMTP error 550?
Contents
- What’s behind the SMTP 550 error?
- Which SMTP 550 error messages are there?
- How to solve the SMTP error 550
- “550 Relay not permitted”: How to fix the authentication problem
- “550 requested action not taken mailbox unavailable” – how to resolve the message
- What you can do about a “550 Reject due to policy restrictions” message
What’s behind the SMTP 550 error?
According to the “Request for Comments 5321” mentioned above, the standard form of the 550 SMTP status code “550 Requested action not taken: Mailbox unavailable” is translated approximately as “550 The requested action was not executed: P.O. box not reachable.” The IETF document lists the following three options as possible causes, among others:
- The target address is invalid (mailbox not found)
- It’s missing the rights for use of the SMTP service (no access)
- The request is denied for policy reasons (command rejected for policy reasons)
This means that the error message will always appear if an e-mail client wants to use SMTP for the transfer of electronic mail but the requestfails for one of the reasons listed above (among others). Whether the SMTP server passes on the cause of the problem to the client and in what form depends on the respective mail system as well as the client itself. As a result, the error message can look quite different, at least partially, though it’s often referring to the exact same problem.
Which SMTP 550 error messages are there?
The fact that the messages for the SMTP 550 error appear differently in the various mail services is at least partially due to the nature of the error itself: the basic information associated with the status code and standard message isn’t very specific. Without additional details, you’ll only know that the request was denied, but not why. It’s therefore always worth taking a close look at the message if you want to be able to fix the 550 error on your own. The following SMTP 550 messages are some of the most popular:
- 550 requested action not taken: mailbox unavailable
- 550 user unknown
- 550 mailbox not found
- 550 relay not permitted
- 550 recipient address rejected: user unknown in local recipient table
- 550 reject due to policy restrictions
- 550 invalid address
- 550 user has too many messages on the server
- 550 permanent failure for one or more recipients
Hosted Exchange with IONOS
The prefect solution for your business! Get the world’s leading email and calendar solution together with secure hosting from a single source!
25 GB email
Free domain
24/7 support
How to solve the SMTP error 550
The listing of well-known SMTP 550 messages makes it clear that there can’t possibly be just one single way to solve the problem. It’s important that you react appropriately to the respective cause for the error notification. However, it’s not always within your abilities to solve the problem yourself. In the following, we’ll show your possible solutions for three of the most common SMTP error 550 messages.
“550 Relay not permitted”: How to fix the authentication problem
The message “550 Relay not permitted” is the result of a failed connection between the e-mail client and mail server (some servers also use SMTP 553 for this). There are two things in particular that could be responsible for this problem: because a majority of mail servers rely on SMTP authentication (renewed password requests when sending) to make sure that no messages can be sent by an unauthorized person using your address, the SMTP 550 error can occur if this authentication method isn’t enabled in your client. On the flip side, it’s also possible that the access data has been entered incorrectly in the client.
In both cases, the solution is to check the outgoing server settings in the account settings of the e-mail program being used, and adjust them accordingly. In Outlook, for example, this is done as follows:
- After opening the account settings, select the account for which you want to modify the SMTP settings and then click on “Change”
- In the next menu, you’ll find the basic e-mail settings (user, server, and login information). No changes need to be made at this point. Instead, use the “Additional settings” button to get to the actual target menu, “Internet e-mail settings.”
- Once there, click on the “Outgoing server” tab. If there’s no check mark next to “The outgoing mail server (SMTP) requires authentication,” you can set it now to activate SMTP authentication in your Outlook client. If you also use the option “Use the same settings for the outgoing server,” then Outlook can work with the usual login credentials. If the authentication is already activated, but an individual username and password are defined that are different from the standard login, you should switch to the previous listed option to avoid the “550 Relay not permitted” message.
“550 requested action not taken mailbox unavailable” – how to resolve the message
If the basic variation of the SMTP 550 error – “550 requested action not taken mailbox unavailable” – is displayed, then the problem is usually that the intended target address couldn’t be reached by the SMTP server. In such cases, your first look should be at the address itself – it’s possible that a simple spelling error or typo slipped in when the e-mail was created. In many cases, though, the problem is on the recipient’s side. The message is typical if the recipient’s address isn’t temporarily available due to technical errors. The same generally goes for when the contacted e-mail account has been deactivated due to inactivity or deleted.
If you can reach the other party via another channel, you should do so. This way, you can make the problem known or find out the new, current (and valid) e-mail address. If you don’t have this option, then there’s nothing else to do other than try the sending again later. If the recipient was only temporarily unavailable, then the new attempt could be successful.
What you can do about a “550 Reject due to policy restrictions” message
If your e-mail client outputs the SMTP error “550 Reject due to policy restrictions,” this is a sign that components of the e-mail violate the guidelines of the mail provider. The following two violations are particularly common causes of the error message:
- Your e-mail address is a known spam address, so the SMTP transfer is blocked by the provider
- The address used by the sending server was not a fully qualified domain name, which leads to rejections by the provider
If the “550 Reject due to policy restrictions” error is the result of an incomplete sending server domain name, solve the problem by entering the complete name.
If the first situation is the case, however, you can find out using tools like the Blocklist Removal Center from Spamhaus: open the web application and enter your e-mail address in the field that says “Enter a Domain Name.”
When you click on the “Lookup” button, the tool searches through the “Domain Block List” database created by the Spamhaus Project, which contains a list of known spam domains. Within a few seconds, you’ll receive a notification as to whether your address is listed in the database.
If your e-mail address is marked as a spam address, you should contact the provider immediately so that you can work together to find a solution to the problem.
IMAP or POP3 – comparing e-mail protocols
When you set up your e-mail account you will sooner or later be faced with the decision of choosing between IMAP or POP3. Both transfer protocols help you receive your e-mails. But what are the differences between IMAP and POP3? And when is it best to use which protocol?
IMAP or POP3 – comparing e-mail protocols
Outlook won’t start – what now?
You cannot start Microsoft Outlook, your calendar is no longer accessible, an important e-mail can no longer be retrieved – when Microsoft’s popular and useful e-mail program fails, you have to laboriously access your inbox via your e-mail provider’s website. Usually, a defective Navigation Pane, outdated add-ins, or a profile in need of repair are at fault. Even with issues lacking clearly…
Outlook won’t start – what now?
How to fix the ERR_CONNECTION_RESET 101 error in Chrome, etc.
The message “ERR_CONNECTION_RESET” reveals that the connection has not been carried out as usual, or that is has been reset. However, the reason for these issues and possible solutions are not given. We explain why the error occurs, why it happens particularly frequently in Google Chrome and how to fix ERR_CONNECTION_RESET.
How to fix the ERR_CONNECTION_RESET 101 error in Chrome, etc.
What is SMTP? Definition and basics
SMTP stands for “Simple Mail Transfer Protocol” – but it’s not that simple. E-mails do not simply travel directly from A to B, but go through several communication and transmission processes that the standard network protocol has been responsible for since the 1980s. As an electronic set of rules from the internet protocol family, SMTP (and its extension, ESMTP) determines important factors such…
What is SMTP? Definition and basics
Email errors can be really bothersome – they can hit you hard and unexpected, when you attempt to send an urgent mail.
As part of our Server Support services for web hosting providers, we resolve email errors faced by website owners.
One commonly encountered email error is “SMTP error from remote mail server after RCPT TO”. It shows up when users try to send mails to other email accounts.
What is the error “SMTP error from remote mail server after RCPT TO”?
This error message is a very confusing one, as it can be triggered due to a number of causes. But usually the bounce message that arrives contains the details about the error.
The RCPT command is used to tell the sender mail server, who the recipient of your message is. The error message denotes that the sending mail server faced an error during that command, while trying to send mails.
To know the exact reason for the error, we examine the entire bounce message that the sender receives. And here are some of the major causes we’ve identified.
“SMTP error from remote mail server after RCPT TO” error – Causes & Fixes!
Mail server configuration issue or blacklisting, anything can cause a mail delivery error. We’ll see how to relate to the cause, from the error message we get.
1. Configuration errors
SMTP error from remote mail server after RCPT TO::
host domain.com [xx.xx.xx.xx]: 550-Please turn on SMTP Authentication in your mail client.
550-(host.domain.com) [yy.yy.yy.yy]: __ is not permitted to relay through this server without authentication.
Cause: The authentication errors mostly occur due to mail client or mail form configuration settings. If you try to send mails without proper authentication of your mail account, the mail server throws this error.
The authentication error also occurs when there is any mail server configuration issue – like domain not present in localdomains file or MX record mismatches.
Fix: The mail client settings should be properly configured with mail account details, SMTP server and port number. For PHP mail forms, using SMTP authentication to send out mails can help resolve this error.
To resolve mail server configuration errors, we examine the mail logs, MX records and related configuration files, and fix the discrepancies that are found in them.
2. Domain blacklists
SMTP error from remote mail server after RCPT TO::
host domain.com [xx.xx.xx.xx]: 550-"JunkMail rejected - host.domain.com [yy.yy.yy.yy]:
___ is in an RBL, see http://www.spamhaus.org/query/bl?ip=________"
SMTP error from remote mail server after RCPT TO:: host host.domain.com [xx.xx.xx.xx]:
554 5.7.1 Service unavailable; Client host [yy.yy.yy.yy] blocked using zen.spamhaus.org; http://www.spamhaus.org
Cause: RBLs aka blacklists are used by mail servers to prevent inbound spamming. When blacklist providers such as Spamhaus suspect your mail server as a spam origin, they will blacklist your server IP.
Getting blacklisted indicates that your server had a spammer or someone who is sending mass mails. Many times, server owners get to know about it only when users complain about mail errors.
Fix: Once blacklisted, getting de-listed is a time-consuming procedure. Pinpointing the source of spam and fixing it is the most important step. Then you need to request RBL to remove you from the list.
To ensure seamless mail delivery, it is important to avoid getting blacklisted. At Bobcares, we proactively secure the mail server and keep constant vigil on them to avoid all spamming activities that can cause the server to get blacklisted.
3. RDNS misconfiguration
SMTP error from remote mail server after RCPT TO::
host mx.domain.com [xx.xx.xx.xx]: 554 5.7.1 :
Client host rejected: envelope policy RBL PTRNUL
Cause: RDNS pointer records are used to map IP to hostname and it helps to validate a server. Many mail servers reject incoming mails from servers without proper RDNS records.
Fix: Setting RDNS records for the sending mail server helps to avoid such errors. At Bobcares, we configure critical mail records such as RDNS, SPF, DKIM, etc to ensure that mail delivery errors are avoided.
4. Recipient errors
SMTP error from remote mail server after RCPT TO: :
552 5.1.1 Mailbox delivery failure policy error
SMTP error from remote mail server after RCPT TO:
550 5.1.1 xxxxxxxx Recipient Suspended (TT999)
SMTP error from remote mail server after RCPT TO::
550 5.1.1 Recipient not found.
SMTP error from remote mail server after RCPT TO::
host mx.domain.com [xx.xx.xx.xx]: 550 Requested action not taken: mailbox unavailable
Cause: The mail delivery error ‘SMTP error from remote mail server after RCPT TO:’, can be caused by a range of issues at the recipient mail server.
These include missing or suspended recipient email account, incorrect MX records, custom blacklists or filters configured at the recipient email account, which cause mails to bounce back to sender.
Fix: The MX records of the recipient domain should be tested and confirmed to be working fine. For resolving issues at recipient end, you need to contact the remote mail server with these inputs.
5. Sender errors
SMTP error from remote mail server after RCPT TO::
host host.domain.com [xx.xx.xx.xx]: 554 5.1.8 :
Sender address rejected: Domain not found
SMTP error from remote mail server after RCPT TO::
host mx.server.com [xxx.xxx.xxx.xxx]: 550-Verification failed for
550-No Such User Here : Sender verify failed
Cause: A sender error can be caused due to many factors. The prominent reasons we have seen in our role as Website Support Techs for web hosting companies, include:
a. Duplicate sender account present in the recipient server
b. Misconfigured mail configuration settings
c. Sender email account doesn’t exist or cannot be detected
d. Permission issues caused by server migrations, updates or custom scripts
Fix: To resolve sender errors, we examine the mail server logs, sender email account settings, folder permissions, mail server configuration, etc. and resolve any issues related to that.
At Bobcares, our custom checklists for migrations and updates enable us to avoid any related issues that may pop up. We also audit the mail server settings periodically and reconfigure the ‘Email Routing’ as appropriate.
Conclusion
“SMTP error from remote mail server after RCPT TO” error is a common error that affects email delivery. Here we’ve discussed five major causes our Server Support Engineers have seen and how we fix it.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
SEE SERVER ADMIN PLANS
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Будучи менеджером коммерческого отдела небольшой торговой компании, я выполнял задачу по отправке нескольких сотен писем постоянным и потенциальным клиентам. Базу формировали из открытых источников мы сами, предложение было реально интересным целевой аудитории. Возникла «неожиданная» проблема – часть писем стала возвращаться. Кроме того, начали приходить сообщения с указаниями кодов ошибки SMTP. Своего IT-специалиста в штате у нас не было, потому разобраться с проблемой я решил самостоятельно. О результатах этой работы, причинах возникновения таких ошибок и методах их решения расскажу в этой статье.
Как избежать ошибок при составлении и отправке писем
Причинами возникновения ошибок и, как следствие, неполучения сообщений могут служить разные факторы. Одни из них связаны с неправильным составлением исходящих писем самим пользователем, другие относятся к более глобальным программным настройкам со стороны получателя.
Самый простой способ это понять – отправить тестовое сообщение на свой ящик. Затем следует протестировать его отправку и получение, используя разные внешние почтовые сервисы: gmail, yandex, mail, rambler и другие. Если сообщение получено, следует ответить на него, проверив корректность исполнения команды «RE» вашим почтовым сервером и принятие ответа условным отправителем.
Довольно часто проблемы с попаданием писем в папку «Спам» или программной блокировкой на стороне получателя лежат в неверном оформлении ключевых полей. Особенно это касается массовых рассылок коммерческого характера. Для отправки большого количества однотипных сообщений как минимум потребуется выполнение следующих параметров настройки:
- выделенный IP-адрес с целью исключить блокировку на стороне сервера-ретранслятора или почтовой программы конечного получателя;
- криптографические подписи DKIM и SPF, помогающие подтвердить подлинность домена и минимизировать количество писем, воспринимаемых как спам.
Важно! В случае несоблюдения этих элементарных правил вы рискуете не только тем, что конкретное письмо не будет доставлено адресату. При многократных попытках отправки письма в большинстве почтовых программ в блок-лист попадет вся корреспонденция, отправляемая с вашего email, и даже корпоративный домен (@domain.***).
Некорректное использование бота для отправки писем может привести к блокировке отправителя и другим нежелательным последствиям. Даже если информация, которую вы отправляете потенциальным клиентам, реально интересна им, система спам-фильтрации может воспринять данную рассылку как вредоносную. Чтобы избежать этого, лучше всего воспользоваться услугами специализированных компаний.
В моей практике был случай, когда никак не удавалось добиться получения моей электронной корреспонденции одним из сотрудников компании «Лукойл». Письма я отправлял самые простые, используя корпоративный ящик. Только после того, как мой респондент обратился в IT-службу своего предприятия, выяснилось, что данный адрес находится в блэк-листе. Попал он туда из-за каких-то ошибок, допущенных моим предшественником. Понадобилось больше недели, чтобы адрес включили в «белый список». Все это время письма, высылаемые с личного mail@yandex.ru, доходили без проблем.
Полезно: Почему не приходят письма с сайта. Пример частного случая.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостей
Подписаться
Положительные и отрицательные сообщения SMTP-сервера
SMTP (Simple Mail Transfer Protocol) — это протокол, используемый большинством почтовых программ для отправки электронных сообщений в сети интернет. Некорректное взаимодействие между серверами, индивидуальные настройки на уровне программного обеспечения и многие другие причины приводят к появлению ошибок. В этом случае письма не доходят до получателей, возвращаются обратно или просто «пропадают». При возникновении таких ситуаций отправитель получает сообщение о наличии конкретной ошибки, отражающей SMTP-код последнего отклика сервера.
Данные коды являются трехзначными, каждая его часть несет в себе определенную информацию, расшифровывающую причину сбоя.
Первая цифра комбинации содержит информацию о качестве доставки:
- сообщение доставлено («SMTP OK»);
- возникла неизвестная или временная проблема («SMTP unknown»);
- критическая ошибка («SMTP error»).
Существует четыре варианта значений для первой цифры кода:
- 2xx – положительный результат, есть возможность передачи следующей команды;
- 3xx – отложенный результат, необходимо осуществление дополнительных действий;
- 4xx – сообщение не принято, но проблема носит временный характер, и запрос может быть повторен через какое-то время;
- 5xx – категорический отказ выполнения команды, отправка запроса со стороны передающего сервера в том же виде невозможна.
Вторая цифра в коде сообщает о категории ответа:
- 0 – синтаксические ошибки;
- 1 – ответы на запросы информации;
- 2 – ошибки канала передачи;
- 3 и 4 – неизвестный тип ошибки;
- 5 – статус почтовой системы.
Третья цифра дает более расширенную информацию о значении, указанном во второй цифре SMTP-ответа.
Помимо цифровой комбинации, SMTP-сообщение может содержать дополнительную текстовую информацию.
Полную информацию о кодах, их компоновке и значениях можно найти в спецификациях RFC 5321 и RFC 1893.
Следует учитывать, что SMTP-message говорит об успешном или неудачном варианте доставки именно на уровне взаимодействия почтовых серверов. Положительный ответ вовсе не означает, что ваше письмо не попало в папку «Спам».
Читайте также
Виды почтовых сервисов
На программном уровне существует несколько видов обработки электронной почтовой корреспонденции. К первой группе относятся виртуальные сервисы, доступные чаще всего в бесплатном исполнении через интернет-соединение на сайте почтового сервера. Это всем известные ресурсы:
- Gmail/Google Suite (почта от Google.com);
- Yandex.ru;
- Mail.ru;
- Rambler.ru и другие.
Более подробную информацию о значениях ответов SMTP можно получить на сайтах популярных почтовых сервисов:
- Коды ошибок SMTP почтового сервиса Gmail (Google Suite) (support.google.com)
- Создание и отправка писем на сервисе Яндекс
- Ошибки отправки писем при использовании сервера и сервиса Mail.ru
Ко второй группе относятся почтовые клиенты – программы, обладающие более расширенным функционалом, чем виртуальные сервисы. Наиболее популярными и универсальными почтовыми клиентами для Windows являются:
- Opera Mail;
- Mozilla Thunderbird;
- Koma-Mail;
- SeaMonkey;
- The Bat!;
- Microsoft Outlook.
Принципы работы почтовых клиентов несколько отличаются от процесса обработки корреспонденции виртуальными серверами. При отправке сообщения программа отсылает его не напрямую конечному получателю, а ретранслирует через сервер-релей. Этот процесс осуществляется чаще всего с использованием протокола SMTP, а получение корреспонденции обычно происходит с помощью IMAP или POP.
Коды SMTP-ответов определяются стандартом. Администратор почтового сервера может создать собственные настройки, в том числе и в части кодировки ответов сервера. Особенно это касается локальных почтовых программ, установленных непосредственно на сервере какой-нибудь компании.
О вариантах выбора и способах создания корпоративных почтовых сервисов более подробно можно прочитать здесь: Что такое почтовый сервер и зачем он нужен.
Классификация отрицательных SMTP-сообщений. Способы решения проблем
Я настроил свою почтовую программу – локальный клиент (MS Outlook и т.п.) или бесплатную почту на gmail или yandex. Начинаю отправлять письма, но сталкиваюсь с различными проблемами, связанными с тем, что мои респонденты не получают направленную им корреспонденцию. Соответственно, на мой ящик приходят сообщения об ошибках в виде кодировок SMTP.
Сразу опускаю тот пакет сообщений, которые начинаются с 2хх и 3хх, так как они содержат информацию о том, что задача получения письма уже решена положительно либо получит такой статус в ближайшее время. Более подробно рассмотрим некоторые виды кодированных сообщений, начинающихся с 4хх и 5хх, т.е. отклики SMTP-сервера, которые сообщают о наличии проблем.
Почтовый сервер сообщил об ошибке 421
Значение: Service Not Available. Сервер недоступен: канал связи будет закрыт.
|
Возможные причины |
Варианты решения |
|
Неправильно заданы параметры SMTP-соединения |
Необходимо перепроверить настройки |
|
Брандмауэр блокирует IP-адрес сервера электронной почты |
Необходимо создать новое правило в брандмауэре |
|
Блокируется трафик через порт 25 |
Попробуйте в настройках учетной записи электронной почты сменить номер порта SMTP на 465 |
|
Проблема использования VPN |
Необходимо, чтобы провайдер услуги занес ваш почтовый сервер в белый список адресов VPN |
Данная ошибка возникает наряду с грейлистингом (Greylisting – «Серый список») при интенсивном использовании бесплатного SMTP-сервера, который лимитирует количество отправляемых сообщений в единицу времени. Для решения этой проблемы можно воспользоваться высоконагруженным SMTP-сервером. Чаще всего эта услуга является платной.
Получено сообщение с кодом 451
Значение: Requested action aborted: local error in processing. Требуемое действие прерывалось: ошибка в обработке.
|
Возможные причины |
Варианты решения |
|
Превышено количество допустимых подключений или лимит обмена сообщениями за отрезок времени, письма ждут отправки в очереди |
В настройках сервера увеличить лимит или задать ограничение не на количество подключений, а на количество писем на одного пользователя. Накопившуюся очередь писем можно отправить повторно командой «force send» |
|
Неправильно настроены MX-записи домена, из-за чего происходит неправильная маршрутизация писем |
Проверьте логи, конфигурационные файлы, МХ-записи и разрешения, внесите корректировки |
Устранение проблем с доставкой электронной почты для кода ошибок 451 4.7.500–699 (ASxxx) в Exchange Online. Электронная почта из доменов onmicrosoft.com ограничена и фильтруется для предотвращения спама.
Необходимо добавить настраиваемый домен.
Ошибка почтового сервера 452
Значение: Insufficient system resources. Запрашиваемое действие не выполнено: недостаточно места в системе.
|
Возможные причины |
Варианты решения |
|
На сервере получателя закончилось место, поэтому письмо не доставляется |
Чтобы в этом убедиться, достаточно попробовать осуществить отправку письма с другого сервера |
|
В сообщении присутствует текст «Out of memory». Это значит, что недостаточно места на вашем сервере |
Необходимо проверить количество отправляемых писем в очереди, наличие свободного места на диске и объем доступной памяти |
В Microsoft Exchange Server есть специальный компонент мониторинга доступных ресурсов Back Pressure, который отслеживает свободное место на диске, на котором хранятся очереди транспортной службы Exchange. При возникновении такой ошибки можно сделать следующее:
- очистить диск от ненужных файлов;
- отключить мониторинг Back Pressure (не рекомендуется);
- перенести транспортную очередь на другой диск достаточного объема.
Сервер сообщил об ошибке SMTP 550
Значение: Mailbox unavailable. Требуемые действия не предприняты: электронный ящик недоступен
|
Возможные причины |
Варианты решения |
|
Неверно указан email-адрес получателя |
Необходимо связаться с адресатом альтернативным способом и уточнить правильность написания адреса, а также убедиться, что он является действующим |
|
Система заражена вирусом, осуществляющим массовую рассылку писем с вашего адреса |
Провести полную проверку специализированной антивирусной программой |
|
На стороне вашего интернет-провайдера установлены ограничения на отправку исходящих сообщений |
Необходимо связаться с поставщиком интернет-услуг и получить консультацию по устранению данной проблемы |
|
Сервер получателя не работает |
Отправьте тестовое письмо на другой почтовый сервер. Свяжитесь с получателем и сообщите о проблеме |
Данная ошибка может возникнуть из-за настроек программы Антиспам на стороне получателя. Проверьте корректность оформления вашего письма и другие параметры, по которым ваше сообщение может быть отнесено к нежелательным.
Почтовый сервер ответил ошибкой 571
Значение: SMTP Protocol Returned a Permanent Error 571 xxx@mail.ru prohibited. We do not relay/Spam message rejected. Ошибка на стороне получателя почты.
|
Возможные причины |
Варианты решения |
|
Ваш IP-адрес заблокирован на стороне конечного получателя спам-фильтром, антивирусом или файрволом |
Данную проблему может решить только администратор сети получателя, исключив ваши идентификационный данные из списка блокировки или добавив их в «белый список» |
|
Неверные учетные данные ретранслятора. У вас нет разрешения на отправку электронной почты через сервер, который находится между вами и получателем |
Обратитесь к администратору данного ресурса для изменения настроек |
|
У IP отправителя нет RDNS |
Проверьте настройки получения писем и разрешения для доменов-отправителей |
Как я уже писал выше, разные почтовые серверы накладывают свои ограничения на прием и отправку сообщений. Код 571 в Google Suite расшифровывается следующим образом: «Действующая политика запрещает отправку этого сообщения». Письмо может содержать защищенные или конфиденциальные данные – номера кредитных карт и т.п. Или политика администрирования запрещает отправку определенными пользователями сообщений адресатам вне установленной группы.
Сертификат почтового сервера недействителен
Обычно с таким сообщением приходится сталкиваться пользователям, у которых настроен Microsoft Exchange Server/MS Outlook. В данной ситуации самое простое решение – обновить сертификат.
Проверка доступности почтового сервера программным методом
В данной статье описаны лишь некоторые варианты ошибок, которые могут возникнуть при отправке электронных сообщений. Полный перечень достаточно объемен и во многом зависит от настроек конкретного сервера как на стороне отправителя, так и получателя. Некоторые из ошибок могут быть легко устранены обычным пользователем, другие под силу лишь опытным администраторам.
Одним из способов предупреждения появления ошибок является онлайн-проверка доступности почтового сервера с помощью бесплатных инструментов:
- https://mxtoolbox.com
- https://www.ultratools.com
- http://mail2web.com
Эти сервисы пробуют подключиться к почтовому серверу по SMTP, подтверждают, что у него есть запись обратной зоны DNS, и замеряют время отклика. С их помощью можно диагностировать некоторые ошибки службы почтовых серверов или проверить, не занесен ли данный ресурс в черные списки из-за спама.
Прочитав эту статью, обратите внимание на то, как настроен ваш почтовый сервер на получение сторонних писем по SMTP-протоколу. Быть может, в данный момент ваш антиспам или локальная политика фильтрации входящих сообщений блокирует получение очень важного и нужного для вас месседжа? Проверьте сами или обратитесь к системному администратору. Если ошибку с SMTP никак не удается решить, то попробуйте обратиться в службу поддержки почтового сервера.