Pindah hosting tanpa email mati itu soal urutan, bukan keberuntungan
Banyak pemilik usaha menyiapkan pindah hosting dengan rapi. File diunduh, database diekspor, tema diuji di server baru. Lalu nameserver diganti. Website terbuka normal, halaman terasa cepat.
Sampai telepon itu datang: pelanggan bertanya kenapa emailnya tidak pernah dibalas. Anda cek kotak masuk, dan ternyata kosong sejak beberapa jam lalu. Website sehat, tetapi email bisnis mati.
Penyebabnya bukan server baru yang rusak. Website dan email memakai catatan DNS yang berbeda. Website berjalan di atas record A dan CNAME, sedangkan email bergantung pada catatan MX. Begitu nameserver diarahkan ke penyedia baru, catatan MX tidak ikut berpindah otomatis.
Urutannya harus dibalik. Salin catatan lama lebih dulu, buat ulang di DNS baru, arahkan nameserver paling akhir. Supaya kerangka kerjanya jelas, baca dulu persiapan migrasi website sebelum menyentuh apa pun. Enam langkah di bawah ini fokus pada satu hal: menjaga email tetap hidup selama proses pindah.
1. Pindah hosting tanpa email mati dimulai dari mengenali catatan MX
Kotak masuk email Anda bergantung pada satu catatan yang jarang dibuka pemilik domain, yaitu MX. Catatan ini memberi tahu pengirim ke server mana pesan harus diantar. Selama nameserver lama masih dipakai, catatan itu bekerja tanpa Anda sadari.
Begitu nameserver berpindah, seluruh pengelolaan DNS jatuh ke tangan penyedia baru. Record lama tidak ikut terbawa. Di layar administrasi DNS yang baru, daftar MX bisa kosong sama sekali.
Akibatnya membingungkan. Website Anda tampil normal karena record A sudah mengarah ke server baru dengan benar. Di saat yang sama, email berhenti menerima pesan. Banyak orang lalu menuduh hosting barunya bermasalah, padahal masalahnya sederhana: catatan emailnya tidak pernah dibuat ulang.
Penyedia email biasanya mempublikasikan daftar server MX beserta nilai prioritasnya. Cocokkan satu per satu saat menyalin. Urutan prioritas itu yang menentukan server mana dicoba lebih dulu oleh pengirim.
Bedakan dua jalur ini. Website dan email memakai rute DNS terpisah. Membetulkan alamat web tidak akan menghidupkan email, dan mengubah MX tidak akan mengubah tampilan situs.
Website pun bisa menipu sementara. Selama TTL catatan lama belum kedaluwarsa, sebagian pengunjung masih dilayani server lama sementara yang lain sudah masuk ke server baru. Tampilan yang mulus di komputer Anda tidak menjamin catatan email di sisi penerima ikut benar.
Karena itu, pindah hosting tanpa email mati bukan soal keberuntungan atau mahal tidaknya vendor. Ini soal urutan pekerjaan. DNS disalin lebih dulu, record email dibuat ulang, nameserver diganti paling akhir.
2. Salin semua record lama sebelum menyentuh nameserver
Langkah yang paling sering dilewati adalah membuka dashboard DNS lama dan menyalin isinya. Banyak orang hanya mencatat record A karena itu satu-satunya yang terasa penting untuk website.
Padahal ada beberapa jenis catatan yang harus Anda pegang:
- Record A dan CNAME untuk website dan subdomain
- Record MX untuk server penerima email
- Record TXT yang memuat SPF, DKIM, dan DMARC
- Record verifikasi layanan pihak ketiga
Sebelum mengubah apa pun, turunkan TTL pada catatan website ke nilai rendah, umumnya 300 detik, minimal 24 sampai 48 jam sebelum cutover. TTL lama menentukan berapa lama catatan lama masih dipakai jaringan. Dengan TTL rendah, langkah salah arah bisa Anda pulihkan jauh lebih cepat.
Simpan salinannya di dokumen atau spreadsheet. Untuk MX, tulis juga nilai priority-nya. Angka prioritas sering terlupa, dan salah menulisnya membuat email masuk ke server yang salah.
Kalau ada catatan yang tidak Anda kenali di daftar, jangan hapus. Record aneh biasanya berasal dari verifikasi yang dipasang vendor atau layanan sebelumnya, dan menghapusnya bisa mematikan fitur yang masih dipakai pelanggan Anda.
Baru setelah salinan itu ada di tangan, buat catatan serupa di penyedia DNS baru. Kerjakan selagi situs masih memakai DNS lama, jadi Anda punya waktu memeriksa tanpa risiko. Kalau perpindahannya lewat Cloudflare, urutan lengkapnya ada di 6 cara memindahkan website ke Cloudflare.
3. Record email harus DNS Only, bukan awan oranye
Kalau domain Anda dikelola lewat Cloudflare, ada jebakan yang tidak terlihat di layar: ikon awan. Dua ikon itu punya arti yang sangat berbeda, dan salah memilih bisa mematikan email tanpa mengganggu website.
Awan oranye berarti lalu lintas HTTP dan HTTPS dilewatkan proxy Cloudflare. Awan abu-abu, yang disebut DNS Only, berarti permintaan langsung menuju server asal. Proxy hanya mengurus trafik web.
Email tidak melewati jalur itu. Jadi catatan MX dan hostname mail wajib dibiarkan DNS Only. Kalau record email diproksikan, mesin pengirim tidak menemukan tujuan yang benar, dan pengiriman bisa gagal atau tersangkut di antrean.
Kesalahan ini sulit dilacak karena dasbor menampilkan catatan yang seolah sudah benar. Karena itu, setiap kali seusai merapikan DNS, periksa ulang ikon pada baris MX dan baris mail. Kasus semacam ini dibahas khusus di panduan resmi soal masalah email di Cloudflare.
Satu pola lapangan yang perlu Anda kenali: website tetap terbuka, halaman admin bisa diakses, tetapi email tidak masuk sama sekali. Kalau pola itu muncul setelah Anda merapikan DNS, curigai ikon proxy pada record email lebih dulu sebelum menuduh penyedia email Anda bermasalah.
Pegang satu patokan: proxy untuk website, DNS Only untuk email.
6 Cara Memindahkan Website ke Cloudflare
4. SPF harus satu record TXT yang dimulai v=spf1
SPF memberi tahu server penerima siapa saja yang berhak mengirim email atas nama domain Anda. Bentuknya bukan tipe record tersendiri, melainkan catatan TXT yang isinya diawali v=spf1.
Di dalamnya Anda mendaftarkan server yang diizinkan, biasanya lewat include menuju penyedia email yang dipakai. Sisa lalu lintas dinyatakan dengan penutup seperti -all atau ~all.
Kesalahan paling umum saat pindah penyedia email adalah menambah record SPF baru. Dua catatan SPF pada nama root tidak diizinkan. Hasilnya bukan penggabungan otomatis, melainkan pemeriksaan yang gagal, dan email Anda bisa ditandai spam atau ditolak.
Aturannya tegas: satu domain, satu catatan SPF. Kalau berganti penyedia, edit record yang sudah ada. Tambahkan include layanan baru, dan hapus include yang sudah tidak dipakai.
Kalau dasbor menolak menyimpan karena SPF dianggap ganda, jangan membuat nama baru sebagai jalan pintas. Hapus salah satu, lalu gabungkan include yang masih dipakai ke dalam catatan v=spf1 yang tersisa. Kebersihan daftar ini menentukan diterima atau ditolaknya email Anda.
Sisakan juga kesabaran. Perubahan SPF bisa butuh sampai 48 jam sebelum autentikasi bekerja penuh. Selama masa itu, sebagian email wajar mendarat di folder spam. Kalau Anda perlu memeriksa kenapa pengiriman gagal, ada panduan menelusuri masalah SPF dari Google Workspace yang cukup membantu.
5. DKIM dan DMARC melengkapi SPF, bukan menggantikannya
SPF memeriksa server pengirim, sedangkan DKIM memastikan isi pesan tidak diubah di perjalanan. DKIM memakai sepasang kunci. Kunci privat disimpan penyedia email, dan kunci publiknya Anda pasang sebagai record TXT di DNS, umumnya pada nama seperti selector._domainkey.
Kunci publik itu tidak ikut pindah sendiri. Saat DNS diganti, salinannya dari dashboard lama harus dipasang ulang di penyedia baru. Kalau terlupa, penerima tidak bisa memverifikasi tanda tangan pesan Anda, dan reputasi pengiriman domain turun perlahan.
DMARC melangkah lebih jauh. Record ini memberi tahu penerima apa yang harus dilakukan ketika SPF dan DKIM tidak lulus, plus ke alamat mana laporan dikirim. DMARC juga ditulis sebagai TXT, pada nama _dmarc.
Catat nama selector DKIM dari dokumentasi penyedia email Anda. Nama itulah yang nanti muncul pada pemeriksaan TXT. Tanpa catatan selector, Anda hanya bisa menebak apakah kunci publik benar-benar terpasang di DNS baru.
Mulailah dengan kebijakan yang longgar sambil memantau laporan, lalu perketat setelah semua jalur pengiriman Anda terdaftar dengan benar. Jangan langsung memakai kebijakan paling keras tanpa tahu aplikasi mana saja yang mengirim email atas nama domain Anda.
Ada uji singkat untuk memastikan ketiganya berjalan. Kirim satu email ke alamat Anda sendiri, buka detail pesan, lalu periksa bagian autentikasi. Nilai spf=pass, dkim=pass, dan dmarc=pass adalah tanda ketiganya sudah terbaca dengan benar.
Tiga hal ini bekerja sebagai satu tim. SPF mengurus siapa yang boleh mengirim, DKIM mengurus keaslian isi, DMARC mengurus keputusan akhir dan pelaporannya. Melewatkan salah satunya membuat autentikasi email Anda bolong.
6. Periksa dengan dig, lalu uji kirim terima setelah propagasi
Setelah semua record dibuat ulang, jangan percaya pada tampilan dasbor saja. Lakukan pemeriksaan dari terminal. Dua perintah ini sudah cukup untuk melihat jawaban publik atas pertanyaan yang paling penting.
Yang pertama, dig namadomain.com MX +short, menampilkan server penerima email yang dikenali jaringan publik. Yang kedua, dig namadomain.com TXT +short, menampilkan catatan TXT, termasuk SPF, DMARC, dan kunci DKIM kalau Anda menyebut nama selectornya. Bandingkan hasilnya dengan salinan yang Anda buat sebelum pindah.
Ingat soal propagasi. Perubahan MX umumnya butuh 1 sampai 24 jam untuk tersebar, tergantung TTL yang dipasang. Kalau di jaringan Anda hasilnya sudah benar tetapi di tempat lain belum, itu normal. Jangan buru-buru mengubah record lagi, sebab perubahan beruntun membuat diagnosis makin rumit.
Setelah dirasa cukup tersebar, uji kirim terima. Kirim email dari akun di luar domain Anda, balas, lalu periksa folder spam dan folder masuk. Lakukan dari arah sebaliknya juga. Kalau bisa, uji dari dua penyedia berbeda supaya Anda tahu masalahnya spesifik di satu jaringan atau memang global.
Hindari menguji hanya dari jaringan kantor sendiri. Wi-Fi kantor sering memakai resolver yang menyimpan jawaban lama, jadi hasilnya bisa berbeda dari jaringan luar.
Jangan lupa mencatat hasil pemeriksaan dan jam pengujiannya di dokumen yang sama dengan salinan record tadi. Kalau nanti ada keluhan email tidak masuk, Anda punya titik pembanding, bukan sekadar dugaan.
Terakhir, biarkan server lama tetap hidup sementara waktu. Sebagian pengunjung dan bot masih memakai catatan DNS lama. Setelah beberapa hari stabil, naikkan kembali TTL ke nilai normal, misalnya 3600 detik.
Kesimpulan: Email mati saat pindah hosting hampir selalu punya sebab yang sama, yaitu catatan email tidak disalin ke DNS baru. Website tampak sehat karena memakai jalur catatan yang berbeda, jadi kerusakan di sisi email tidak terlihat dari halaman depan.
Kerjakan dengan urutan yang benar. Salin semua record lama, buat ulang di penyedia DNS baru, pastikan catatan email berstatus DNS Only, jaga SPF tetap tunggal, lengkapi DKIM dan DMARC, periksa hasilnya dengan dig, lalu uji kirim terima setelah propagasi selesai.
Sebelum mengganti nameserver, luangkan satu jam untuk memeriksa daftar catatan Anda. Buka panel DNS lama hari ini, salin seluruh record ke satu dokumen, dan simpan di tempat yang bisa diakses tim Anda. Satu jam itu jauh lebih murah daripada kehilangan pesanan yang dikirim lewat email.
Perlu layanan pembuatan web atau ingin diskusi digital marketing?
Konsultasikan kebutuhan infrastruktur digital bisnis anda secara langsung dengan pakarnya.