Cara Cek Email Masih Nyasar ke Server Lama Setelah MX Record Dipindah

MX record sudah dipindah ke server baru, cek DNS dari laptop sudah menunjuk ke alamat baru, tapi beberapa orang masih bilang emailnya tidak sampai. Biasanya email itu tidak hilang. Email tersebut diterima dengan normal oleh server lama, lalu disimpan di mailbox yang sudah tidak dibuka siapa pun. Di tiket support, keluhan ini sering muncul satu sampai beberapa hari setelah migrasi, dan bentuknya hampir selalu sama: "sebagian email masuk, sebagian tidak". Artikel ini fokus ke cara memverifikasinya lewat command line. Tujuannya ada tiga: memastikan DNS di luar sana sudah benar-benar berpindah, membuktikan apakah server lama masih menerima email, dan menentukan kapan server lama aman dimatikan.

Kenapa sebagian pengirim masih ke server lama

Setiap record DNS punya TTL (time to live), yaitu berapa detik resolver boleh menyimpan jawaban di cache sebelum wajib bertanya ulang. Kalau TTL MX lama adalah 86400 (contoh, setara satu hari), resolver yang sempat menyimpan jawaban lama tepat sebelum kamu mengubah record boleh terus memakai jawaban itu sampai satu hari ke depan. Server pengirim yang memakai resolver tersebut akan terus mengirim ke IP lama. Selama server lama masih hidup dan masih menganggap domain itu miliknya, email diterima dan masuk ke mailbox di sana. Ada tiga hal lain yang sering terlewat. Pertama, MX tidak menunjuk langsung ke IP. MX menunjuk ke nama host, misalnya mail.contoh.com, lalu nama host itu punya A record sendiri dengan TTL-nya sendiri. Kalau yang kamu ubah hanya A record mail, TTL yang berlaku adalah TTL A record itu, bukan TTL MX. Kedua, kalau migrasinya sekalian pindah nameserver, ada lapisan cache tambahan. Record NS yang dipegang server TLD (misalnya server .com) punya TTL sendiri yang tidak bisa kamu atur dari zona, dan nilainya bisa jauh lebih panjang. Selama resolver masih memegang NS lama, resolver itu tetap bertanya ke nameserver lama. Kalau zona di nameserver lama masih berisi MX lama, hasilnya tetap MX lama, berapa pun TTL yang kamu pasang di zona baru. Ketiga, ini yang paling sering bikin bingung: email dari server lama itu sendiri. Kalau website masih di server lama dan form kontaknya mengirim ke [email protected], MTA di server lama (Exim atau Postfix) melihat domain itu terdaftar sebagai domain lokal. Email langsung dikirim ke mailbox lokal tanpa melihat DNS sama sekali. Ini bukan masalah cache, dan tidak akan beres hanya dengan menunggu.

Cek MX dan TTL dari beberapa sisi

Jangan hanya mengandalkan dig dari laptop sendiri. Resolver ISP kamu bisa saja sudah fresh, sementara resolver yang dipakai pengirim belum. Bandingkan jawaban dari nameserver authoritative (sumber aslinya), dari beberapa resolver publik, dan dari server TLD.

BASH

# Nameserver yang sedang dipakai domain
dig contoh.com NS +short

# MX langsung dari authoritative; TTL di sini adalah nilai penuh yang kamu set
dig @ns1.contoh-dns.net contoh.com MX +noall +answer

# MX dari resolver publik; TTL di sini adalah sisa waktu cache di resolver itu
dig @8.8.8.8 contoh.com MX +noall +answer
dig @1.1.1.1 contoh.com MX +noall +answer

# A record host yang dituju MX (cek juga TTL-nya)
dig @8.8.8.8 mail.contoh.com A +noall +answer

# Delegasi NS di server TLD, contoh untuk domain .com
dig @a.gtld-servers.net contoh.com NS +norecurse

Ganti ns1.contoh-dns.net dengan nameserver hasil query pertama. Untuk TLD selain .com, cari dulu server TLD-nya dengan dig com. NS +short (ganti com. dengan TLD kamu, misalnya id.). Cara membacanya: kolom kedua di setiap baris jawaban adalah TTL. Di jawaban authoritative angkanya tetap. Di resolver publik angkanya menurun setiap kali kamu query ulang, karena itu sisa umur cache. Kalau resolver publik sudah memberi MX baru, berarti resolver tersebut sudah mengambil data terbaru. Tapi ini tidak menjamin semua resolver di internet sudah sama. Resolver publik memakai anycast, jadi dua query berturut-turut bisa mengenai node cache yang berbeda dan memberi sisa TTL yang berbeda pula. Angka yang paling penting untuk perencanaan adalah TTL lama, yaitu TTL MX, A record mail, dan NS sebelum perubahan. Hitung sejak perubahan disimpan. Setelah waktu sebanyak TTL lama terlama itu lewat, resolver yang patuh seharusnya sudah tidak memakai jawaban lama. Sebagian resolver punya batas minimum atau maksimum cache sendiri, jadi tambahkan margin.

Buktikan server lama masih menerima email

DNS hanya menunjukkan kemungkinan. Bukti yang sebenarnya ada di log server lama. Login ke server lama, lalu cari pengiriman lokal untuk domain yang sudah pindah.

BASH

# Exim (umumnya cPanel): baris ' => ' adalah pengiriman ke tujuan
grep 'contoh.com' /var/log/exim_mainlog | grep ' => ' | tail -n 20

# Jumlah dan isi antrean Exim
exim -bpc
exim -bp | head -n 40

# Postfix: path log tergantung distro (/var/log/maillog atau /var/log/mail.log)
grep 'to=<[^>]*@contoh.com>' /var/log/maillog | grep 'status=sent' | tail -n 20

