Panduan Bedah Exim Log cPanel: Cara Membaca & Troubleshootin

Pernah nggak kamu lagi enak-enak monitor server, tiba-tiba ada client nelpon bilang “email saya nggak masuk” atau “kenapa email saya bounce terus?” Kamu buka log Exim, dan yang kamu lihat cuma baris-baris pendek yang nggak ngasih banyak petunjuk. Saya pernah nge-handle kasus persis seperti ini — client bilang email order dari customer mereka hilang. Saya buka /var/log/exim/mainlog, dan yang muncul cuma beberapa karakter error yang sangat singkat. Saya harus muter-muter dua jam sebelum nemu bahwa sebenarnya log Exim yang aktif itu terlalu minim untuk dijadikan acuan troubleshoot.

Jadi begini — log Exim itu ibarat CCTV di sebuah gedung perkantoran. Kalau CCTV-nya cuma merekam frame per menit, kamu nggak akan bisa tau siapa yang masuk jam berapa, lewat pintu mana, dan bawa apa. Begitu juga Exim. Log bawaannya memang dirancang untuk ringan — tapi untuk kebutuhan troubleshooting yang serius, kamu perlu mengaktifkan verbose logging supaya setiap detail komunikasi email tercatat dengan lengkap.

Artikel ini akan membawa kamu dari nol — mulai dari cara mengaktifkan verbose log, memahami struktur log Exim, mengenal perintah-perintah CLI yang wajib dikuasai NOC engineer, hingga membaca kode-kode error spesifik yang sering muncul di server cPanel. Semuanya berdasarkan pengalaman langsung menangani ratusan server produksi. Kita juga akan membahas bagaimana SpamAssassin dan SpamBox berintegrasi dengan Exim di lingkungan cPanel, karena dua komponen ini sering jadi aktor tersangka saat email masuk ke spam folder secara tidak wajar.

Mengapa Log Bawaan Exim Tidak Cukup?

Sebelum masuk ke teknis, penting untuk memahami kenapa banyak engineer yang frustrasi dengan log Exim bawaan. Dalam kondisi default, Exim hanya mencatat informasi minimal — cukup untuk melihat bahwa email masuk dan keluar, tapi nggak cukup untuk memahami kenapa sebuah email gagal, kenapa routing-nya salah, atau kenapa autentikasi SMTP gagal. Tanpa verbose logging, kamu seperti mencoba memperbaiki mobil cuma dengan dengar suara mesinnya — nggak ada diagnostic code, nggak ada data spesifik.

Dampaknya terhadap troubleshooting sangat signifikan. Ketika client melapor email bounce, kamu harus menebak-nebak penyebabnya alih-alih langsung melihat di log apa yang terjadi. Proses yang seharusnya selesai dalam 10 menit bisa makan waktu satu jam atau lebih. Dalam konteks bisnis, email yang gagal terkirim bisa berarti deal yang hilang, invoice yang nggak sampai, atau komunikasi kritis yang putus di tengah jalan.

Konfigurasi & Aktivasi Verbose Log di WHM

Pertama-tama, kita perlu mengaktifkan verbose logging agar Exim mencatat lebih banyak informasi. Ada dua cara utama: melalui WHM dan melalui file config langsung.

Cara 1: Melalui WHM Advanced Editor

Login ke WHM → Service Configuration → Exim Configuration Manager → tab “Advanced Editor”. Di bagian log_selector, kamu bisa menambahkan parameter-parameter yang dibutuhkan. Ini beberapa parameter paling berguna:

Rekomendasi saya: untuk produksi, jangan pakai +all karena log-nya akan jadi sangat besar dan memakan disk I/O. Gunakan kombinasi parameter yang relevan. Contoh konfigurasi yang bagus untuk troubleshoot email delivery issues:

log_selector = +address_rewrite +dns_lookup +host_lookup_failed +reject +smtp_confirmation +smtp_protocol_error

