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

Описание

Ретрансляция происходит, когда почтовое сообщение отправлено на адрес электронной почты, домен которого (имя после символа @, например adatum.com) не обрабатывается протоколом SMTP или сервером исходящей почты, получающим от отправителя запрос на доставку сообщения. SMTP-серверу необходимо подключиться к другому SMTP-серверу, чтобы ретранслировать сообщение.

Если при отправке почтового сообщения возникает ошибка ретрансляции, ваш SMTP-сервер (исходящей почты) может вернуть ваше сообщение вместе с сообщением об ошибке, например, такого вида:

Тема: <тест>, учетная запись: <тест>, сервер: , протокол: SMTP, ответ сервера: "550 Ретрансляция запрещена", порт: 25, защита (SSL): нет, ошибка сервера: 550, номер ошибки: 0x800CCC79".

"Не удается отправить сообщение, поскольку сервер отказался принять адрес одного из получателей. В письме был указан адрес: <адрес эл. почты>. Тема: <тест>, учетная запись: <тест>, сервер: , протокол: SMTP, ответ сервера: "553 к сожалению, этого домена нет в моем списке разрешенных узлов (#5.7.1)", порт: 25, защита (SSL): нет, ошибка сервера: 553, номер ошибки: 0x800CCC79".

Точный текст сообщения об ошибке будет зависеть от вашего поставщика интернет-услуг. Некоторые поставщики не возвращают сообщение об ошибке, когда определяют исходящие сообщения как нежелательную рекламу. В этих случаях все выглядит так, как будто ваше сообщение отправляется в обычном режиме (в Outlook остается в папке Исходящие и появляется в папке Отправленные ), но получателю оно не доставляется.

Ваше сообщение отклонено, поскольку SMTP-сервер (исходящей почты) не распознал вас как полномочного пользователя.

SMTP - это протокол (стандарты, используемые компьютерами для взаимодействия), который используется на большинстве серверов электронной почты для отправки сообщений в Интернете. Если вы используете почтовую программу (например, Outlook), которая позволяет хранить сообщения на компьютере, вам необходим доступ к SMTP-серверу для отправки сообщений.

Примечание: Веб-системы электронной почты (например, Windows Live Mail или Yahoo! Mail) работают иначе и не рассматриваются в этой статье.

Нежелательная почта и открытые ретрансляции

Рекламные сообщения, распространяемые без запроса, называют нежелательной почтой или спамом. Объем нежелательной почты продолжает расти, потому что ее отправка практически ничего не стоит тем, кто ее рассылает. Фактически отправителю даже не обязательно отправлять нежелательную почту через SMTP-сервер (исходящей почты) своего поставщика интернет-услуг.

При создании базовой структуры Интернета никто не предвидел, к каким последствиям приведет возможность отправлять миллионы нежелательных сообщений за ничтожно малую плату. Благодаря способности 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 .	Нет. Ваша почта обрабатывается обычным способом.
Вы остановились в гостинице или воспользовались в аэропорту интернет-терминалом, предоставляющим доступ в Интернет. У вас есть домашняя учетная запись поставщика интернет-услуг, оканчивающаяся на @proseware.com , с которой вы подключаетесь по телефонной линии, с помощью кабеля или через DSL-модем. В Outlook у вас настроены те же параметры SMTP-сервера, что и дома. Вы отправляете сообщение другому человеку, почтовый адрес которого тоже оканчивается на @proseware.com .	Нет. Ваша почта обрабатывается обычным способом.
То же, что и в предыдущей ситуации, только вы отправляете сообщение человеку, почтовый адрес которого оканчивается на @adatum.com .	Да, и это сообщение может быть заблокировано как ретранслируемая почта. Вы пытаетесь использовать домашний SMTP-сервер (исходящей почты) своего поставщика интернет-услуг, хотя не подключены к его сети. SMTP-сервер не может удостоверить вас как полномочного подписчика поставщика интернет-услуг. Кроме того, вы просите SMTP-сервер принять сообщение и подключиться к другому SMTP-серверу, чтобы доставить его в почтовый ящик получателя.

Решения

Если ваша ситуация рассматривается как ретрансляция, вы должны отправить сообщение через сервер, к которому сейчас подключаетесь. То есть, если вы на работе или вне дома и не используете своего поставщика интернет-услуг для подключения к Интернету, но хотите отправить сообщение из своей домашней учетной записи, предоставленной этим поставщиком, вам нужно изменить параметры почтовой учетной записи, указав тот SMTP-сервер, который вы используете там, где находитесь (например, рабочий SMTP-сервер). Пошаговые инструкции см. в статье .

Если это не работает или вы предпочитаете использовать домашнюю учетную запись, вам нужно связаться со своим поставщиком интернет-услуг и спросить, доступны ли вам описанные ранее параметры. Что касается первых двух ограничений (требуется проверка подлинности SMTP и требуется сначала подключение к POP3-серверу входящей почты поставщика интернет-услуг), вы можете внести изменения в Параметры учетной записи в Outlook. Инструкции см. в статье Изменение параметров учетной записи электронной почты .

Сообщения по-прежнему не отправляются?

Вы изменили параметры SMTP в Outlook или нашли параметр, который разрешит вам отправлять почтовые сообщения. Но вы по-прежнему не можете отправить почту и получаете сообщение об ошибке.

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

В Outlook, как и в большинстве почтовых программ, можно указать "отображаемое имя" и обратный почтовый адрес, который появляется при ответе на ваше сообщение. В нежелательной почте эти поля почти всегда содержат ложную информацию. Вы правда верите, что сообщения о том, как быстро разбогатеть, пришли от супермодели или мирового лидера?

Чтобы предотвратить спуфинг удостоверений, некоторые поставщики интернет-услуг ограничивают возможность вставки ложной информации в поле адреса в ответах. Например, если доменное имя вашего поставщика интернет-услуг оканчивается на proseware.com, поставщик может запретить вам указывать обратный адрес [email protected] . Это ограничение используется не так широко, как описанные ранее, но может применяться ко всем пользователям независимо от их местонахождения и способа подключения. В этом случае альтернативы нет. Если администратор сервера использует этот способ, вы должны указывать в обратном адресе домен, соответствующий вашему текущему подключению.

Примеры писем:

550 5.7.1 This message was not accepted due to domain owner DMARC policy (RFC 7489) https://help.mail.ru/mail-help/postmaster/dmarc

550-5.7.1 Unauthenticated email from mail.ru is not accepted due to domain"s 550-5.7.1 DMARC policy. Please contact administrator of mail.ru domain if this 550-5.7.1 was a legitimate mail. Please visit 550-5.7.1 https://support.google.com/mail/answer/2451690 to learn about DMARC

550 5.7.1 Email rejected per DMARC policy for ...

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

DMARC — это протокол защиты от спама и от несанкционированной рассылки почты от имени домена, основанный на существующих механизмах DKIM и SPF . Официальный сайт: dmarc.org .

Если вы получаете подобные приведённым выше сообщения, скорее всего, почта с сайта у вас отправляется от имени почтового ящика на базе @mail.ru , @bk.ru , @list.ru или @inbox.ru . Mail.Ru не принимает сообщения, отправленные через phpmail, если в почтовых заголовках числится ящик, принадлежащий mail.ru. Такие сообщения, согласно внедрённой Mail.Ru политике DMARC , отклоняются.

Как решить проблему

Решить проблему можно двумя способами:

Способ 1: изменить ящик, с которого отправляются сообщения

Обычно e-mail, от имени которого рассылаются почтовые сообщения, прописывается в административной части CMS. Также его можно изменить напрямую в скрипте, рассылающем сообщения (поле «From»).

Необходимо, чтобы сообщения рассылались с ящика на базе вашего доменного имени, например «[email protected]» , где domain.ru — ваш домен. .

Также, почтовый ящик необходимо изменить в файле php.ini :

Изменение ящика в php.ini

1. 1 войдите в панель управления хостингом и откройте на редактирование файл php.ini : ;
2. 2

   найдите строку вида:
   

   sendmail_path = "/usr/sbin/sendmail -t -i -f [email protected]"

   В данной строке вместо «[email protected]» укажите почтовый ящик, не относящийся к доменам @mail.ru , @bk.ru , @list.ru и @inbox.ru .
   Желательно указать почтовый ящик на вашем домене, например, «[email protected]» , где domain.ru — ваш домен.

   Кроме этого, прописанный в php.ini почтовый ящик должен существовать. Если вы пользуетесь почтой на хостинге, создайте почтовый ящик на домене по и пропишите его в файле php.ini .

Способ 2: использовать SMTP-авторизацию

Вы можете рассылать сообщения от имени вашего почтового ящика на базе Mail.Ru, настроив SMTP-авторизацию. В этом случае все сообщения через ваш сайт будут отправлять напрямую с серверов Mail.Ru.

Настройка отправки писем без их попадания в спам.

Вариант с отправкой писем через сторонние SMTP-серверы (Mandrill, Mailgun, Яндекс) и через личные адреса почтовых сервисов рассматривать не буду (там все очень просто, если следовать предоставляемым инструкциям по установке) - рассмотрю лишь вариант, что у нас есть свой сервер, на котором установлен соответственно почтовый сервер, например exim (как у большинства хостеров).

Нам потребуется доступ к редактированию DNS-записей и минимальное владение консолью для настройки DKIM (если есть ISPmanager - и этот пункт становится неактуальным). Всего потребуется настроить (добавить) 4 новые записи в DNS-записи вашего домена: PTR , SPF , DKIM и DMARC .

• PTR - так называемая "обратная" DNS-запись. Должна быть обязательно, поскольку очень большое число почтовых сервисов к ее некорректному указанию нетерпимо. По-идее она должна устанавливаться вашим хостером, например DigitalOcean делает это автоматически. - но есть вариант и ее ручной настройки.
• SPF - запись, в которой указано, что вашему серверу разрешено отправлять письма с этого домена и IP. Нет этой записи - попадание в спам практически гарантировано. Установка очень простая - исчерпывающую информацию с примерами по настройке можно получить на (информация в зеленой табличке), либо на .
• DKIM - электронная подпись ваших писем. При наличии двух предыдущих записей - придает вашему домену и письма с него "вес", благодаря чему тот же Яндекс, например, помечает письма приятной зеленой галочкой.

Настройка этой подписи, пожалуй, самая сложная - как последствие, у 90% сайтов ее нет, но крайне рекомендуется. Очень просто настроить ее в ISPmanager: включаете поддержку DKIM на вкладке возможностей, в редактировании почтового домена ставите галочку DKIM и забираете уже готовую запись в свойствах домена (NS). Если ISPmanager нет, советую воспользоваться этой, достаточно простой статьей: .

• DMARC - стандарт совершенно новый, но уже активно почтовыми сервисами внедряется и в этом году уже 100%-ый must have. Настройка самая простая из всех выше перечисленных записей, вам нужно лишь добавить один из примеров, указанных на этой странице снизу: - советую второй.

Сервер у вас теперь настроен и если все сделано верно - ни одно письмо в спам уже не уйдет. Для примера, подтверждающий скриншот с почтового офиса mail.ru (аналогичная ситуация с полным отсутствием определения писем как спам и по Яндексу):

Настройка сборщика возвратной почты.

В XenForo есть совершенно потрясающий механизм, который практически никем не используется - сборщик возвратной почты (bounce email). Думаю каждый встречался с ситуацией, что после совершения массовой рассылки на почтовый ящик приходит большое число писем следующего вида:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

***@rambler.ru
SMTP error from remote mail server after RCPT TO:<***@rambler.ru>:
host imx1.rambler.ru : 540 5.7.1 <***@rambler.ru>:
Recipient address rejected: Your emails has been returned because the intented recipient"s email account has been suspended. The account must be re-activated to receive incoming messages.

Эти письма являются сигналом того, что у ваших пользователей устарели их адреса электронной почты (ящики заблокированы, удалены, переполнены), а значит новые письма они от вас не получат и в случае необходимости аккаунт на форуме также восстановить не смогут. Многие пользователи о том, что у них используется устаревший адрес электронной почты даже не знают, а почтовые сервисы, видя большое число отправок писем на несуществующие адреса, могут банально внести ваш домен в спам-лист .

С этим нужно бороться, потому что даже на моем форуме, где эта система работает уже не первую рассылку, "возвращенных" писем очень много, в сравнении с числом пользователей:

• Для начала, создаем почтовый адрес, на который будем посылать возвращенные письма (ящик системный и ни для каких других целей использоваться не должен) - например , где google.com - ваш домен.

• Заходим в раздел админки Настройки - Настройки электронной почты . В поле адрес для возврата писем указываем созданный вами почтовый ящик. Ставим галочку автоматической обработки недоставленных писем и указываем данные для захода на ваш служебный почтовый ящик, которые вы создали ранее: адрес (в случае собственного SMTP-сервера - свой и указывайте), логин (адрес, который вы создали) и пароль от ящика. Приведу пример своих настроек - у меня бизнес-почта от Mail.ru - следовательно к их серверу для получения почты со служебного ящика я и подключаюсь

В принципе, это вся настройка. Форум автоматически с определенными интервалами будет заходить на указанный вами служебный почтовый ящик, скачивать копии возвращенных писем, которые на него поступили и удалять их оттуда. В разделе Инструменты - Журнал отказов в доставке писем вы эту статистику сможете просмотреть. Особо подчеркиваю, что ни для каких других целей этот ящик использовать нельзя, а то рискуете получить несколько достаточно забавных багов в логах админки.

Согласно заданным вами условиям, при возврате, к примеру, 3 писем с одного адреса, пользователь будет отправляться на автоматическую реактивацию - ему будет предложено указать актуальный адрес электронной почты и заново активировать аккаунт. Какое либо ваше участие при этом не требуется - пользователи будут сами указывать свои актуальные адреса электронной почты, а следовательно проблема уйдет со временем. А при рассылках, пользователей с некорректным адресом электронной почты можно будет исключить из нее - тем самым избежав возможного попадания в спам листы.

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

Для некоторого упрощения части задач, описанных выше, можно использовать либо - что вам больше нравится. Я использую первый - но выбор полностью за вами. Добавление ваших доменов туда даст удобные, неограниченные по размеру почтовые ящики с уже встроенными спам-фильтрами + некоторое упрощение настройки сервера (часть записей будет предоставлена автоматически (за исключением DKIM, которую для отправки почты со своего сервера надо генерировать вручную так или иначе)).

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

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

Проблема с отправкой сообщений с сайта

Пожалуйста, убедитесь, что вы точно выполняете все советы статьи .

Самое важное:

1) Обратный адрес письма должен быть зарегистрированным ящиком на нашем хостинге!
2) Массовые рассылки запрещены, по умолчанию, с сайта можно отправить до 500 писем в день.
3) Письмо должно соответствовать почтовым стандартам. Ваш скрипт самостоятельно формирует письмо и если оно получилось не очень качественным, оно будет принято нашим сервером, но его доставка не произойдет, т.к. его задержат фильтры нашей системы или у получателя.

