Setiap domain yang dipakai berkirim surat bergantung pada satu baris catatan DNS bernama MX record. Baris itu menyebutkan server mana yang berhak menerima email untuk domain tersebut. Hampir semua panduan pemindahan email berhenti di titik ini: ubah MX, tunggu propagasi, selesai.
Kenyataannya tidak selalu sesederhana itu. Ada satu kelas masalah yang justru muncul setelah MX diubah dengan benar. Pesan dari luar tidak memantul, tetapi juga tidak pernah muncul di kotak masuk. Pengirim tidak menerima laporan kegagalan apa pun, sehingga tidak ada satu pun pesan galat yang bisa dijadikan petunjuk.
Penyebabnya biasanya bukan di DNS, melainkan pada keputusan yang diambil server sesudah pesan tiba di depan pintunya. Email routing adalah nama untuk keputusan tersebut, dan ia disimpan di tempat yang sama sekali berbeda dari MX record.
Email Routing Adalah Keputusan Tujuan, Bukan Sekadar Menu
Email routing adalah proses penentuan ke mana sebuah pesan harus diantarkan pada setiap titik perjalanannya, dari server pengirim sampai kotak surat penerima. Padanan Indonesianya perutean email, dan sebagian panel menuliskannya dengan urutan terbalik, sehingga routing email adalah istilah yang persis sama.
Kata routing di sini dipinjam dari dunia jaringan, tetapi objeknya berbeda. Pada jaringan komputer yang dirutekan adalah paket data, dan penentunya adalah tabel di dalam router. Pada email yang dirutekan adalah satu pesan utuh, dan penentunya tersebar di beberapa tempat sekaligus: catatan DNS, konfigurasi server penerima, serta aturan di panel penyedia.
Persoalan yang sering muncul saat mencari jawaban atas pertanyaan apa itu email routing adalah satu nama dipakai untuk tiga hal berbeda:
- Menu Email Routing di panel hosting: satu pengaturan di cPanel yang menentukan apakah server tersebut boleh mengantar surat domain Anda ke kotak surat lokalnya sendiri.
- Layanan routing terkelola: produk seperti Cloudflare Email Routing yang mengambil alih penerimaan surat domain Anda lalu meneruskannya sesuai aturan yang Anda buat.
- Konsep umum perjalanan pesan: rangkaian keputusan teknis yang berlaku pada semua sistem email, terlepas dari perangkat lunak yang dipakai.
Ketiganya saling terkait, tetapi hanya yang ketiga yang menjelaskan dua sisanya. Karena itu kita mulai dari sana.
Perjalanan Satu Pesan dan Titik Tempat Rutenya Ditentukan
Sebuah pesan melewati empat keputusan sebelum sampai di kotak masuk, dan tidak satu pun terlihat oleh pengirim maupun penerima.
Keputusan pertama diambil server pengirim. Ia mengambil bagian domain di belakang tanda @, lalu menanyakan MX record domain itu ke DNS. RFC 5321 bagian 5.1 mengatur langkah ini secara rinci. Bila domain tidak punya MX sama sekali, alamatnya diperlakukan seolah memiliki implicit MX (MX tersirat) berpreferensi 0 yang menunjuk host itu sendiri. Namun bila MX ada dan tidak satu pun bisa dipakai, situasi itu wajib dilaporkan sebagai kegagalan, bukan dialihkan diam-diam ke A record.
Keputusan kedua diambil server penerima. Begitu koneksi masuk, server memeriksa apakah domain tujuan termasuk domain yang ia layani sendiri. Kalau ya, pesan diantar ke kotak surat lokal. Kalau tidak, ia harus memutuskan apakah bersedia meneruskan pesan itu ke server lain, yang dalam istilah SMTP disebut relay (penerusan antar-server). RFC 5321 bagian 3.6.2 menyarankan balasan kode 550 bila server menolak me-relay karena alasan kebijakan.
Keputusan ketiga diambil tabel rute di dalam server. Pada Exim, yang menjadi mail server bawaan di hampir semua server cPanel, alamat penerima dilewatkan ke rangkaian router secara berurutan. Setiap router bisa menerima, menolak, menunda, atau menggagalkan alamat tersebut. Pada Postfix, peran yang setara dipegang tabel transport, yang menurut dokumentasi resminya menimpa pilihan tujuan bawaan Postfix.
Keputusan keempat adalah pengantaran akhir. Pesan ditulis ke kotak surat, atau diserahkan ke aturan penerusan bila ada.
Email routing melewati empat keputusan: baca MX, antar lokal atau teruskan keluar, pilih cara antar, tulis ke kotak surat.
Empat keputusan ini berjalan di mesin yang berbeda dan dikelola pihak yang berbeda. Itulah sebabnya satu perubahan di DNS tidak otomatis menyelaraskan semuanya.
MX Menentukan Pintu Masuk, Routing Menentukan Sisanya
Perbedaan peran ini yang paling sering tertukar. MX record menjawab satu pertanyaan saja: pesan untuk domain ini harus dikirim ke server yang mana. Setelah pesan diterima server tersebut, MX tidak punya suara lagi.
Bayangkan sebuah kantor dengan satu pos jaga di gerbang. MX record adalah papan penunjuk di jalan raya yang mengarahkan kurir ke gerbang itu. Email routing adalah aturan yang dipegang petugas pos jaga: paket ini ditaruh di rak dalam, paket itu diteruskan ke gedung sebelah, paket lain ditolak. Papan penunjuk yang benar tidak menjamin petugasnya memegang aturan yang benar.
Dari sinilah masalah paling membingungkan itu lahir. Sebuah domain memindahkan emailnya ke Google Workspace, MX-nya sudah menunjuk server Google, dan pengujian dari luar terlihat normal. Namun server hosting lama masih mencatat domain itu sebagai domain miliknya sendiri. Ketika ada pesan dikirim dari akun lain di server yang sama, server tidak repot menanyakan MX. Ia merasa berhak mengantar sendiri, dan pesan berakhir di kotak surat lokal yang tidak pernah dibuka siapa pun.
Pesan itu tidak hilang. Ia tersimpan rapi di tempat yang salah, tanpa laporan kegagalan, karena dari sudut pandang server pengantaran tersebut berhasil.
Tiga Pilihan Email Routing di cPanel dan Arti Praktisnya
Menu Email Routing di cPanel menyimpan keputusan tersebut dalam empat pilihan. Satu pilihan bersifat otomatis, tiga sisanya menyetel perilaku secara langsung. Nama resminya memakai istilah Mail Exchanger (penukar surat), sama dengan kepanjangan MX.
- Local Mail Exchanger: server selalu menerima surat untuk domain ini dan mengantarnya ke kotak surat lokal. Dipakai ketika email domain memang dihosting di server itu juga. Ini juga pilihan yang tepat bila di depan server ada layanan penyaring spam yang meneruskan surat bersih ke sana.
- Remote Mail Exchanger: server menolak menerima surat untuk domain ini, dan mengarahkannya ke mail exchanger berprioritas terendah sesuai MX record. Ini pilihan yang benar ketika email domain sudah dipindahkan ke Google Workspace, Microsoft 365, atau penyedia lain.
- Backup Mail Exchanger: server bertindak sebagai penampung cadangan. Surat diantre di sana sampai exchanger utama bisa dihubungi kembali, lalu diteruskan.
- Automatically Detect Configuration: cPanel menebak sendiri di antara ketiganya. Ini pilihan bawaan dan yang disarankan dokumentasi resmi.
Tiga pilihan email routing cPanel: Local mengantar di server ini, Backup mengantre dulu, Remote meneruskan keluar.
Pilihan Backup terdengar menarik karena menjanjikan tidak ada surat yang hilang saat penyedia utama sedang bermasalah. Dalam praktiknya ia jarang dibutuhkan. Server pengirim yang taat standar sudah punya mekanisme antre sendiri: RFC 5321 bagian 4.5.4.1 menyarankan jeda percobaan ulang minimal 30 menit, dengan waktu menyerah yang umumnya perlu 4 sampai 5 hari. Rentang itu jauh lebih panjang daripada durasi gangguan penyedia besar pada umumnya.
Sebaliknya, penampung cadangan menambah satu titik yang perlu diamankan. Server semacam itu harus menerima surat untuk alamat yang daftar penerimanya tidak ia ketahui. Akibatnya, pesan untuk alamat yang tidak ada baru ketahuan salah setelah diterima.
Kenapa Deteksi Otomatis Bisa Salah Menebak
Deteksi otomatis bekerja dengan aturan yang sederhana. cPanel membaca MX bernomor terkecil, lalu mencocokkannya dengan IP server yang bersangkutan. MX yang menunjuk server ini menghasilkan Local, MX yang menunjuk server lain menghasilkan Backup, dan tidak adanya MX yang menunjuk server ini menghasilkan Remote.
Ada satu batasan yang dinyatakan terbuka di dokumentasi resminya. Deteksi otomatis hanya membaca catatan di berkas zona lokal server, dan tidak melakukan DNS lookup yang sebenarnya. Selama nameserver domain masih mengarah ke server hosting tersebut, keduanya sama. Begitu nameserver dipindahkan ke Cloudflare atau ke panel registrar, berkas zona lokal berhenti diperbarui sementara MX yang berlaku di internet berubah.
Sejak saat itu tebakan cPanel dihitung dari data yang sudah tidak dipakai siapa pun. Inilah alasan sebuah domain bisa tetap tersetel Local walaupun MX aslinya sudah lama menunjuk penyedia lain.
Di lapisan yang lebih dalam, Exim di server cPanel membaca dua berkas untuk mengambil keputusan yang sama. Domain yang terdaftar di /etc/localdomains diperlakukan sebagai domain lokal dan suratnya diantar di server itu juga. Domain yang terdaftar di /etc/remotedomains dikirim keluar mengikuti MX. Menu Email Routing di cPanel pada dasarnya adalah antarmuka untuk memindahkan domain di antara kedua berkas tersebut.
Perubahan pengaturan email routing berlaku seketika di server, karena ia tidak disimpan di DNS. Yang perlu menunggu propagasi hanyalah perubahan MX record.
Cara Setting Email Routing di cPanel
Langkahnya singkat, tetapi urutannya penting. MX record diselesaikan lebih dahulu, baru pengaturan routing disesuaikan.
Langkah #1: Pastikan MX Record Sudah Benar
Buka menu Zone Editor atau MX Entry, lalu periksa nilai MX domain Anda. Bila email dipindahkan ke penyedia luar, hapus MX lama yang menunjuk server hosting dan pasang nilai resmi dari penyedia baru. Selama masih ada MX lama yang tertinggal dengan prioritas lebih kecil, sebagian surat tetap datang ke server lama.
Langkah #2: Buka Menu Email Routing
Menu ini ada di grup EMAIL pada halaman utama cPanel, dengan nama Email Routing. Pilih domain yang ingin diatur dari daftar di bagian atas halaman. Pada akun dengan banyak domain, pengaturan ini berlaku per domain, bukan per akun.
Langkah #3: Pilih Rute yang Sesuai lalu Simpan
Untuk email yang dihosting di server itu sendiri, pilih Local Mail Exchanger. Untuk email yang sudah pindah ke penyedia luar, pilih Remote Mail Exchanger. Klik Change untuk menyimpan. Perubahan berlaku pada pesan berikutnya, tanpa perlu memulai ulang layanan.
Bila Anda mengelola server sendiri lewat WHM, pengaturan yang sama juga muncul saat membuat akun cPanel baru pada kolom pengaturan email.
Menu ini identik di semua hosting berbasis cPanel, sehingga langkahnya tidak berubah dari satu penyedia ke penyedia lain. Panel di luar keluarga cPanel — Plesk, DirectAdmin, atau CWP — menyimpan keputusan yang sama dengan nama menu berbeda. Karena itu yang perlu Anda cari bukan judul menunya, melainkan pertanyaannya: apakah server ini masih berhak mengantar surat untuk domain tersebut.
Memeriksa Rute Sebelum dan Sesudah Diubah
Pemeriksaan dilakukan berlapis, karena tiap lapis menjawab pertanyaan yang berbeda.
Lapis pertama adalah MX record yang berlaku di internet. Perintah dig tersedia di macOS dan Linux, dan hasilnya diurutkan berdasarkan angka prioritas:
dig +short MX gmail.com | sort -n5 gmail-smtp-in.l.google.com.
10 alt1.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.Angka di depan nama server adalah preferensi, dan nilai lebih kecil lebih diutamakan. Bila beberapa MX punya angka sama, RFC 5321 mewajibkan pengirim mengacaknya untuk membagi beban. Cara membaca keluaran ini lebih lengkap dibahas di panduan nslookup.
Lapis kedua adalah keputusan server itu sendiri. Di server yang memakai Exim, perintah berikut memperlihatkan router mana yang akan menangani sebuah alamat, beserta tujuan akhirnya:
exim -bt nama@domainanda.comPerintah ini hanya menguji rute dan tidak mengirim pesan apa pun. Kode keluarannya bernilai 0 bila semua alamat berhasil dirutekan, 1 bila ada alamat yang tidak dapat diselesaikan, dan 2 bila ada alamat yang gagal sepenuhnya. Perintah ini dijalankan di sisi server melalui SSH, bukan dari komputer pembaca.
Lapis ketiga adalah bukti pengantaran. cPanel menyediakan menu Track Delivery yang mencatat tujuan akhir setiap pesan beserta alasan penolakan bila ada. Langkahnya ada di panduan cek log pengiriman dan penerimaan email.
Gejala Rute yang Keliru dan Cara Membacanya
Rute yang salah jarang menampilkan pesan galat yang jelas. Empat gejala berikut yang paling sering muncul, dan masing-masing menunjuk penyebab berbeda.
- Pesan dari sesama pengguna server hilang tanpa jejak: pengirim tidak menerima laporan kegagalan, penerima tidak menerima apa pun. Penyebabnya domain masih tersetel Local padahal kotak suratnya ada di penyedia luar. Pesan tersimpan di kotak surat lokal yang tidak pernah dibuka.
- Pesan memantul dengan keterangan penerima tidak ditemukan: server merasa berhak melayani domain itu, tetapi tidak menemukan alamat yang dituju di daftar kotak suratnya. Gejala ini muncul pada domain yang tercatat di
/etc/localdomainspadahal seharusnya di/etc/remotedomains. - Penolakan dengan kode 550 saat mengirim keluar: server diminta meneruskan surat ke domain yang bukan miliknya tanpa autentikasi yang sah. Penyebab paling umum adalah pengaturan SMTP di aplikasi email yang belum mengaktifkan autentikasi, bukan pengaturan routing.
- Pesan berputar sampai akhirnya ditolak: dua server saling merasa pihak lain yang bertanggung jawab, sehingga pesan dikirim bolak-balik. Kondisi ini disebut mail routing loop (perulangan rute surat). RFC 5321 bagian 6.3 menyebut penghitungan baris
Received:sebagai cara yang terbukti efektif mendeteksinya, dengan ambang penolakan yang disarankan minimal 100 entri. Penyebabnya biasanya satu domain tersetel Local di dua server sekaligus, atau MX yang menunjuk balik ke server yang baru saja meneruskan pesan itu.
Gejala pertama yang paling berbahaya karena tidak meninggalkan bukti di sisi pengirim maupun penerima. Satu-satunya tempat yang mencatatnya adalah log pengiriman di server, dan pengelola domain umumnya baru membukanya setelah ada keluhan.
Email routing Remote mengantar pesan ke penyedia luar; rute Local yang keliru menaruhnya di kotak lokal kosong.
Bila email dari luar masuk normal tetapi email dari sesama pengguna hosting yang sama tidak pernah sampai, penyebabnya hampir pasti pengaturan routing, bukan DNS.
Routing Terkelola: Cloudflare, Google Workspace, dan Microsoft 365
Tidak semua keputusan rute diambil di server hosting. Tiga layanan berikut memindahkannya ke panel penyedia, dengan cara kerja yang berbeda-beda.
Email routing diputuskan di tiga lapis: MX record di DNS, menu di server hosting, lalu aturan panel penyedia.
Cloudflare Email Routing mengambil alih penerimaan surat domain Anda. Saat diaktifkan, ia menambahkan tiga jenis catatan DNS secara otomatis: MX agar surat masuk ke Cloudflare, TXT SPF, dan TXT DKIM. Layanan ini tersedia pada paket gratis maupun berbayar.
Batasnya terdokumentasi: 200 aturan rute per domain, 200 alamat tujuan per akun, dan ukuran pesan masuk maksimal 25 MiB. Setiap alamat tujuan wajib diverifikasi lebih dahulu, dan selama belum diverifikasi, aturan yang menunjuk alamat tersebut tetap nonaktif. Aturan catch-all (tangkap semua) menampung juga alamat yang salah ketik, dengan pilihan tindakan berupa kirim ke email lain, serahkan ke Worker, atau buang pesan. Yang perlu dicatat, layanan ini tidak memberi Anda kotak surat, dan pengiriman keluar merupakan kapabilitas terpisah di luar Email Routing.
Google Workspace menaruh keputusannya setelah pesan masuk ke Google. Pengaturan Default routing menentukan perilaku bawaan seluruh organisasi, sementara aturan di Routing settings dapat menimpanya untuk kasus yang lebih spesifik. Dari sini lahir dua pola yang sering ditanyakan.
Split delivery membagi pesan masuk ke dua sistem email berbeda berdasarkan kriteria penerima, biasanya dipakai selama masa migrasi. Dual delivery membuat satu pesan sampai ke lebih dari satu kotak masuk sekaligus. Keduanya bekerja setelah pesan diterima Google, bukan dengan menggandakan MX record.
Microsoft 365 memakai istilah connector (penghubung), yaitu kumpulan instruksi yang mengubah alur surat masuk dan keluar organisasi. Dokumentasi Microsoft menyatakan bahwa sebagian besar organisasi justru tidak membutuhkannya untuk alur surat biasa.
Connector baru diperlukan pada empat keadaan. Pertama, ada server email di kantor sendiri. Kedua, ada pembatasan keamanan khusus dengan mitra bisnis. Ketiga, ada perangkat seperti printer atau aplikasi yang perlu me-relay surat. Keempat, volume kiriman rutin perlu dikecualikan dari greylisting (penundaan sementara sebagai penyaring spam).
Perlu dibedakan dari mail flow rule (aturan alur surat), yaitu aturan yang mengatur perlakuan pesan berdasarkan pengirim, penerima, atau isinya. Connector menentukan jalur yang dipakai, sedangkan aturan alur surat menentukan perlakuan terhadap pesan yang lewat.
Pola ketiganya sebenarnya sama, dan berlaku juga pada penyedia lain seperti Zoho Mail: MX menunjuk ke penyedia, lalu seluruh keputusan berikutnya dijalankan di panel penyedia itu, bukan di server hosting Anda.
Dokumentasi yang sama menyisipkan peringatan yang berlaku untuk semua konfigurasi routing: pastikan server yang menghadap internet tidak tanpa sengaja tersetel sebagai open relay, yaitu server yang bersedia meneruskan surat dari sumber mana pun. Konfigurasi semacam itu menyamarkan asal pesan yang sebenarnya.
Email Routing dan Email Forwarding Bukan Hal yang Sama
Kedua istilah ini sering dipakai bergantian, padahal keduanya bekerja pada tahap yang berbeda.
| Email routing | Email forwarding | |
|---|---|---|
| Pertanyaan yang dijawab | Pesan ini harus diantar ke mana | Pesan yang sudah diterima diapakan |
| Waktu bekerja | Sebelum pesan diterima | Setelah pesan diterima |
| Objek yang diatur | Domain | Alamat email |
| Tempat pengaturan | Menu Email Routing, MX record | Menu Forwarders |
Rute yang salah membuat aturan penerusan tidak pernah berjalan, karena pesannya bahkan tidak sampai ke server yang menyimpan aturan tersebut. Karena itu urutan pemeriksaannya selalu rute dahulu, baru penerusan. Pembahasan lengkap sisi penerusan ada di artikel email forwarding adalah.
Hal yang Perlu Anda Pertimbangkan Sebelum Mengubah Routing
Mengubah satu pilihan di menu ini terasa ringan, padahal akibatnya menyentuh seluruh surat masuk domain Anda.
- Salah pilih membuat surat hilang tanpa peringatan: dokumentasi cPanel menyatakan pengaturan yang keliru dapat mengganggu kemampuan domain menerima surat. Berbeda dengan kesalahan DNS yang biasanya memantul, kesalahan rute justru mengantar pesan ke tempat yang salah dengan status berhasil.
- Mengarahkan ke luar berarti menyerahkan kendali: setelah domain tersetel Remote, seluruh penyaringan, penyimpanan, dan kebijakan keamanan surat masuk mengikuti aturan penyedia tujuan.
- Aturan yang tertinggal di server lama tetap diam-diam aktif: forwarder, autoresponder, dan filter yang pernah dibuat di server lama tidak ikut berpindah, dan tidak pula terhapus.
- Autentikasi pengirim tetap perlu diperiksa ulang: memindahkan tujuan surat masuk tidak menyentuh SPF, DKIM, maupun DMARC yang mengatur sisi kirim. Keduanya diatur terpisah.
Sebagai panduan angka, pilih Local hanya bila seluruh kotak surat domain memang berada di server tersebut. Pilih Remote begitu satu saja penyedia luar mengambil alih MX bernomor terkecil. Hindari Backup kecuali Anda benar-benar mengelola server penampung sendiri dan sanggup mengurus antreannya. Setelah mengubah pengaturan, kirim dua pesan uji: satu dari akun di server yang sama, satu lagi dari luar. Tunggu paling lama 15 menit sebelum menyimpulkan ada yang keliru.
Bagi pemilik domain yang tidak ingin mengurus keputusan ini sendiri, menempatkan seluruh kotak surat pada layanan email hosting menyisakan satu pengaturan rute saja, diselesaikan sekali di awal.
Pertanyaan yang Sering Muncul
Apa perbedaan email routing dan email forwarding?
Email routing menentukan server mana yang berhak mengantar pesan untuk sebuah domain, dan bekerja sebelum pesan diterima. Email forwarding meneruskan pesan yang sudah diterima ke alamat lain. Rute yang salah membuat aturan penerusan tidak pernah dijalankan.
Kenapa email tidak sampai padahal MX record sudah benar?
Kemungkinan terbesarnya server hosting masih mencatat domain Anda sebagai domain lokal. Pesan dari pengguna lain di server yang sama tidak melewati pemeriksaan MX, sehingga langsung diantar ke kotak surat lokal yang kosong. Ubah pengaturan menjadi Remote Mail Exchanger.
Apakah Cloudflare Email Routing gratis?
Layanan ini tersedia pada paket gratis maupun berbayar, dengan batas 200 aturan rute per domain dan ukuran pesan masuk maksimal 25 MiB. Yang perlu diingat, layanan ini meneruskan pesan dan tidak menyediakan kotak surat.
Apakah mengubah email routing perlu menunggu propagasi DNS?
Tidak. Pengaturan ini disimpan di server, bukan di DNS, sehingga berlaku pada pesan berikutnya. Yang perlu menunggu propagasi hanyalah perubahan MX record itu sendiri.
Bisakah satu domain memakai dua tujuan sekaligus?
Bisa, tetapi tidak lewat MX. Pembagian semacam split delivery dan dual delivery dijalankan penyedia setelah pesan diterima, sehingga MX tetap menunjuk satu tujuan.
Apa arti pesan galat tentang mail routing loop?
Artinya pesan berputar di antara dua server yang sama-sama merasa bukan tujuan akhirnya. Periksa apakah domain itu tersetel Local di lebih dari satu server, dan pastikan MX-nya tidak menunjuk balik ke server yang meneruskan pesan tersebut.
Apakah menu Email Routing ada di panel selain cPanel?
Keputusannya selalu ada karena setiap mail server harus menentukan lokal atau diteruskan, tetapi namanya berbeda-beda antarpanel. Pada panel non-cPanel, cari pengaturan layanan mail per domain, bukan menu bernama Email Routing.
Kesimpulan
Email routing adalah keputusan tentang ke mana sebuah pesan diantarkan, dan keputusan itu diambil di beberapa tempat sekaligus: MX record di DNS, pengaturan di panel hosting, serta aturan di sisi penyedia email. MX menentukan pintu masuknya, sementara routing menentukan segala hal yang terjadi sesudah pesan melewati pintu tersebut.
Pilih Local Mail Exchanger bila kotak surat domain memang berada di server itu, dan Remote Mail Exchanger begitu penyedia luar mengambil alih MX. Saat sebuah pesan hilang tanpa laporan kegagalan, periksalah pengaturan rutenya lebih dahulu sebelum mencurigai DNS.
Semoga artikel ini membantu.