Kalau kamu memang butuh debug total (misalnya lagi investigate masalah serius), pakai +all tapi ingat untuk balik ke konfigurasi yang lebih ringan setelah selesai.

Cara 2: Edit File Konfigurasi Langsung

Buka file /etc/exim.conf dan cari baris log_selector. Kalau belum ada, tambahkan di bagian “Main” configuration:

log_selector = +address_rewrite +dns_lookup +host_lookup_failed +reject +smtp_confirmation

Setelah edit, reload Exim:

systemctl restart exim

atau melalui WHM: Home → Restart Services → Exim Mail Server.

Struktur & Perintah CLI Exim yang Wajib Dikuasai

Setelah verbose logging aktif, kamu perlu menguasai perintah-perintah CLI Exim untuk membaca dan menganalisis log. Berikut adalah perintah-perintah yang saya gunakan hampir setiap hari sebagai NOC engineer:

Perintah Dasar Monitoring

Perintah Pencarian & Analisis Log

# Cari semua email dari IP tertentu
exigrep "192.0.2.10" /var/log/exim/mainlog

# Cari semua email ke alamat tertentu
exigrep "user@client-a.com" /var/log/exim/mainlog

# Cari semua error dalam 24 jam terakhir
exigrep "== " /var/log/exim/mainlog | grep "$(date +%Y-%m-%d)"

# Cari semua bounce
exigrep "** " /var/log/exim/mainlog | tail -20

# Cari semua penolakan (rejected)
exigrep "rejected" /var/log/exim/mainlog | tail -20

# Cari semua email yang berhasil deliver
exigrep "=> " /var/log/exim/mainlog | tail -30

Memahami Pola Notasi di Log Exim

Ini bagian yang paling penting untuk dipahami. Log Exim menggunakan pola notasi simbol untuk menandai jenis aktivitas. Kalau kamu nggak paham simbol-simbol ini, membaca log Exim akan seperti membaca huruf Cina.

Jadi pola pembacaannya: mulai dari simbol paling kiri. <= berarti email masuk, lalu => berarti email keluar, ** berarti bounce, dan == berarti defer. Dari kombinasi simbol-simbol ini, kamu bisa memetakan perjalanan sebuah email dari awal hingga akhir.

Contoh Log Lengkap & Analisis

Mari kita lihat contoh log nyata dan belajar membacanya:

2026-07-20 09:15:33 [45231] <= orders@shop-client.com H=mail.shop-client.com [203.0.113.25] P=ESMTPS X=TLSv1.3 TLS_AES_256_GCM_SHA384 CV=no C="250 OK id=1mN8k2-0003ABC-123" S=4521 I=5 E=none N=8 QT=0.002 DT=0.001
2026-07-20 09:15:34 [45231] => admin@mydomain.com R=virtual_user T=virtual_delivery H=local [127.0.0.1] C="250 OK" QT=0.8 DT=0.799
2026-07-20 09:15:34 [45231] => sales@mydomain.com R=virtual_user T=virtual_delivery H=local [127.0.0.1] C="250 OK" QT=0.8 DT=0.799
2026-07-20 09:16:45 [45232] <= newsletter@marketing-tool.com H=relay.marketing-tool.com [198.51.100.50] P=ESMTPS X=TLSv1.2 TLS_AES_128_GCM_SHA256 CV=no C="250 OK id=2kL9m3-0004DEF-567" S=15234 I=8 E=none N=12 QT=0.003 DT=0.002
2026-07-20 09:16:46 [45232] == user@mydomain.com R=lookuphost T=remote_smtp H=mx1.mydomain.com [203.0.113.10] C="421 4.7.1 Try again later" QT=1.2 DT=1.198
2026-07-20 09:16:46 [45232] == user@mydomain.com R=lookuphost T=remote_smtp H=mx2.mydomain.com [203.0.113.11] C="421 4.7.1 Try again later" QT=1.2 DT=1.198
2026-07-20 09:21:46 [45232] == user@mydomain.com R=lookuphost T=remote_smtp H=mx1.mydomain.com [203.0.113.10] C="421 4.7.1 Try again later" QT=5.0 DT=4.999
2026-07-20 09:31:47 [45232] == user@mydomain.com R=lookuphost T=remote_smtp H=mx1.mydomain.com [203.0.113.10] C="450 4.7.25 IP not in whitelist" QT=10.0 DT=9.998
2026-07-20 09:31:47 [45232] ** user@mydomain.com: H=mx1.mydomain.com [203.0.113.10] C="450 4.7.25 IP not in whitelist — too many connections" QT=10.0 DT=9.998
2026-07-20 09:31:47 [45232] Frozen (delivery error message)
2026-07-20 09:31:47 [45232] <= <> R=double-bounce T=double_bounce S=0 QT=0.001 DT=0.001

