Перенесення сайту на інший хостинг часто сприймають як звичайне копіювання файлів і бази даних. Однак корпоративна пошта може працювати за окремими правилами: її скриньки, архіви, DNS-записи та налаштування захисту не завжди переносяться разом із сайтом.
Помилка під час міграції здатна призвести до втрати доступу до листування, недоставлених повідомлень або потрапляння важливих листів у спам. Тому пошту потрібно планувати як окрему частину перенесення, а не залишати на завершальний етап.
Поштові скриньки та архіви
Перший крок — скласти повний перелік поштових скриньок, псевдонімів, переадресацій і службових адрес. Варто перевірити не лише очевидні адреси на кшталт info@ або sales@, а й технічні скриньки, через які сайт надсилає повідомлення з форм, інтернет-магазину чи CRM.
- зафіксуйте всі активні скриньки та їхні обсяги;
- перевірте, де фактично зберігаються листи — на старому хостингу, поштовому сервісі чи локальних пристроях;
- визначте, які листи потрібно перенести, а які можна залишити в архіві;
- перевірте налаштування переадресацій, автовідповідачів, фільтрів і спільного доступу;
- заздалегідь збережіть важливі листи та контакти в окрему резервну копію.
Не варто видаляти старі скриньки або змінювати їхню конфігурацію до завершення перевірки. Якщо поштовий сервіс і хостинг належать різним провайдерам, перенесення сайту може взагалі не вимагати перенесення самої пошти — достатньо правильно зберегти DNS-налаштування.
Якщо доступ до панелей керування вже втрачено, спочатку потрібно відновити контроль над обліковими записами та доменом. У такій ситуації корисно ознайомитися з матеріалом Що робити, якщо втрачено доступ до домену та хостингу, а вже потім планувати міграцію.
MX, SPF, DKIM і DMARC
Поштова доставка залежить не тільки від наявності скриньок. Домен має повідомляти іншим поштовим серверам, куди доставляти листи та які сервери мають право їх надсилати. Для цього використовуються DNS-записи.
- MX визначає поштові сервери, що приймають вхідну пошту для домену;
- SPF містить перелік серверів, яким дозволено надсилати листи від імені домену;
- DKIM додає до листів криптографічний підпис для перевірки їхньої справжності;
- DMARC задає політику перевірки SPF і DKIM та правила обробки підозрілих повідомлень.
Під час зміни хостингу особливо часто помилково замінюють усю DNS-зону записами з нового сервера. У результаті сайт може відкритися, але пошта перестане приймати або надсилати листи. Перед змінами потрібно зберегти поточну DNS-зону та окремо перевірити записи MX, TXT і пов’язані з ними піддомени.
Якщо змінюється поштовий провайдер, його інструкції можуть вимагати нові значення SPF, DKIM і DMARC. Не можна механічно додавати кілька SPF-записів: для домену має використовуватися коректна єдина політика SPF. Також важливо не вмикати жорстку політику DMARC до завершення тестів, якщо джерела відправлення ще не перевірені. Інакше легітимні листи сайту, бухгалтерських систем або CRM можуть блокуватися.
Міграція листів
Є кілька способів перенесення пошти: імпорт через панель нового провайдера, синхронізація за IMAP або експорт та імпорт окремих скриньок. Вибір залежить від обсягу архівів, підтримки протоколів, кількості користувачів і можливостей старого сервера.
- Зробіть резервну копію поштових скриньок до початку робіт.
- Створіть скриньки на новому сервісі з потрібними адресами та обсягами.
- Перевірте доступ до них через вебінтерфейс або поштовий клієнт.
- Запустіть копіювання старих листів, не видаляючи оригінали.
- Порівняйте кількість папок, повідомлень і розмір архівів.
- Окремо перевірте папки «Надіслані», «Чернетки», «Спам» і власні користувацькі папки.
IMAP-міграція зазвичай переносить листи, але не завжди коректно відтворює календарі, контакти, правила сортування, підписи та делегований доступ. Частина даних може зберігатися локально в Outlook або іншій програмі й не бути присутньою на сервері.
До зміни MX-записів потрібно врахувати перехідний період: частина серверів ще може доставляти листи за старими DNS-даними. Не видаляйте стару поштову інфраструктуру відразу. Якщо це можливо, залиште її доступною на час поширення DNS-змін і перевірки доставки.
Небезпечними є дії, що передбачають масове видалення скриньок, очищення старого сервера або перезапис локальних архівів. Без резервної копії вони можуть призвести до незворотної втрати листування.
Перевірка доставки
Після перенесення не обмежуйтеся перевіркою входу до вебпошти. Потрібно протестувати повний ланцюжок: відправлення та отримання листів усередині домену, обмін із зовнішніми адресами та автоматичні повідомлення із сайту.
- надішліть лист із кожної ключової скриньки на зовнішні адреси різних поштових сервісів;
- відправте відповіді назад і перевірте, чи не потрапили вони в спам;
- перевірте роботу форм зворотного зв’язку, замовлень, відновлення пароля та системних сповіщень;
- переконайтеся, що адреса відправника сайту існує на новому поштовому сервері;
- перевірте заголовки листів — результати SPF, DKIM і DMARC мають відповідати новій конфігурації;
- перевірте переадресації та автовідповідачі.
Якщо листи не приходять, причина може бути не лише в поштовій скриньці. Серед типових проблем — неправильний MX-запис, помилка в SPF, відсутній DKIM-підпис, кешування старих DNS-даних, блокування порту SMTP або некоректні параметри в CMS.
Для сайту на WordPress слід окремо перевірити спосіб відправлення пошти. Функція mail() може працювати нестабільно або блокуватися хостингом. Надійнішим варіантом часто є SMTP із правильною автентифікацією, але його налаштування потрібно виконувати обережно та з урахуванням політик поштового провайдера.
План відкату
До початку міграції має бути зрозуміло, як повернутися до попередньої конфігурації, якщо нова пошта не працює. План відкату не означає автоматичне повернення всіх даних, а визначає конкретні кроки, відповідальних осіб і межі безпечних змін.
- збережіть копію DNS-зони та поточних налаштувань пошти;
- зафіксуйте старі MX-, SPF-, DKIM- і DMARC-записи;
- не вимикайте старий сервер до завершення контрольного періоду;
- визначте, хто має доступ до реєстратора домену, DNS-панелі та поштового сервісу;
- запишіть параметри підключення сайту до SMTP і службових скриньок;
- перед небезпечними операціями створіть резервні копії та перевірте, що їх можна відновити.
Повернення старих MX-записів не гарантує, що листи миттєво знову надходитимуть на попередній сервер: DNS-зміни кешуються, а частина повідомлень може залишатися в чергах відправників. Тому під час проблем потрібно контролювати обидві системи та з’ясовувати, куди фактично доставляється пошта.
Спеціаліст потрібен, якщо немає повного доступу до DNS або старого хостингу, поштові архіви мають значний обсяг, зникли окремі папки, не проходять автентифікації DKIM чи DMARC, або після зміни DNS перестали працювати сайт і пошта одночасно. У таких випадках самостійні повторні зміни можуть ускладнити діагностику та збільшити ризик втрати даних.