Изменение хостов, приводящих к 554 5.7.1 <xxx@domain.tld>: Релейный доступ запрещен

У меня есть проблема с переключением моего проекта от hoster к hoster B. Существует три стороны involed: старый hoster, новый hoster и NetworkSolutions как регистратор.

У меня есть .com и и Домен.NET. Обоим установили Серверы имен от старого Hoster A. Я изменил это больше чем 24 часа назад и должен теперь полностью управлять установкой записей DNS. .com-домен работает правильно, Домен.NET не.

У обоих есть те же записи DNS. Однако, когда я посылаю электронное письмо от Gmail новые ответы почтового сервера с 554 5.7.1: Релейная ошибка доступа запрещен. Когда я отправляю почту от нового почтового сервера (с .com-учетной-записью), почта заканчивается в старом почтовом сервере. Однако TTL старого MX и A-записей истек, и новый почтовый сервер, кажется, не замечает его.

Я не понимаю эту ошибку, поскольку это - стандартный почтовый сервер, обеспеченный hoster. Интересно, существует ли что-то, что я настроил неправильно с DNS zonefile или является ли это проблемой с mailserver конфигурацией или должен ли старый hoster изменить его серверы имен с доменом.

enter image description here

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

Что я сделал до сих пор: - удостоверенный файл Зоны DNS составляет 100% то же, как рабочий домен имеет - Проверенный, что проблема не только с Google: https://www.ultratools.com/tools/emailTestResult - Пониженный TTL на все мои настройки вчера для обеспечения быстрого распространения

ОБНОВЛЕНИЕ:

Когда я выполняю сценарий PHP, он разрешает хост "mail.domain.tld" старого mailservers IP. domain.tld решит правильно к новому IP. Таким образом, это ДЕЙСТВИТЕЛЬНО использует новые серверы имен, и все же это разрешает запись MX неправильным способом. Это может вызвать релейную проблему?

2
задан 7 April 2015 в 01:10
1 ответ

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

Если DNS верен (запись MX указывает на правильный адрес нового почтового сервера хоста), это означает, что домен / почтовые ящики не настроены на сервере нового хостера.

Если новый хост утверждает, что почтовые ящики / домен настроены правильно, то DNS указывает на неправильный сервер.

Обе эти возможности, вероятно, могут быть исправлены с быстрым звонком в службу поддержки нового хостера.

2
ответ дан 3 December 2019 в 11:38

Теги

Похожие вопросы