Mari kita trace dari awal:

• Baris 1 (<=): Email masuk dari orders@shop-client.com via TLS. Message ID adalah 45231. Semua normal di sini.
• Baris 2-3 (=>): Email berhasil deliver ke admin@mydomain.com dan sales@mydomain.com lokal. OK, dua recipient sudah selesai.
• Baris 4 (<=): Email baru masuk dari newsletter@marketing-tool.com. Message ID 45232.
• Baris 5-6 (==): Email ke user@mydomain.com gagal deliver ke MX1 dan MX2 — remote server membalas 421 4.7.1 Try again later. Artinya remote server sedang sibuk atau rate limiting.
• Baris 7 (==): Retry pertama setelah 5 menit — masih gagal dengan kode yang sama.
• Baris 8 (==): Retry kedua — sekarang error berubah ke 450 4.7.25 IP not in whitelist. IP server kita kena rate limit atau blacklist sementara.
• Baris 9 (**): BOUNCE — email gagal total setelah beberapa retry. Pesan error lengkap ditampilkan.
• Baris 10 (Frozen): Email membeku di queue karena delivery error.
• Baris 11 (<=): Double bounce tercatat — karena bounce-nya juga gagal dikirim.

Dari trace ini, kita bisa simpulkan: masalahnya bukan di server lokal, tapi di remote MX server yang menolak koneksi karena IP kita masuk rate limiting atau whitelist issue. Solusinya: cek apakah IP server masuk di RBL, dan pertimbangkan untuk mengatur retry time atau menghubungi admin remote server.

Bedah Kode Error Mail Exim

Sekarang kita masuk ke bagian yang paling ditunggu — memahami kode-kode error Exim. Kode error Exim mengikuti standar SMTP reply codes, tapi Exim menambahkan detail internal yang sangat membantu untuk troubleshooting.

Kode 421 — Service Not Available / Temporarily Not Available

Error 421 berarti server tujuan belum siap menerima email. Ini sifatnya temporary — Exim akan otomatis retry. Tapi kalau terus-menerus muncul, ada masalah yang perlu diurus.

2026-07-20 10:05:12 [67890] == recipient@external.com R=lookuphost T=remote_smtp H=mx.external.com [203.0.113.50] C="421 4.7.1 Service temporarily overloaded" QT=0.5 DT=0.499
2026-07-20 10:10:13 [67890] == recipient@external.com R=lookuphost T=remote_smtp H=mx.external.com [203.0.113.50] C="421 4.3.2 Not currently accepting mail" QT=5.0 DT=4.998
2026-07-20 10:25:15 [67890] == recipient@external.com R=lookuphost T=remote_smtp H=mx.external.com [203.0.113.50] C="421 4.7.1 Service temporarily overloaded" QT=15.0 DT=14.997
2026-07-20 11:05:16 [67890] => recipient@external.com R=lookuphost T=remote_smtp H=mx.external.com [203.0.113.50] C="250 OK id=3mP7q1-0008GHI-901" QT=40.0 DT=39.995

Di contoh ini, email awalnya ditolak karena server overload. Exim retry beberapa kali, dan akhirnya berhasil deliver di percobaan keempat setelah 40 menit. Kalau kamu lihat pola seperti ini, nggak perlu panik — Exim sedang bekerja sebagaimana mestinya.