Проблема с отправкой сообщений от человека

Ситуация 1

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

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

Ситуация 2

Письмо присутствует в списке сообщений в очереди.
Необходимо открыть «статистика доставки почты», «SMTP доставка».

Ситуация 2.1

Письмо присутствует в списке SMTP доставки.
Для одного сообщения может присутствовать несколько попыток доставки. Предварительные попытки могут быть неудачными, это нормально. Необходимо найти последний блок (строку), который имеет отношение к доставке вашего сообщения.

Ситуация 2.1.1

Блок «лог доставки» оканчивается сообщением 250 OK или любым другим сообщением, которое начинается с кода 250 (кроме последней строки «Connection closed normally» - её учитывать не нужно).
Это означает, что следующий в цепочке доставки почтовый сервер принял письмо и подтвердил факт получения сообщения. Все последующие вопросы о судьбе сообщения необходимо направлять администратору этого почтового сервера. Информация из блока «лог доставки», одновременно с датой и временем, поможет администратору понять судьбу сообщения и при необходимости устранить проблему.

Ситуация 2.1.2

Блок «лог доставки» оканчивается сообщением, которое начинается кодом, отличным от 250, либо сопровождается сообщением «Processing of job XXXXXXX incomplete or failed».
Это означает, что наш почтовый сервер не смог доставить сообщение адресату. При этом вы должны получить сообщение о недоставке почтового сообщения («возврат»). Дополнительная информация доступна из лога SMTP доставки, которую вы сейчас просматриваете.