# Ringkasan antrean Postfix (baris terakhir berisi total)
postqueue -p | tail -n 1

# Kalau log hanya ada di journald
journalctl -u postfix --since today | grep 'contoh.com' | tail -n 20

Di Exim, perhatikan baris => yang transport-nya mengarah ke pengiriman lokal (nama transport tergantung konfigurasi, sering berisi kata dovecot atau local). Di Postfix, perhatikan relay= di baris yang sama. Kalau isinya pengiriman lokal atau ke Dovecot, berarti email itu berakhir di mailbox server lama. Untuk server cPanel, fitur Track Delivery di WHM membaca log yang sama dengan tampilan yang lebih mudah dibaca. Pembahasannya ada di cara membedakan bounce dan spam lewat Track Delivery cPanel. Antrean (queue) juga perlu dicek. Queue berisi email yang belum terkirim. Di server lama, queue yang berisi email untuk domain yang sudah pindah biasanya berarti server lama mencoba relay ke luar dan gagal, atau ada email keluar dari website lama yang tertahan. Kedua kondisi ini perlu diselesaikan sebelum server dimatikan, karena isi queue ikut hilang bersama server.

Cek isi mailbox dan asal email

Log bisa sudah dirotasi, jadi cek juga mailbox-nya langsung. Pada cPanel, mailbox biasanya disimpan dalam format Maildir: satu file per email di bawah /home/USER/mail/DOMAIN/. Path ini bisa berbeda di setup lain.

BASH

# Jumlah file email yang dibuat dalam 24 jam terakhir (abaikan file index Dovecot)
find /home/USERCPANEL/mail/contoh.com -type f -mtime -1 ! -name 'dovecot*' ! -name 'maildirsize' | wc -l

# Daftar file terbaru beserta waktunya
find /home/USERCPANEL/mail/contoh.com -type f -mtime -1 ! -name 'dovecot*' ! -name 'maildirsize' -printf '%TY-%Tm-%Td %TH:%TM %p
' | sort | tail -n 20

# Lihat dari mana email itu masuk: header Received paling atas dan pengirimnya
grep -m 3 -E '^(Received|From):' /home/USERCPANEL/mail/contoh.com/info/new/NAMAFILE

Command ini read-only, tidak mengubah apa pun. Header Received paling atas menunjukkan siapa yang menyerahkan email ke server lama. Ada dua pola yang sering muncul. Kalau isinya IP server luar, berarti pengirim tersebut masih memegang MX lama di cache-nya. Kalau isinya localhost atau nama host server lama sendiri, berarti email dibuat di server itu, misalnya dari form website atau cron, dan masuk lewat pengiriman lokal. Kasus kedua tidak akan berhenti dengan sendirinya. Kamu perlu memindahkan website, atau mengubah konfigurasi di server lama supaya domain itu diperlakukan sebagai remote. Di cPanel pengaturan ini ada di Email Routing, dengan opsi Remote Mail Exchanger, sehingga server lama ikut melihat MX publik. Email yang terlanjur masuk ke mailbox lama bisa dipindahkan lewat sinkronisasi IMAP inkremental ke mailbox baru, atau diekspor manual. Pilih cara yang tidak menggandakan email yang sudah pernah tersinkron.

Kapan server lama aman dimatikan

Ini yang sering salah kaprah: mematikan server lama justru biasanya lebih aman daripada membiarkannya tetap hidup tapi "setengah dibongkar". Kalau server lama mati atau port 25-nya tidak merespons, pengirim yang masih memakai cache lama mendapat kegagalan sementara. MTA pengirim akan menyimpan email di queue dan mencoba lagi. Pada percobaan berikutnya biasanya MTA melakukan lookup MX ulang, sehingga setelah cache kedaluwarsa email sampai ke server baru. Jendela retry umumnya beberapa hari, tergantung konfigurasi pengirim. Yang berbahaya ada dua kondisi. Pertama, server lama masih hidup dan menerima email secara lokal, sehingga email tersimpan di tempat yang tidak dibaca. Kedua, domain sudah dihapus dari server lama tapi SMTP-nya masih menjawab. Server lama lalu menolak dengan kode 5xx (misalnya relay not permitted atau user unknown). Kode 5xx adalah kegagalan permanen, jadi pengirim langsung menerima bounce dan tidak mencoba ulang. Patokan praktis sebelum mematikan server lama:

Waktu sebanyak TTL lama terlama (MX, A record mail, dan NS di TLD kalau nameserver ikut pindah) sudah lewat, ditambah margin.
Resolver publik dan authoritative konsisten memberi MX baru.
Log server lama tidak lagi menunjukkan pengiriman lokal dari IP luar untuk domain tersebut selama beberapa hari berturut-turut.
Tidak ada lagi email yang berasal dari server lama sendiri, karena website, form, dan cron sudah pindah atau sudah diarahkan ke remote.
Queue di server lama kosong, dan sinkronisasi terakhir mailbox lama ke mailbox baru sudah dijalankan.

Peringatan: menghapus akun atau mematikan VPS lama tidak bisa dibatalkan. Ambil backup mailbox dan konfigurasi dulu, dan jalankan sinkronisasi terakhir setelah langkah 3 dan 4 terpenuhi. Untuk migrasi berikutnya, bagian yang paling mengurangi masalah ada di awal: turunkan TTL MX dan A record mail beberapa waktu sebelum cutover. Setelah cutover, jadikan log server lama sebagai alat ukur, bukan perkiraan. Selama log masih menunjukkan email masuk dari luar, server lama belum selesai tugasnya. Setelah log bersih beberapa hari dan semua sumber lokal sudah dipindah, server lama bisa dimatikan dengan tenang.