Kode 450 — Mailbox Unavailable / Access Denied (Temporary)

450 berarti ada masalah akses yang sifatnya temporary. Penyebab paling umum: rate limiting, IP masuk blacklist sementara, atau autentikasi yang belum selesai.

2026-07-20 14:22:10 [11223] == client@partner.com R=lookuphost T=remote_smtp H=mx.partner.com [198.51.100.15] C="450 4.7.1 IP not in whitelist" QT=0.3 DT=0.298
2026-07-20 14:22:11 [11223] == client@partner.com R=lookuphost T=remote_smtp H=mx.partner.com [198.51.100.15] C="450 4.7.25 Please try again later" QT=0.3 DT=0.298

Dari log ini, IP server kita kemungkinan masuk di daftar whitelist temporary server partner. Cek apakah IP kita masuk di RBL seperti Spamhaus, Barracuda, atau lainnya. Kamu bisa cek dengan:

# Cek IP server di berbagai RBL
dig +short 10.0.0.1.zen.spamhaus.org
dig +short 10.0.0.1.b.barracudacentral.org
dig +short 10.0.0.1.bl.spamcop.net

Kode 451 — Local Error in Processing (Temporary)

451 berarti ada error lokal di server tujuan. Ini juga temporary dan Exim akan retry. Biasanya terkait DNS issues atau server yang sedang restart.

Kode 452 — Insufficient Storage (Temporary)

452 berarti mailbox penuh atau server kehabisan storage. Sering muncul untuk mailbox shared hosting yang sudah melebihi quota.

2026-07-20 16:44:55 [33445] == user@hosting-client.com R=virtual_user T=virtual_delivery H=local [127.0.0.1] C="452 4.2.2 Mailbox quota exceeded" QT=0.001 DT=0.001
2026-07-20 16:44:55 [33445] ** user@hosting-client.com: Remote host said: 452 4.2.2 Mailbox quota exceeded QT=0.001 DT=0.001

Solusinya: login ke cPanel client, cek penggunaan disk di Email Accounts, dan minta client bersihkan mailbox atau upgrade quota.

Kode 550 — Mailbox Not Found / Relay Denied (Permanent)

Ini error permanen — Exim tidak akan retry karena server tujuan menolak secara definitive. 550 punya beberapa sub-variasi:

# 550 User not found — alamat email tidak ada
2026-07-20 17:05:12 [55667] ** nonexistent@client-a.com R=lookuphost T=remote_smtp H=mx.client-a.com [203.0.113.20] C="550 5.1.1 The email account that you tried to reach does not exist" S=189 QT=0.5 DT=0.499

# 550 Relay denied — server menolak relay
2026-07-20 17:10:33 [66778] ** spammer@random-domain.com R=lookuphost T=remote_smtp H=mx.random-domain.com [198.51.100.30] C="550 5.7.1 Relaying denied" S=201 QT=0.3 DT=0.298

# 550 Blocked — sender masuk blacklist
2026-07-20 17:15:44 [77889] ** sender@blacklisted-domain.com R=lookuphost T=remote_smtp H=mx.external.com [203.0.113.40] C="550 5.7.1 Message rejected — see https://www.spamhaus.org/query/bl/" S=312 QT=0.4 DT=0.398

Kode 553 — Mailbox Name Not Allowed

553 biasanya muncul karena alamat email yang dikirim tidak valid secara syntax atau karena server tujuan tidak mengenali domain.

Kode 554 — Transaction Failed / Permanent Error

554 adalah catch-all untuk error permanen yang tidak masuk kategori lain. Sering muncul ketika server tujuan menolak email karena reputasi IP yang buruk atau content filtering.

Integrasi SpamAssassin & SpamBox di cPanel