• Сообщение может быть отклонено сервером получателя из-за некорректной фильтрации спама. Ответственность за возврат письма лежит на администраторе сервера, почтовый сервер которого принял решение о том, что письмо является спамом. Спам с адресов нашего почтового сервера не рассылается, поэтому решение об отклонении письма на основании IP адреса или иных формальных признаков является заведомо ошибочным.
  Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Необходимо обратиться к администратору принимающего сервера.
  Примеры сообщений о том, что почтовый сервер адресата отклонил сообщение по подозрению в спаме:
• 591 your host is blacklisted
• 450 5.7.1 ... Mail from a.b.c.d refused - see http://spamcop.net ...
• 553 5.3.0 Spam blocked see: http://spamcop.net/ ...
• 550 5.7.0 Your server IP address is in the SpamCop database, bye
• 554 Service unavailable; Sender address blocked using list.dsbl.org
• 550-Message rejected because … (…)
• 591 your host is blacklisted, see ...
• Сообщение с кодом 4xx или 5xx, упоминающее слова spam, blocked, Spamcop, Spamhaus, RBL, SBL, XBL, SPEWS, policy analysis, denied, или аналогичные.
• Сообщение может быть отклонено сервером получателя в том случае, если адресат на сервере отсутствует, т.е. по причине ошибки адреса.
  Уточните адрес до символа @.
  Расследовать данную проблему с нашей стороны нет смысла, т.к. цитируется ответ принимающего сервера. Если вы считаете, что адрес точен, то необходимо обратиться к администратору принимающего сервера для уточнения причины отказа принять письмо.
  Примеры сообщений об отсутствующем адресе:
