Коротка відповідь
Пошта на домені (наприклад, info@вашдомен.com) технічно не пов'язана з тим, де фізично розміщений сайт — вона керується окремим типом DNS-запису (MX), і саме тому переносити сайт і пошту потрібно узгоджено, а не сподіватись, що «все саме переїде разом».
Чому пошта — окрема система
Домен має кілька типів DNS-записів для різних цілей: A-запис вказує, де знаходиться сайт, MX-запис вказує, який сервер приймає пошту для цього домену. Це можуть бути (і часто є) різні сервери. Наприклад, сайт може бути на хостингу, а пошта — на Google Workspace чи іншому окремому поштовому сервісі. Загальний принцип роботи DNS і A-записів розібраний у статті як спрямувати домен на хостинг — там же коротко про MX.
Сценарій 1: пошта лишається на старому хостингу
Якщо плануєте перенести тільки сайт, а поштові скриньки залишити на попередньому провайдері, — головне не чіпати MX-записи при зміні A-запису на новий сервер. Це технічно можливо: A-запис веде на новий сервер сайту, MX-запис і надалі веде на старий сервер пошти. Важливо явно попередити нового провайдера, що змінювати потрібно тільки A-запис.
Сценарій 2: пошта переїжджає разом із сайтом
Якщо переносите і сайт, і пошту на Meridaro, порядок дій такий:
- Створити поштові скриньки на новому сервері заздалегідь, з тими самими адресами, що на старому.
- Перевірити, чи потрібно вручну перенести вже наявні листи (через IMAP-синхронізацію чи експорт/імпорт), якщо важлива історія переписки.
- Тільки після готовності поштових скриньок на новому сервері — змінити MX-записи в DNS.
- Не вимикати поштові скриньки на старому сервері одразу — лишити доступними ще кілька днів, поки MX-записи повністю не оновляться у всьому світі.
Чому передчасне вимкнення старої пошти небезпечне
Оновлення DNS-записів (включно з MX) відбувається не миттєво для всього інтернету — різні поштові сервери у світі можуть кешувати старий запис від кількох годин до 1-2 діб. Якщо вимкнути стару поштову скриньку одразу після зміни MX, листи, надіслані з серверів зі «старим» кешем DNS, ризикують не дійти — вони підуть за адресою, якої вже немає.
Безпечний інтервал: тримати стару пошту доступною мінімум 48-72 години після зміни MX-записів, навіть якщо здається, що все вже працює на новому сервері.
Як перевірити, що нова пошта працює до повного перемикання
Створіть на новому сервері тестову скриньку й надішліть на неї лист із зовнішньої адреси (Gmail тощо) ще до зміни основних MX-записів — це підтверджує, що нова поштова система технічно готова приймати пошту, перш ніж переключати весь домен.
Типові помилки при переносі пошти
- Забули створити скриньки на новому сервері заздалегідь — MX вже змінили, а скриньки ще не готові, листи губляться.
- Не перенесли SPF-запис — це може призвести до того, що легітимні листи з домену почнуть потрапляти у спам у отримувачів.
- Вимкнули стару пошту одразу — втрата листів через затримку кешування DNS у світі, як описано вище.
- Не попередили команду — співробітники продовжують налаштовувати поштового клієнта зі старими даними сервера вхідної/вихідної пошти.
Якщо переносите разом із сайтом на CMS
Загальний порядок дій для сайту (не тільки пошти) — файли, база, перевірка через технічну адресу, і тільки потім DNS — детально в статті перенести WordPress на новий хостинг: покроково. Пошту варто планувати як окремий, паралельний трек цього ж перенесення, а не додаток «між іншим».
Налаштування поштового клієнта на новому сервері
Після створення скриньок на новому сервері співробітникам потрібно оновити налаштування поштового клієнта (Outlook, Thunderbird, поштова програма на телефоні) — адреси серверів вхідної (IMAP/POP3) і вихідної (SMTP) пошти майже завжди відрізняються між провайдерами хостингу. Варто підготувати коротку інструкцію з новими параметрами й розіслати команді заздалегідь, до фактичної зміни MX-записів, щоб перехід не застав нікого зненацька в понеділок вранці.
DKIM і DMARC: додатковий рівень довіри до пошти з домену
Крім SPF, сучасна поштова гігієна включає записи DKIM (цифровий підпис листів, що підтверджує їх автентичність) і DMARC (політика, яка каже поштовим серверам отримувачів, що робити з листами, які не пройшли перевірку SPF/DKIM). Якщо на старому хостингу ці записи були налаштовані, а на новому — ні, це може погіршити доставлюваність пошти навіть без прямих помилок: листи не "губляться" повністю, але частіше потрапляють у спам. Варто звірити наявність цих записів до і після перенесення, а не тільки сам факт роботи пошти.
Тестовий період паралельної роботи двох поштових систем
Для критично важливих поштових адрес (наприклад, головна адреса для прийому замовлень) має сенс на кілька днів налаштувати паралельний прийом на обох серверах — старому й новому, — а не покладатися виключно на точність і швидкість оновлення MX-записів у всьому світі. Це трохи складніше організаційно, зате повністю виключає ризик втрати важливих листів у перехідний період, коли частина інтернету ще бачить старі DNS-записи, а частина вже нові.
Автовідповідач і переадресація: не забути перенести й це
Крім самих скриньок, варто звірити додаткові налаштування пошти, які легко забути: автовідповідачі ("Я у відпустці"), правила переадресації на інші адреси, підписи компанії, налаштовані централізовано. Ці деталі не критичні для базової працездатності пошти, але їх відсутність після перенесення помічають не одразу — і зазвичай саме в незручний момент, коли клієнт скаржиться, що лист без відповіді, хоча відповідальний співробітник у відпустці й розраховував на автовідповідач.
Кількість поштових скриньок і ліміти тарифу
Різні тарифи хостингу можуть мати різні ліміти на кількість поштових скриньок чи обсяг поштового сховища. Перед перенесенням варто звірити, скільки скриньок реально використовується на старому сервері (включно з тими, про які могли забути — наприклад, для окремих співробітників, що вже не працюють), і переконатись, що обраний тариф на новому хостингу покриває цю кількість із запасом.
Чек-лист перенесення пошти в одному місці
- Скласти повний список поточних поштових скриньок і перевірити, які з них дійсно активні.
- Створити ідентичні скриньки на новому сервері заздалегідь.
- Перенести чи налаштувати заново SPF, DKIM і DMARC записи.
- Надіслати тестовий лист на нову скриньку із зовнішньої адреси до зміни MX.
- Підготувати й розіслати команді нові параметри поштового клієнта.
- Перенести автовідповідачі й правила переадресації.
- Змінити MX-записи і тримати стару пошту доступною ще 48-72 години.
Виконаний по порядку, цей список перетворює потенційно нервовий процес на послідовність зрозумілих кроків, кожен з яких можна перевірити окремо.