Новий сайт може відкриватися бездоганно, а рахунки, листи відновлення пароля й відповіді клієнтів — перестати надходити. Помилка полягає в тому, що зміну серверів імен сприймають як налаштування лише сайту. Цей план призначений для невеликої компанії, яка переносить DNS до іншого провайдера, залишаючи чинну поштову службу. Це робоча процедура, а не обіцянка безперервної доставки. У прикладах використано зарезервоване ім’я example.com: підставляйте свій домен і значення, надані провайдером. ВИЗНАЧТЕ, ЩО САМЕ ПЕРЕНОСИТЬСЯ Запишіть три окремі служби: реєстратора домену, провайдера авторитетних DNS-відповідей і компанію, що обслуговує поштові скриньки. У цій міграції змінюйте лише другу. Залиште хостинг сайту, поштову підписку й сервіси відправлення листів без змін. Якщо колега одночасно хоче перенести скриньки, оформіть це як окремий проєкт з іншою датою. Так у разі збою можна шукати його причину, не розбираючись одразу з кількома міграціями. СКЛАДІТЬ ІНВЕНТАР ПЕРЕД ЗМІНОЮ СЕРВЕРІВ Експортуйте поточну зону й збережіть поруч читабельну копію. У таблиці потрібні ім’я запису, тип, значення, пріоритет, TTL, призначення, відповідальний за службу й результат перевірки. Включіть кореневе ім’я, www, mail, autodiscover, селектори DKIM, _dmarc та всі записи підтвердження. Додайте записи CRM, сервісу рахунків і підтримки, навіть якщо ніхто не пам’ятає, хто їх створив. Уточніть у відповідального за кожен інструмент, чи він досі надсилає пошту від вашого домену. Записи MX визначають поштові сервери, а TXT можуть публікувати поштові політики. SPF, DKIM і DMARC виконують різні завдання: збереження одного не замінює інших. Посилання на специфікації наведені внизу. Записуйте фактичні чинні значення, а не універсальний приклад з інструкції. Не створюйте додаткову конкурентну SPF-політику лише тому, що її пропонує панель нового DNS-провайдера. ВІДРЕПЕТИРУЙТЕ НОВУ ЗОНУ Створіть зону на новому майданчику й порівняйте її з інвентарем рядок за рядком. Автоматичне виявлення — початкова підказка, а не доказ готовності. У нашому умовному прикладі sales@example.com залишається в того самого поштового провайдера, тому адреси й пріоритети MX мають залишитися незмінними. A-запис сайту теж може бути тим самим. Перенесення DNS не вимагає вигадувати нові адреси пошти чи вебсайту. Перед зміною делегування опитайте кожен новий авторитетний сервер безпосередньо. Збережіть відповіді для MX, кореневого TXT, _dmarc і кожного активного селектора DKIM. Можна використати команду dig @NEW_NAMESERVER example.com MX, замінивши позначення призначеним сервером. Порівнюйте повні значення, а не сам факт наявності запису. Відсутній селектор може зачепити лише одного відправника, тому випадкова перевірка здатна ввести в оману. Оберіть спокійне вікно змін і призначте одного виконавця. У тому самому завданні запишіть попередні сервери імен та ідентифікатор нової зони. Якщо плануєте знизити TTL, зробіть це заздалегідь і дочекайтеся завершення попереднього TTL: останньої хвилини кеші миттєво не очищуються. Визначте час ухвалення рішення про відкат і людину, яка може його погодити. ПЕРЕВІРТЕ DNSSEC ОКРЕМИМ КРОКОМ Якщо DNSSEC увімкнено, перевірте поточні дані DS і дотримайтеся процедури міграції нового провайдера. Не залишайте в батьківській зоні DS, що посилається на ключ, який нова зона не використовує. Документація Cloudflare щодо повного налаштування пояснює цю залежність. Для підписаної зони потрібен явний крок DNSSEC у плані, а не припущення, що форма зміни серверів сама все владнає. ПЕРЕВІРТЕ ШЛЯХ КЛІЄНТА, А НЕ ЛИШЕ САЙТ До й після зміни надішліть лист з унікальною позначкою із зовнішньої скриньки на справжню адресу компанії та дайте відповідь. Повторіть із другим зовнішнім провайдером. Потім запустіть відновлення пароля, сповіщення підтримки й тестовий рахунок з інструментів у вашому інвентарі. Використовуйте тестових клієнтів і нечутливі дані. Зафіксуйте очікуваний лист, факт доставки й результати автентифікації в його заголовках. Якщо сайт працює, а вхідна пошта — ні, почніть з MX і служби приймання. Якщо не доходять лише листи CRM, порівняйте її записи автентифікації та журнали. Якщо одна мережа має проблему, а інша ні, зіставте DNS-відповіді, перш ніж змінювати програму. Це запропоноване дерево діагностики: воно звужує пошук, але саме по собі не доводить причину. ЗАВЕРШІТЬ МІГРАЦІЮ ДОКАЗАМИ Залиште обидві DNS-служби доступними на погоджений період спостереження. Поки збираєте результати, уникайте сторонніх змін. Закривайте завдання лише тоді, коли порівняння інвентарю, зовнішні поштові тести й перевірки бізнес-інструментів мають відповідальних і зафіксовані результати. Збережіть фінальний експорт зони, час і невирішені винятки. Цей невеликий звіт допоможе під час наступного перенесення більше, ніж знімок екрана зі статусом «активний». Плануєте новий бренд? Порівняйте імена в каталозі DomainEvery: https://domainevery.com/uk/domains, а відповідальних за пошту й DNS включіть у план запуску. ПЕРШОДЖЕРЕЛА Cloudflare: зміна серверів імен: https://developers.cloudflare.com/dns/zone-setups/full-setup/setup/; Cloudflare: поштові записи: https://developers.cloudflare.com/dns/manage-dns-records/how-to/email-records/; Формати DNS, RFC 1035: https://www.rfc-editor.org/rfc/rfc1035.html; SPF, RFC 7208: https://www.rfc-editor.org/rfc/rfc7208; DKIM, RFC 6376: https://www.rfc-editor.org/rfc/rfc6376.html; DMARC, RFC 7489: https://www.rfc-editor.org/rfc/rfc7489.html.