Потребность переместить услугу хостинга без времени простоя почтового сервиса

EDIT: Перемещение веб-хостинга вашего клиента не имеет никакого отношения к его электронной почте. До тех пор, пока место назначения записи MX не изменится, ничего не случится с доставкой их электронной почты.

Просто измените запись А для их веб-сайта. Хорошей практикой является уменьшение TTL на записях, как описано в других сообщениях или в моем оригинальном ответе.

Если они также перемещают DNS, то этот вопрос уже был задан и на него был дан ответ. Могут возникнуть проблемы, если это период, когда ни новый, ни старый DNS не работает. В противном случае все может пройти гладко.

ОРИГИНАЛЬНОЕ: поддерживайте старую службу до истечения срока действия старых записей MX. После запуска новой службы, GMail может быть настроена на пересылку любой новой почты в новые службы.

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

Как только электронная почта перестанет поступать в 'GMail', он может удалить эту учетную запись.

Электронная почта может быть потеряна, если вы неправильно укажете новый адрес назначения. Для легитимной почты, отправленной на адрес, который не отвечает, скорее всего, будет потерян только спам. Если вы неправильно укажете адрес несвязанного почтового сервера, то возможно, что они правильно откажут письмо.

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

Не будет никакого "простоя". Что вам нужно будет сделать, так это подумать о том, как вы собираетесь синхронизировать всю почту. Это всегда можно сделать после.

Для начала я настоятельно рекомендую оплатить услуги DNS-провайдера третьей стороны, не зависящего от каких-либо услуг хостинга/электронной почты/внутренней сети; обычно я использую их и для регистратора доменов, поскольку удобно обновлять и то, и другое одновременно, и обычно есть скидка за то, что они оба есть.

Это будет стоить дороже (~$25-50 USD в год, что на самом деле ничего не значит для любого законного бизнеса, и я бы ушел от такого клиента, если бы такие деньги были проблемой), но это дает вам роскошь:

a) иметь полный контроль над вашей зоной DNS с помощью обычно (не всегда) лучшей поддержки и доступности/гео-ресурсации;

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

Вернитесь к своему сценарию: убедитесь, что вы можете изменить свою зону заранее у нового поставщика услуг NS (DNS). Если вы обрежете NS-записи в пустой файл зоны, у вас возникнут сбои по очевидным причинам.

No-IP.com позволяет вам войти/изменить зону до передачи домена и/или изменения NS. Я подозреваю, что EasyDNS и другие подобные службы будут делать то же самое; я не использовал их, но у меня есть коллеги, которые хорошо о них отзываются.