Saat sebuah domain diarahkan ke hosting, yang biasanya diatur lebih dulu adalah A record — penunjuk yang memberi tahu browser di alamat IP mana berkas website disimpan. Website terbuka normal, sertifikat terpasang, semuanya tampak selesai. Namun email yang dikirim ke alamat di domain yang sama tidak pernah sampai.
Keadaan ini sering membingungkan karena keduanya memakai nama domain yang persis sama. Padahal di dalam DNS (Domain Name System), alamat website dan alamat penerima email adalah dua penunjuk yang benar-benar terpisah. MX record adalah penunjuk yang mengurus sisi email tersebut, dan satu domain bisa punya website di satu penyedia sementara emailnya di penyedia lain.
Artikel ini membahas isi satu baris MX record, arti angka prioritasnya, cara memverifikasi milik Anda sendiri, serta pesan error yang muncul saat pemasangannya keliru.
MX Record Adalah Penunjuk Server Penerima Email
MX record adalah catatan DNS yang menyebutkan server mana yang berhak menerima email untuk sebuah domain. MX merupakan singkatan dari Mail Exchanger, yang berarti penukar surat. Ketika seseorang mengirim pesan ke nama@domainanda.com, server pengirim menanyakan MX record domainanda.com ke DNS, lalu mengantarkan pesannya ke server yang disebut dalam jawaban itu.
Isi satu baris MX record sendiri sangat sederhana. RFC 1035, dokumen standar yang mendefinisikan format DNS sejak 1987, menetapkan hanya dua field di dalamnya:
- PREFERENCE: angka prioritas berupa integer 16-bit. Nilai yang lebih kecil lebih diutamakan.
- EXCHANGE: nama domain server yang bersedia menerima email untuk domain tersebut.
Di dalam berkas zona DNS, keduanya ditulis berurutan setelah tipe recordnya:
contoh.com. 3600 IN MX 10 mail.contoh.com.Urutan bacanya: nama domain, TTL, kelas IN, tipe MX, angka prioritas, lalu nama server penerima. Panel hosting menyembunyikan kelas dan sering juga TTL, sehingga yang benar-benar Anda isi biasanya hanya dua kolom terakhir — persis dua field dari standarnya.
Dari kesederhanaan itu muncul tiga hal yang perlu diperhatikan. Pertama, field EXCHANGE menyimpan nama domain, bukan alamat IP. Mengisinya dengan alamat IP adalah kesalahan.
Contoh baris MX record: angka 0 adalah field PREFERENCE, mail.indowebsite.co.id adalah field EXCHANGE.
Kedua, MX record tidak menyimpan nomor port sama sekali. Pengiriman antar-server email selalu memakai port 25, dan angka itu ditetapkan di protokol SMTP, bukan di DNS. Jadi tidak ada kolom port yang perlu Anda isi.
Ketiga, MX hanya mengatur email yang masuk. Keluhan "email saya masuk folder spam penerima" tidak akan selesai dengan mengubah MX record.
Empat tahap lookup MX record: baca domain tujuan, tanya MX ke DNS, cari alamat IP, kirim lewat port 25.
Bagaimana kalau sebuah domain sama sekali tidak punya MX record? Standar menyediakan jalan mundur yang disebut implicit MX: pengirim memperlakukan A record domain itu sebagai MX berprioritas 0. Akibatnya email diantarkan ke server tempat website Anda berada, yang pada kebanyakan hosting tidak menjalankan layanan email penerima.
Membaca Angka Prioritas: 0 Sampai 65535
Angka di depan nama server adalah prioritasnya, dan aturannya berlawanan dengan dugaan banyak orang: angka yang lebih kecil justru lebih diutamakan. Server pengirim mencoba MX bernomor terkecil lebih dulu, lalu berpindah ke nomor berikutnya hanya jika yang pertama tidak dapat dihubungi.
Rentangnya 0 sampai 65535. Batas atas itu bukan angka sembarangan, melainkan konsekuensi langsung dari RFC 1035 yang menetapkan field prioritas sebagai integer 16-bit — dan 65535 adalah nilai terbesar yang dapat ditampung 16 bit.
Hal yang paling sering luput: angka ini relatif, bukan absolut. Pasangan 0 dan 10 berperilaku persis sama dengan pasangan 10 dan 20, atau 1 dan 500. Yang dibaca server pengirim hanyalah mana yang lebih kecil di antara record yang tersedia. Karena itu pertanyaan "sebaiknya 0 atau 10?" tidak memiliki jawaban teknis, sepanjang urutannya konsisten.
Gmail memakai tangga lima tingkat yang bisa Anda lihat sendiri:
dig +short MX gmail.com5 gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.
40 alt4.gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.Server tujuan pertama adalah gmail-smtp-in di angka 5. Jika ia menolak koneksi, pengirim menuruni tangga ke 10, lalu 20, dan seterusnya.
Prioritas MX record: 5 dicoba pertama, dua server berangka 10 dibagi beban acak, lalu 20 terakhir.
Bagaimana jika dua record memakai angka yang sama? Itu bukan kesalahan konfigurasi. RFC 5321 justru mewajibkan server pengirim mengacak urutan di antara record berprioritas sama, dengan tujuan yang disebutkan eksplisit di standarnya: menyebarkan beban ke beberapa server penerima sekaligus. Prioritas kembar adalah cara menyatakan bahwa kedua server itu setara.
Standar yang sama mengharapkan pengirim mencoba minimal dua alamat sebelum menyerah. Inilah alasan praktis memiliki lebih dari satu MX record: kalau hanya ada satu dan server itu sedang mati, tidak ada tujuan kedua untuk dicoba.
Perlu diperhatikan bahwa MX kedua hanya berguna kalau server di baliknya benar-benar dikonfigurasi menerima email untuk domain Anda. Menambah baris MX yang menunjuk server yang tidak mengenali domain itu tidak memberi cadangan apa pun — pesannya justru ditolak atau menggantung di antrean.
Tangga prioritas ini benar-benar dipatuhi server email. Ia pernah dipakai sebagai penyaring spam lewat teknik nolisting: host yang sengaja tidak menjawab ditaruh di nomor terkecil. Sekarang teknik itu lebih banyak merugikan, karena perangkat seperti printer hanya mengirim ke MX bernomor terkecil.
Kenapa Google dan Microsoft Kini Cukup Satu Baris
Google Workspace dan Microsoft 365 kini sama-sama cukup dengan satu baris MX. Berikut nilai resmi keduanya, yang sudah ditentukan penyedia dan tidak perlu Anda karang sendiri:
| Penyedia | Host | Nilai server | Prioritas | TTL |
|---|---|---|---|---|
| Google Workspace | @ | smtp.google.com | 1 | default registrar |
| Microsoft 365 | @ | <kunci-domain>.mail.protection.outlook.com | 0 | 3600 |
Perhatikan bahwa keduanya kini hanya meminta satu baris MX. Nilai MX record Google Workspace sebelumnya terdiri dari lima record (ASPMX.L.GOOGLE.COM beserta empat alternatifnya), dan nilai lama itu masih didukung sampai sekarang. Dokumentasinya menyatakan bahwa jika email Anda sudah berjalan, tidak ada yang perlu diubah.
Ada bukti menarik bahwa angka prioritas memang tidak berpengaruh saat recordnya tunggal. Kedua perusahaan itu memakai angka yang berbeda dari saran dokumentasi mereka sendiri untuk domain milik mereka:
dig +short MX google.com
dig +short MX microsoft.com10 smtp.google.com.
10 microsoft-com.mail.protection.outlook.com.Google menyarankan prioritas 1 tetapi memakai 10. Microsoft menyarankan 0 tetapi juga memakai 10. Keduanya berjalan tanpa masalah, karena dengan satu record tidak ada apa pun yang diperbandingkan.
Pergeseran ke MX tunggal ini tidak mengurangi keandalan. Ketahanan terhadap gangguan dipindahkan ke dalam infrastruktur penyedia: di belakang satu nama host itu ada banyak server di beberapa lokasi.
Mengecek MX Record Domain Sendiri
MX record bersifat publik, jadi siapa pun bisa membacanya lewat satu perintah tanpa masuk ke panel hosting. Ada tiga jalur, dan semuanya memberi jawaban yang sama.
Lewat nslookup
Perintah ini tersedia di Windows tanpa perlu memasang apa pun, dan juga ada di macOS serta Linux:
nslookup -type=mx gmail.comNon-authoritative answer:
gmail.com mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 20 alt2.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 10 alt1.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 40 alt4.gmail-smtp-in.l.google.com.
gmail.com mail exchanger = 5 gmail-smtp-in.l.google.com.Baris Non-authoritative answer berarti jawaban berasal dari cache resolver, bukan langsung dari nameserver pemilik domain. Penjelasan lengkap cara membaca keluarannya ada di pembahasan nslookup.
Lewat dig
Di macOS dan Linux, dig memberi keluaran yang lebih ringkas dengan opsi +short:
dig +short MX indowebsite.co.id0 mail.indowebsite.co.id.Tanpa +short, dig juga menampilkan sisa TTL dalam detik di kolom kedua:
dig MX indowebsite.co.id +noall +answerindowebsite.co.id. 280 IN MX 0 mail.indowebsite.co.id.Angka 280 berarti resolver masih akan menyimpan jawaban ini selama 280 detik sebelum menanyakannya lagi.
Lewat alat berbasis web
Jika Anda tidak nyaman dengan terminal, banyak layanan pemeriksa berbasis web yang cukup diberi nama domain. Menu yang perlu Anda cari di sana biasanya berlabel MX record check atau MX lookup. Sebagian layanan memeriksa dari beberapa lokasi dunia sekaligus, berguna saat menunggu perubahan tersebar.
Satu hal yang perlu Anda ketahui sebelum membaca keluaran alat mana pun: urutan yang ditampilkan bukan urutan prioritas. Pada contoh nslookup di atas, angka 30 muncul paling atas dan angka 5 paling bawah. Bahkan menjalankan perintah yang sama dua kali dapat memberi urutan berbeda, karena resolver memutar urutan record.
Ini normal dan bukan tanda konfigurasi rusak. Penyortiran berdasarkan prioritas adalah tugas server pengirim, bukan tugas resolver yang menjawab pertanyaan Anda. Yang perlu Anda periksa adalah isi dan angkanya, bukan urutan tampilannya.
Isi Kolom Host: Kapan @ dan Kapan Nama Subdomain
Saat menambahkan MX record di panel hosting atau registrar, ada satu kolom yang paling sering salah diisi: kolom bernama Host, Name, atau Hostname. Kolom ini menentukan untuk domain mana record tersebut berlaku.
Isian yang hampir selalu benar adalah @, yang berarti domain telanjang itu sendiri. Bagi domain contoh.com, @ menghasilkan MX untuk alamat email nama@contoh.com. Sebagian panel memakai konvensi berbeda — dibiarkan kosong atau diisi nama domain penuh — dengan maksud yang sama.
Kesalahan yang sering terjadi adalah mengisi kolom itu dengan mail, karena nama server tujuannya memang mengandung kata itu. Isian mail menghasilkan MX untuk subdomain mail.contoh.com, sementara contoh.com sendiri tetap tanpa MX. Email ke nama@contoh.com pun tidak terarah ke mana-mana.
Kolom Host diisi @ membuat MX berlaku untuk contoh.com; diisi mail justru untuk mail.contoh.com.
MX di subdomain ada gunanya untuk kebutuhan yang disengaja, misalnya alamat notifikasi di nama@notif.contoh.com yang ditangani penyedia berbeda. Untuk email utama domain, isian yang Anda perlukan adalah @.
Sebagian panel meminta nama server tujuan diakhiri titik (
smtp.google.com.) karena begitulah nama domain absolut dituliskan dalam berkas zona DNS. Panel lain menambahkannya sendiri. Kalau ragu, periksa hasilnya dengandigsetelah menyimpan — bukan menebak dari tampilan form.
Untuk langkah rinci pada cPanel, ikuti panduan cara setting MX record melalui cPanel.
Pesan Error MX Record dan Penyebabnya
Ketika MX record tidak berfungsi, pesan yang muncul biasanya singkat dan tidak menjelaskan sebabnya. Berikut empat kondisi yang paling sering ditemui.
Empat sebab MX record gagal: target tanpa A record, MX ke alias, null MX, dan MX yang tidak dipasang.
Host unresolvable atau host tidak dapat diselesaikan. Nama di field EXCHANGE tidak memiliki A record maupun AAAA record. RFC 5321 mewajibkan nama itu mengembalikan minimal satu catatan alamat saat ditanyakan, sebab dari situlah pengirim tahu ke IP mana harus menyambung. Periksa dengan menanyakan nama server tujuannya secara terpisah, bukan hanya domain Anda.
MX diarahkan ke alias (CNAME). RFC 2181 melarangnya, dan alasannya bersifat teknis, bukan sekadar formalitas. Saat menjawab pertanyaan MX, nameserver otoritatif ikut menyertakan alamat server tujuan dalam jawaban yang sama — mekanisme yang disebut additional section processing. Hasilnya, satu pertanyaan sudah cukup:
dig @ns3.google.com MX gmail.com +noall +answer +additionalgmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 3600 IN MX 10 alt1.gmail-smtp-in.l.google.com.
...
gmail-smtp-in.l.google.com. 300 IN A 74.125.24.27
alt1.gmail-smtp-in.l.google.com. 300 IN A 192.178.230.27
...Alamat IP kelima server datang bersamaan dengan daftar MX-nya. Jika field EXCHANGE berisi alias, bagian tambahan itu kosong, sehingga setiap pengiriman email membutuhkan pertanyaan susulan.
Null MX. Sebuah domain dapat menyatakan secara resmi bahwa ia tidak menerima email, yaitu dengan satu MX record berisi prioritas 0 dan sebuah titik sebagai server tujuan. example.com memakainya:
dig +short MX example.com0 .Aturannya diatur RFC 7505: domain yang memakai null MX tidak boleh punya MX lain, dan pengirim menolak pesannya dengan kode balasan 556 beserta status 5.1.10. Kalau domain Anda menampilkan 0 . padahal seharusnya menerima email, record itulah yang harus dihapus.
MX tidak ditemukan. Pengirim jatuh ke aturan implicit MX dan mengarahkan email ke A record domain Anda, yang umumnya adalah server website tanpa layanan email. Pesan tidak langsung gagal, melainkan diantre dan dicoba ulang berkali-kali — RFC 7505 menyebut lamanya biasanya sekitar satu minggu sebelum pengirim menyerah. Inilah sebabnya email yang hilang karena MX kosong sering baru disadari beberapa hari kemudian.
Berapa Lama Perubahan MX Record Berlaku
Perubahan MX record tidak berlaku serentak di seluruh dunia. Setiap catatan DNS punya TTL (Time To Live), yaitu batas waktu dalam detik sebuah jawaban boleh disimpan resolver di cache. Selama TTL lama belum kedaluwarsa, sebagian pengirim masih memakai nilai yang sudah Anda ganti.
Angka rujukan yang jelas datang dari Microsoft, yang menyarankan TTL 3600 detik atau satu jam, dan menyebutkan bahwa Exchange Online hanya mendukung TTL di bawah 6 jam atau 21.600 detik. Google menyerahkannya ke nilai default registrar Anda.
Urutan yang aman saat memindahkan email ke penyedia baru cukup sederhana. Turunkan TTL MX record yang ada menjadi 300 detik, tunggu selama durasi TTL lama supaya cache lama habis, baru ganti nilai MX-nya. Setelah email terbukti masuk normal selama sehari, naikkan kembali TTL ke 3600 detik agar DNS Anda tidak ditanyai berlebihan.
Satu catatan penting soal migrasi: buat dulu semua akun email di penyedia baru sebelum mengganti MX. Pesan baru langsung masuk ke penyedia baru, sementara email lama tetap tertinggal di tempat sebelumnya. Pembahasan penyebaran perubahan DNS ada di pengertian propagasi DNS.
Hal yang Perlu Anda Pertimbangkan
MX record menyelesaikan satu urusan dengan baik: mengarahkan email yang masuk. Lima hal berikut berada di luar jangkauannya, dan beberapa di antaranya sering disalahartikan.
- MX tidak memverifikasi keaslian pengirim: ia hanya menentukan ke mana email masuk. Domain dengan MX yang benar tetap dapat dipalsukan oleh siapa saja. Perlindungan terhadap email spoofing datang dari catatan lain, yaitu SPF, DKIM, dan DMARC.
- Backup MX terdengar seperti asuransi, tetapi sering menimbulkan masalah: server cadangan yang menampung email harus mengenali domain Anda sebagai domain yang ia layani. RFC 5321 mengharuskan server relay membuang record di level prioritasnya sendiri beserta semua yang bernomor lebih besar. Pemasangan yang keliru membuat email berputar antar-server sampai gagal.
- MX tidak menyentuh email keluar: reputasi pengiriman ditentukan hal lain, termasuk PTR record alias reverse DNS pada IP pengirim.
- Satu MX berarti tidak ada tujuan cadangan: ini wajar bagi penyedia besar yang sudah punya banyak server di belakang satu nama host. Untuk server email yang Anda kelola sendiri di satu mesin, pertimbangkan menambah tujuan kedua.
- MX bisa diarahkan ke gateway penyaring lebih dulu: banyak organisasi menaruh layanan pemfilter di MX, lalu pesan yang lolos diteruskan ke server penyimpan email. Konsekuensinya nama dan alamat IP yang terlihat publik adalah milik gateway itu. Karena MX memang terbuka untuk umum, siapa pun juga bisa mengambil alamat tersebut lalu memeriksanya di daftar hitam email. Contoh penerapannya ada di panduan routing lewat SpamExpert.
Bagi Anda yang tidak ingin mengurus sendiri server penerima beserta seluruh catatan pendukungnya, layanan email hosting menyediakan nilai MX yang sudah siap dipasang beserta pengaturan pendukungnya.
Pertanyaan yang Sering Muncul
MX record untuk apa? Untuk memberi tahu server pengirim di mana email sebuah domain harus diantarkan. Tanpa MX record yang benar, pesan yang dikirim ke alamat di domain itu tidak akan sampai ke kotak masuk Anda.
Apa itu record MX di Microsoft 365? Satu baris MX berisi nilai <kunci-domain>.mail.protection.outlook.com dengan prioritas 0 dan Host @. Bagian kunci domain berbeda untuk setiap pelanggan dan ditampilkan di halaman pengaturan domain pada pusat admin Microsoft 365.
Bisakah satu domain memakai dua penyedia email sekaligus? Tidak untuk satu alamat yang sama. Semua email masuk mengikuti MX bernomor terkecil yang bisa dihubungi, sehingga pesan tidak dapat digandakan ke dua penyedia. Yang mungkin dilakukan adalah memisahkan per subdomain, atau memakai penerusan di sisi penyedia.
Bagaimana melihat MX record yang lama setelah diubah? Nilai sebelumnya tidak tersimpan di DNS Anda. Selama TTL lama belum habis, nilai itu mungkin masih terlihat dari resolver yang belum menyegarkan cache. Setelah itu, hanya layanan pengarsip riwayat DNS yang masih menyimpannya.
Kesimpulan
MX record adalah catatan DNS yang menunjuk server penerima email sebuah domain, dan isinya hanya dua hal: sebuah angka prioritas dan sebuah nama server. Angka prioritas hanya berarti ketika ada lebih dari satu record — nilainya relatif, dan pada pemasangan modern yang memakai satu baris MX, angka itu tidak berpengaruh sama sekali.
MX perlu Anda sentuh saat memasang email di penyedia baru atau memindahkannya, dan sebaiknya dibiarkan selama email masuk berjalan normal. Ketika ada yang tidak beres, satu perintah dig atau nslookup lebih cepat menjawab daripada menebak dari tampilan panel — dengan catatan urutan yang muncul di layar bukan urutan prioritas.
Semoga artikel ini membantu.