• 550 , Recipient unknown
• 553 We do not relay without RFC2554 authentication
• 550 Message was not accepted -- invalid mailbox
• 554 … This account has been disabled or discontinued
• Сообщение об ошибке в почтовом адресе после символа @. Уточните почтовый адрес, а также то, что домен получателя активен и работает.
  
  Примеры сообщения об ошибке после @:
• Temporary error XXX (temporary MX resolution error) resolving "aaa.bb"
• Техническая ошибка при отправке сообщения. Вы можете попытаться отправить письмо повторно, либо уточнить у получателя, нормально ли работает его сервер электронной почты.
  Вы можете обратиться к службе поддержки с просьбой прокомментировать ситуацию точнее.
  Примеры сообщений о технических ошибках:
• Error connecting to primary server "a.b.c.d"
• Error connecting to alternate server " a.b.c.d"

Ситуация 2.2

Письмо отсутствует в списке SMTP доставки. Обратитесь в службу поддержки.

Проблема с получением сообщений

Вам необходимо зайти в личный кабинет, выбрать «статистика доставки почты», «очередь сообщений» для нужного вам ящика.
ВАЖНО: расследовать проблему такого вида можно только для сообщений, которые были доставлены в ящик непосредственно, без участия списка рассылки либо спам-фильтра. Если ваш ящик получает сообщение косвенным образом (через список рассылки), вам необходимо расследовать проблему для ящика, который является основным ящиком списка рассылки. Если включен спам-фильтр - его необходимо выключить.