SpamAssassin dan SpamBox adalah dua komponen yang sangat berpengaruh terhadap perilaku email di server cPanel. Kalau kamu nggak paham bagaimana keduanya berintegrasi dengan Exim, kamu akan kesulitan saat email client masuk ke spam folder secara tidak wajar.

SpamAssassin

SpamAssassin bekerja dengan menambahkan header X-Spam-Score ke setiap email yang masuk. Di cPanel, threshold default untuk menandai spam biasanya di score 5.0. Kamu bisa cek score spam di log Exim:

# Lihat semua email yang ditandai sebagai spam
exigrep "X-Spam-Score" /var/log/exim/mainlog | tail -20

# Cari email dengan spam score tertentu
exigrep "X-Spam-Score: [89]" /var/log/exim/mainlog

Jika kamu ingin melihat detail scoring SpamAssassin, cek log di /var/log/exim/mainlog dan cari header X-Spam-Status:

X-Spam-Status: No, score=8.2 required=5.0 tests=RCVD_IN_BL_SPAMHAUS,HTML_IMAGE_RATIO_02,MISSING_HTML_TAG,URIBL_BLACK autolearn=unavailable version=3.4.6

Dari log ini, kamu bisa lihat bahwa email mendapat score 8.2 (di atas threshold 5.0), sehingga ditandai sebagai spam. Test utama penyebabnya: masuk di Spamhaus blacklist (RCVD_IN_BL_SPAMHAUS) dan beberapa test lainnya.

SpamBox

SpamBox menyimpan email spam ke folder .Spam di mailbox user alih-alih langsung memblokirnya. Ini bagus karena user masih bisa cek spam folder mereka. Tapi kadang email legit juga masuk ke sini, dan user nggak sadar.

Path folder SpamBox di cPanel:

/home/username/mail/domain.com/user/.Spam/

Pastikan permission folder ini benar. Saya pernah handle kasus di mana folder .Spam punya permission yang salah (644 bukan 711), sehingga SpamBox tidak bisa menulis email ke folder tersebut dan semua email spam justru bounce balik ke pengirim.

# Cek permission folder mailbox
ls -la /home/username/mail/domain.com/user/

# Permission yang benar untuk folder mailbox
drwx--x---  3 username  username  4096 Jul 20 09:00 .
drwx--x---  5 username  username  4096 Jul 20 09:00 ..
drwx------  2 username  username  4096 Jul 20 09:00 cur
drwx------  2 username  username  4096 Jul 20 09:00 new
drwx------  2 username  username  4096 Jul 20 09:00 tmp
drwx------  2 username  username  4096 Jul 20 09:00 .Spam

Perhatikan bahwa folder mailbox menggunakan drwx--x--- (711 untuk direktori, 700 untuk subfolder). Ini penting untuk keamanan — mencegah user lain di server yang sama bisa membaca isi mailbox.

Pola Masalah yang Sering Ditemukan di Log Exim

Berdasarkan pengalaman menangani ratusan server, berikut pola-pola masalah yang paling sering muncul:

1. DNS yang Salah (MX/PTR)

Salah satu penyebab paling umum email bounce. Kalau MX record salah atau PTR record untuk IP server belum diatur, email dari server kamu akan ditolak hampir oleh semua mail server besar.

# Cek MX record domain kamu
dig +short MX yourdomain.com

# Cek PTR record IP server kamu
dig +short -x 203.0.113.10

# Cek apakah PTR match dengan hostname server
hostname -f

PTR record harus resolve ke hostname server, dan hostname server harus resolve balik ke IP yang sama (forward-confirmed reverse DNS). Kalau nggak match, banyak mail server yang akan menolak email dari IP kamu.

2. Autentikasi SMTP Mati

Kadang client mengeluh tidak bisa kirim email dari email client (Outlook, Thunderbird). Di log Exim kamu akan lihat:

2026-07-20 20:15:33 [88990] no IP address found for host client-pc-123.example.net
2026-07-20 20:15:33 [88990] authenticator failed for (client-pc-123): 535 Incorrect authentication data

