Миграция веб-сервера без влияния на почтовый сервер

Миграция веб-сервера без влияния на почтовый сервер

В настоящее время у меня есть сайт example.com, размещенный на каком-то старом провайдере. Я переношу его к другому провайдеру, услугами которого я пользуюсь.

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

Пользователи example.com получают доступ к своей электронной почте @example.com через Outlook

Я не могу переместить почтовый сервер, поэтому я подумал о том, чтобы вместо этого выставить mail.example.com с записью MX для старого, указывающей на него. Мои записи DNS выглядят примерно так, как показано ниже

example.com        14000   MX    10 mail.example.com
example.com        14000   A     123.456.789.100      (new IP)
mail.example.com   14000   A     241.123.151.900      (old IP)
mail.example.com   14000   MX    10 mail.example.com  (new record)

Пользователи могут подключаться через Outlook, используя mail.example.com; но они не хотят вносить эти изменения. Есть ли способ, которым я могу продолжать разрешать использовать example.com для доступа к электронной почте и веб-сайту.

Я ожидал, что понадобится только запись MX, но попытка подключиться с помощью example.com (без префикса почты) приводит к тайм-ауту.

Я рассмотрел кучу связанных вопросов, и все они заставляют меня думать, что настройки записи MX должно быть достаточно. Я должен добавить, что почтовый сервер находится на паршивой системе и довольно медленный. MXToolbox жаловался на то, что это занимает более 15 секунд, так что некоторые тайм-ауты могут быть связаны с этим, но если я изменю MX на example.com и старый IP, он сможет подключиться через Outlook за несколько секунд (т.е. без тайм-аута)

Редактировать:

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

Мне было поручено перенести только веб-сервер на новый хост, что было просто изменением записи A. Я не знал, что на старом хосте также работает почтовый сервер. После переезда пользователи начали жаловаться, поэтому я посмотрел другие записи и понял, что MX указывает на тот же домен (т. е. example.com). Также был CNAME для mail.example.com на example.com. Я изменил CNAME на A, указывающий на старый IP-адрес, а MX — на mail.example.com. Дал ему около 5 часов (старый TTL был 4 часа) и попробовал, как описано выше. В конце концов, мне пришлось все вернуть, так как пользователи продолжали жаловаться, что это не работает.

Все предыдущие настройки электронной почты сводились к простому добавлению записи MX для сервера -> почтового сервера и предоставлению людям возможности настраивать доступ напрямую через почтовый сервер... (Пример: mysite.com использует Gmail в качестве веб-сервера, пользователи подключаются через imap.gmail.com и smtp.gmail.com). Вот почему у меня возникли сомнения, можно ли это сделать.

решение1

Только контроль записей MXодинвещь: входящая доставка с других доменов (т. е. почтовый обмен). Они не влияют на то, где клиентские приложения, такие как Outlook, будут подключаться к SMTP-серверам, и, более того, они абсолютно не влияют на то, где приложения будут искать IMAP- или POP-серверы.

Так что если кто-то ввел "example.com" в качестве своего сервера IMAP в Outlook, то Outlook будет продолжать пытаться подключиться к "example.com", пока он не попытается вручную изменить его. С этим ничего нельзя поделать, кроме как сообщить своим пользователям, что с этого момента им придется использовать "imap.example.com".

(SRV был бы эквивалентом записей MX для «клиентского SMTP/IMAP/POP», но очень немногие приложения запрашивают записи SRV, и даже те, которые это делают, обычно делают это только один раз во время настройки. Outlook вообще не поддерживает записи SRV.)

В краткосрочной перспективе вы можете настроить TCP-ретранслятор/прокси-сервер со старого сервера на новый, но вряд ли вам захочется использовать его в течение длительного времени.

Связанный контент