Ситуация 3

Сообщение присутствует в списке.
Это означает, что сообщение было принято сервером и размещено в ваш почтовый ящик. Проблемы с получением такого письма связаны с вашей системой либо её настройками.

• Проверьте настройки системы фильтрации спама («полный список функций», «фильтрация нежелательных сообщений»). Если спам-фильтр включен, письмо могло быть перемещено либо отклонено (в зависимости от ваших настроек). Письмо также могло быть уничтожено вне зависимости от настроек, если содержало вирус.
  Следует попробовать отключить фильтрацию почты либо проверить все ящики, куда могло быть перемещено письмо, если выбран такой режим.
• Ваша почтовая система может вообще не принимать почту с нашего сервера. Для уточнения этого случая посмотрите содержимое вашего почтового ящика через веб-доступ к почте, см. ссылку напротив нужного ящика на странице «пароли на ресурсы» личного кабинета.
• Иногда почтовая система компьютера или организации принимает сообщение, а затем по какой-то причине удаляет его с сервера, никуда далее не передав и не сохранив. Вам необходимо обратиться к администратору вашей почтовой системы для расследования проблем такого типа.
  Расследовать данную проблему с нашей стороны нет смысла, т.к. письмо было размещено в ваш ящик и могло быть удалено из него только с помощью команд с вашего компьютера с помощью протокола POP3 или IMAP.

Ситуация 4

Сообщение отсутствует в списке.
Это означает, что наш почтовый сервер не принимал сообщение.
Расследовать данную проблему с нашей стороны нет смысла. Это представляет собой проблему нашей почтовой системы только в том случае, если есть доказательства того, что сообщение было доставлено на наш сервер. Доказательством служит кусок лога SMTP клиента отправляющего сервера (случай, зеркально аналогичный ситуации 2.2.1 выше). Если такого доказательства нет, значит, расследовать данный случай недоставки должен администратор почтового сервера отправляющей стороны.

Также можно попробовать учесть различные обстоятельства работы вашего домена, которые могут привести к тому, что доставка почты на него вообще работать не будет.

• Убедитесь, что домен активен (DELEGATED), что DNS сервера соответствуют DNS серверам сайт (ns1.сайт, ns2.сайт).
• Если домен обслуживается другими DNS серверами, убедитесь, что MX запись домена показывает на наш почтовый сервер (если не сообщено иначе, это должен быть mail.сайт).
• Если домен обслуживается нашими DNS серверами, зайдите в «полный список функций», «редактор DNS зон», выберите домен, убедитесь, что стоит галка «1Gb..
• Убедитесь, что домен зарегистрирован более 3х дней назад.