Migrasi Hosting Website Tanpa Memindahkan Email: Apa yang Perlu Dijaga?
Pisahkan migrasi website dan email dengan inventaris DNS, pemeriksaan ketergantungan MX, pengiriman aplikasi, serta rencana pengujian dan pemulihan.
Satu domain dapat menggunakan beberapa layanan berbeda
Pemindahan website sering dibicarakan seolah-olah seluruh layanan sebuah domain harus ikut berpindah. Padahal, website, penerimaan email, dan pengiriman pesan aplikasi dapat menggunakan penyedia yang berbeda. Keputusan mempertahankan layanan email saat memindahkan hosting website masuk akal ketika kotak surat sudah tertata dan tim hanya ingin memperbarui tempat aplikasi berjalan. Kuncinya adalah memahami hubungan antarbagian sebelum mengubah DNS atau menutup layanan lama.
Artikel ini membahas rencana pemisahan tersebut, bukan perintah konfigurasi yang bisa disalin untuk setiap domain. Pengaturan yang benar bergantung pada siapa yang mengelola DNS, server mana yang menerima email, serta cara aplikasi mengirim pesan. Hasil perencanaan yang dibutuhkan ialah daftar komponen yang berubah, komponen yang dipertahankan, penanggung jawab, dan bukti pengujian. Jangan memakai keberhasilan membuka beranda sebagai satu-satunya tanda bahwa migrasi selesai; layanan email memerlukan pemeriksaannya sendiri.
Bedakan lokasi website, DNS, dan kotak surat
Mulailah dengan peta sederhana: penyedia domain, nameserver otoritatif, hosting website, dan penyedia kotak surat. Catat siapa yang memiliki wewenang mengubah masing-masing bagian. Panel tempat membayar domain belum tentu merupakan tempat DNS aktif dikelola. Demikian pula, keberadaan menu email di hosting baru tidak membuktikan bahwa kotak surat perusahaan sudah dipindahkan ke sana. Peta ini membantu menghindari perubahan pada panel yang terlihat benar tetapi tidak melayani DNS publik.
Dokumentasi Cloudflare membedakan MX untuk tujuan penerimaan email dari jenis record yang memetakan nama ke alamat server. Dokumentasi cPanel Zone Editor menunjukkan bahwa beberapa tipe record dikelola secara terpisah. Secara praktis, tim perlu meninjau nama website dan nama server email sebagai objek berbeda. Contoh hipotetisnya, www.example.com dapat menuju hosting baru sementara mail.example.com tetap melayani kotak surat lama. Jangan memakai nama atau alamat contoh sebagai nilai konfigurasi nyata.
Buat inventaris sebelum menyiapkan perubahan
Minta pengelola yang berwenang mencatat record terkait website dan email dari sumber DNS aktif. Untuk setiap record, simpan nama, tipe, nilai, prioritas bila ada, TTL, dan fungsi bisnisnya. Sertakan record verifikasi layanan yang masih digunakan. Catatan ini merupakan bahan kerja internal, sehingga tidak perlu dibagikan ke forum publik. Tujuannya bukan mengumpulkan kredensial, melainkan memiliki acuan yang dapat dibandingkan dengan rencana perubahan dan hasil sesudah migrasi.
Tambahkan daftar alamat layanan yang biasa dipakai pengguna, seperti alamat webmail dan nama server pada aplikasi email. Catat juga alias atau penerusan yang dianggap penting oleh tim. Jika informasi suatu record tidak dipahami, tandai sebagai 'perlu konfirmasi', bukan langsung menghapusnya karena terlihat lama. Saat DNS ikut dipindahkan ke pengelola baru, inventaris menjadi daftar pemeriksaan agar record yang masih diperlukan tersedia pada zona tujuan sebelum nameserver diganti.
Mempertahankan MX saja belum selalu cukup
Periksa nama host yang menjadi tujuan MX dan alamat server yang diperoleh dari nama tersebut. Ada ketergantungan yang mudah terlewat: jika tujuan email memakai nama yang alamatnya ikut diubah untuk website, jalur email dapat berubah walaupun teks MX tetap sama. Contoh hipotetisnya adalah MX yang menunjuk ke example.com, sementara record alamat example.com akan dipindahkan ke server web baru. Tim harus meninjau rancangan itu sebelum perubahan dilakukan.
Cloudflare menjelaskan bahwa tujuan MX harus mengarah pada host dengan record alamat A atau AAAA, bukan alias CNAME. Jika inventaris menemukan konfigurasi yang tidak sesuai, minta pengelola email menentukan perbaikannya secara terencana. Jangan membuat target MX baru dari tebakan nama server. Periksa pula apakah alamat IPv4 dan IPv6 yang terkait masih menunjuk ke layanan yang tepat. Prinsip yang perlu dipertahankan ialah tujuan penerimaan email yang benar beserta ketergantungan alamatnya, bukan sekadar satu baris DNS.
Pisahkan penerimaan email dari autentikasi pengirim
Record penerimaan email tidak menjelaskan semua kebutuhan pengiriman. Dokumentasi Cloudflare menerangkan bahwa SPF mengidentifikasi pengirim yang diizinkan, DKIM berkaitan dengan tanda tangan pesan, dan DMARC memberikan kebijakan serta pelaporan autentikasi. Ketiganya memiliki peran berbeda dari MX. Saat website pindah tetapi penyedia email tetap, record yang masih dibutuhkan penyedia tersebut perlu dipertahankan sesuai petunjuk resminya, termasuk nama selector atau lokasi record yang digunakan.
Perhatian tambahan diperlukan ketika website mengirim notifikasi formulir, pengingat, atau pesan transaksi. Jika cara pengirimannya ikut berubah, daftar pengirim yang sah mungkin perlu ditinjau bersama penyedia email. Jangan menambahkan record dari panduan layanan lain hanya karena formatnya serupa. Buat daftar alur pesan yang benar-benar digunakan dan tentukan siapa yang memvalidasi konfigurasi setiap alur. Dengan demikian, tim dapat membedakan masalah penerimaan kotak surat dari masalah autentikasi pesan yang dikirim aplikasi.
Tinjau pengiriman aplikasi dan email routing di hosting baru
Aplikasi dapat memiliki jalur pengiriman sendiri yang tidak sama dengan aplikasi email pegawai. Sebelum migrasi, minta pengembang menjelaskan apakah pesan dikirim melalui layanan email khusus, server penyedia kotak surat, atau fasilitas pada hosting. Tentukan cara menguji pesan dari lingkungan baru tanpa mengirim notifikasi kepada pelanggan nyata. Gunakan alamat pengujian milik tim dan pesan yang jelas menandai bahwa pengiriman tersebut merupakan percobaan.
Pada cPanel, Email Routing mengatur bagaimana server menangani email untuk domain. Dokumentasi resminya membedakan Local Mail Exchanger dan Remote Mail Exchanger serta menjelaskan bahwa deteksi otomatis memakai informasi zona lokal, bukan pemeriksaan DNS publik langsung. Karena itu, jangan menganggap pilihan otomatis selalu mencerminkan rancangan terbaru. Jika email tetap berada di luar hosting baru, minta penyedia mengonfirmasi pengaturan yang sesuai dan uji pesan ke alamat berdomain sendiri maupun alamat eksternal setelah konfigurasi disepakati.
Rencanakan waktu perubahan tanpa janji propagasi seragam
Tetapkan jendela perubahan saat penanggung jawab website dan email sama-sama dapat dihubungi. Pisahkan pekerjaan persiapan dari perubahan yang memengaruhi pengunjung. Misalnya, isi website dapat diperiksa terlebih dahulu pada lingkungan tujuan, sedangkan perubahan DNS dilakukan setelah daftar pemeriksaan disetujui. Jika hanya alamat website yang berubah, jelaskan secara tertulis bahwa layanan kotak surat tetap dipertahankan. Jika nameserver juga berubah, ruang lingkup pemeriksaan DNS perlu lebih luas.
Dokumentasi TTL Cloudflare menjelaskan peran durasi cache DNS. Pengaturan TTL dapat membantu perencanaan, tetapi bukan jaminan semua pengamat langsung menerima jawaban baru pada detik yang sama. Nilai yang sudah tersimpan sebelumnya dan jalur resolusi perlu dipertimbangkan. Hindari menutup layanan lama hanya karena satu komputer melihat website baru. Tentukan kriteria penyelesaian berdasarkan hasil pengujian dan konfirmasi penanggung jawab, lalu susun jadwal penghentian yang tidak memutus kotak surat yang memang masih digunakan.
Uji penerimaan, balasan, dan pesan dari website secara terpisah
Siapkan skenario pengujian sebelum hari perubahan. Kirim pesan dari alamat eksternal yang dikuasai tim ke kotak surat domain, lalu balas kembali dan pastikan keduanya diterima pada tempat yang diharapkan. Periksa pula alur penting seperti alias atau penerusan bila digunakan. Catat waktu pengiriman, pengirim, penerima, dan hasilnya tanpa memasukkan isi sensitif ke laporan. Keberhasilan satu alamat tidak otomatis membuktikan bahwa semua alias dan aturan penerusan telah bekerja.
Selanjutnya, uji pesan yang berasal dari website baru dengan akun pengujian. Bedakan hasil 'aplikasi menampilkan terkirim' dari 'pesan diterima pada tujuan'. Bila pesan tidak ditemukan, periksa bersama pengelola pada lapisan yang sesuai, termasuk folder spam dan laporan kesalahan yang relevan. Jangan mencoba menyelesaikan semua kegagalan dengan mengubah MX, sebab masalahnya mungkin berada pada pengiriman aplikasi. Gunakan catatan sebelum migrasi sebagai pembanding agar perubahan perilaku dapat ditelusuri dengan alasan yang jelas.
Siapkan rencana kembali dan penutupan pekerjaan
Rencana kembali perlu menyebut perubahan mana yang boleh dibatalkan, siapa yang mengambil keputusan, dan apa dampaknya pada pekerjaan yang telah berjalan. Mengembalikan alamat website tidak selalu memulihkan pesan yang sudah dikirim ke server berbeda. Karena itu, bila email sempat menerima pesan di lebih dari satu tempat, minta pengelola meninjau keberadaan pesan sebelum menonaktifkan layanan. Simpan inventaris awal dan catatan perubahan sampai seluruh pihak menyatakan pemeriksaan selesai.
Untuk membahas kebutuhan layanan, mulai dari https://www.jagoweb.com/ dan baca informasi hosting cPanel di https://www.jagoweb.com/hosting-cpanel. Jelaskan apakah yang dipindahkan hanya website, DNS sekaligus, atau email juga, agar pembicaraan dukungan memiliki ruang lingkup yang sama. Akhiri pekerjaan dengan peta layanan terbaru serta pemilik setiap bagian. Pemisahan migrasi yang terdokumentasi membuat tim memahami apa yang tetap berjalan pada penyedia lama dan mencegah tagihan lama dihentikan tanpa melihat ketergantungannya.
Bacaan terkait
Sumber dan referensi