Penyebabnya bisa bermacam-macam: password salah, plain text authentication disabled di WHM tapi client nggak pakai SSL, atau ada masalah dengan driver autentikasi cPanel (dovecotauth). Cek di WHM → Exim Configuration Manager → tab “Security” dan pastikan SMTP Authentication sudah diaktifkan dengan benar.

3. Queue Meluap (Mail Queue Overflow)

Ketika ada ribuan email stuck di queue, performa server akan menurun drastis. Cek jumlah email di queue:

exim -bpc

Kalau angkanya ratusan atau ribuan, ada masalah serius. Cek email apa yang stuck:

exim -bp | head -50

Untuk flush semua email dari queue (PERINGATAN: ini akan menghapus SEMUA email di queue):

# Backup dulu
exim -bp > /tmp/full-queue-backup-$(date +%Y%m%d-%H%M).txt

# Lihat jumlah email
cat /tmp/full-queue-backup-*.txt | wc -l

# Flush semua email
exim -bpr

Pro Tips & Warnings

1. Jangan pernah aktifkan +all di produksi untuk waktu lama. Log-nya bisa mencapai gigabyte per hari dan membebani disk I/O. Aktifkan hanya saat troubleshoot, lalu kembali ke konfigurasi ringan.
2. Selalu cek DNS terlebih dahulu sebelum menyimpulkan ada masalah di sistem lokal. 60% masalah email sebenarnya bermula dari DNS.
3. Gunakan exigrep dengan bijak. Pattern yang terlalu umum (misalnya hanya kata “error”) akan menghasilkan ribuan hasil yang nggak relevan. Selalu sertakan message ID atau IP spesifik.
4. Backup selalu dilakukan sebelum operasi destruktif. Ini bukan opsi — ini wajib. Satu kesalahan bisa berarti email penting client hilang selamanya.
5. Perhatikan timestamp. Ketika investigasi email bounce, mulai dari waktu kejadian dan trace ke depan. Jangan mulai dari baris terakhir log.
6. Cek RBL secara berkala. IP server bisa kapan saja masuk blacklist. Setup monitoring untuk auto-check setiap jam. Artikel kami tentang Cara Cek IP Blacklist RBL bisa jadi panduan.
7. Struktur direktori mailbox harus tepat. Folder /home/username/mail/domain/user/ harus punya struktur yang benar dengan permission 711 untuk direktori dan 700 untuk subfolder. Lihat juga panduan kami tentang Troubleshooting Email cPanel untuk detail lebih lanjut.
8. Pahami retry rule Exim. Exim tidak langsung menghapus email yang gagal. Ada mekanisme retry yang menentukan kapan email akan dicoba lagi. Kamu bisa lihat retry configuration di Panduan Konfigurasi Retry Exim.

Troubleshooting Cepat — Decision Tree

Ketika kamu menerima laporan masalah email, ikuti flow ini:

1. Cek queue dulu: exim -bpc — kalau banyak, ada masalah delivery
2. Cek log untuk message ID spesifik: exigrep "<message-id>" /var/log/exim/mainlog
3. Baca simbol: <= masuk, => keluar, == defer, ** bounce
4. Cek error code: 4xx temporary (retry), 5xx permanent (bounce)
5. Trace dari awal ke akhir: Mulai dari baris pertama, ikuti alurnya

Kesimpulan

Membaca log Exim memang menuntut ketelitian — kamu harus memahami setiap simbol, setiap kode error, dan mampu menelusuri perjalanan email dari awal hingga akhir. Tapi begitu kamu menguasai polanya, troubleshoot email jadi jauh lebih cepat dan akurat. Ingat: selalu verifikasi catatan DNS dan status RBL server sebelum menyimpulkan kerusakan ada di sistem lokal. Dan yang paling penting — backup dulu, baru eksekusi.

Masih punya pertanyaan soal log Exim? Tim NOC kami handle ini setiap hari — hubungi kami kalau kamu butuh bantuan langsung untuk masalah email di server kamu.