Memindahkan Domain dan Hosting Tanpa Melupakan Email Pesantren
Pindah hosting, pindah DNS, dan transfer domain adalah pekerjaan berbeda. Pisahkan langkahnya agar website, email, dan data aplikasi tetap terpantau.
Digitalisasi Pesantren
Telusuri email pesantren yang masuk spam dari status pengiriman, SPF, DKIM, DMARC, reputasi pengirim, sampai pengaturan SMTP dan antrean aplikasi.
Mengganti judul pesan tidak akan memperbaiki email yang ternyata belum pernah keluar dari aplikasi.
Ketika wali mengatakan “emailnya tidak masuk”, jangan langsung menyimpulkan pesan berada di spam. Bisa jadi alamat salah, antrean belum berjalan, server menolak pengiriman, atau pesan memang sudah diterima tetapi disaring. Urutkan pemeriksaannya supaya perubahan yang dibuat menjawab masalah yang benar.
Minta waktu pengiriman, alamat tujuan, dan jenis pesan tanpa meminta kata sandi atau kode verifikasi wali. Cek apakah ada pemberitahuan gagal kirim. Jika ada, simpan kode kesalahan dan keterangannya untuk penyedia email; jangan hanya mengambil tangkapan layar kata “gagal”.
Bedakan tiga keadaan. Belum dikirim berarti perlu mengecek aplikasi atau koneksi ke layanan email. Ditolak berarti ada respons dari jalur pengiriman yang perlu dibaca. Masuk spam berarti pesan sudah sampai ke penyedia penerima tetapi tidak ditempatkan di kotak masuk utama.
Minta penerima mencari berdasarkan alamat pengirim, bukan hanya nama lembaga. Nama yang tampil dapat berubah, sementara alamat membantu memastikan pesan yang dicari memang benar.
Kirim pesan singkat dari webmail lembaga ke akun eksternal yang dikelola untuk pengujian. Lalu kirim pesan dari aplikasi ke tujuan yang sama. Jangan mengirim percobaan berulang kali ke banyak wali.
Jika webmail berhasil tetapi aplikasi tidak, periksa jalur aplikasi. Pada Pondok CMS, baca konfigurasi SMTP dan cron serta antrean. Pengaturan MAIL_* dan scheduler sama-sama perlu benar. Uji SMTP yang didukung paket; akun webmail aktif tidak berarti semua metode pengiriman tersedia.
Jika kedua jalur bermasalah, penyedia email perlu memeriksa autentikasi, pembatasan akun, atau server pengirim. Jika hanya satu alamat tujuan gagal, cek ejaan dan pemberitahuan dari penyedia penerima sebelum menyalahkan seluruh domain.
SPF, DKIM, dan DMARC membantu penerima memeriksa keabsahan pesan. Ketiganya bukan tombol yang menjamin seluruh email masuk inbox.
Gmail menjelaskan persyaratan pengirim untuk akun Gmail pribadi, termasuk autentikasi dan persyaratan tambahan bagi pengirim massal. Aturan itu perlu dibaca sesuai jenis dan skala pengiriman; jangan menganggap semua pesan lembaga otomatis termasuk pengiriman massal.
Di Gmail, menu Tampilkan versi asli atau Show original membantu melihat hasil autentikasi. Gunakan pesan langsung yang baru dikirim, bukan pesan yang sudah melalui penerusan berlapis. Mintalah administrator membaca hasil SPF, DKIM, dan DMARC beserta domainnya, bukan hanya melihat satu label “pass”.
Salin record yang ada sebelum mengubahnya. Ambil nilai SPF dan DKIM dari panel atau panduan penyedia untuk akun yang dipakai. Jangan menyalin nilai domain lain dari tangkapan layar.
Satu nama domain tidak boleh memiliki beberapa record SPF yang sama-sama diawali v=spf1. Jika email pengurus dan aplikasi memakai penyedia berbeda, administrator perlu memperhitungkan seluruh pengirim sah dalam pengaturan yang tepat, bukan menambahkan SPF kedua.
DKIM juga perlu diaktifkan di layanan pengirim; memublikasikan kunci di DNS saja belum tentu menyelesaikan langkahnya. Untuk DMARC, jangan langsung menerapkan penolakan ketat sebelum pengirim sah terpetakan. Kebijakan pemantauan dapat membantu tahap awal, tetapi laporannya perlu diperiksa.
Pengelolaan record DNS harus dilakukan di pengelola yang aktif. Record MX mengatur penerimaan email, sehingga mengganti MX bukan obat umum untuk pesan keluar yang masuk spam. Jika memakai Zoho, ikuti panduan email lembaga untuk urutan konfigurasinya.
Penerima tetap dapat menyaring pesan berdasarkan reputasi dan perilaku pengiriman. Periksa apakah akun dipakai mengirim tanpa izin, apakah banyak alamat tujuan tidak valid, atau apakah volume meningkat mendadak. Jika ada pengiriman mencurigakan, amankan akun sebelum mencoba memperbaiki isi pesan.
Untuk pemberitahuan, gunakan nama pengirim yang jelas, subjek yang sesuai, dan isi yang menjelaskan alasan wali menerima pesan. Hindari lampiran besar yang tidak diperlukan. Jangan memakai daftar alamat hasil kumpulan yang tidak berhubungan dengan layanan lembaga.
Pesan promosi dan pesan operasional juga perlu dibedakan. Ikuti ketentuan persetujuan serta berhenti berlangganan yang berlaku pada layanan dan jenis pengiriman. Jangan meminta semua wali menandai “bukan spam” untuk menutupi konfigurasi yang rusak.
Catat waktu percobaan, alamat pengirim dan tujuan, jalur webmail atau aplikasi, kode penolakan bila ada, serta hasil autentikasi. Bagikan hanya informasi yang diperlukan kepada penyedia; sembunyikan isi pribadi dan kode masuk.
Setelah diperbaiki, ulangi pengujian terbatas dan bandingkan hasilnya. Perbaikan reputasi tidak selalu langsung terlihat. Untuk undangan penting yang belum diterima, sediakan bantuan melalui kontak resmi sambil petugas menelusuri masalahnya, bukan menyuruh wali terus menekan tombol kirim ulang.
Ikuti panduan instalasi langkah demi langkah. Jika ada developer atau alumni yang bisa membantu, ajak mereka melihat kodenya di GitHub.